Bug 20966 - Embedded Resources in SAPs don't get folders in resource path
Summary: Embedded Resources in SAPs don't get folders in resource path
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: unspecified
Hardware: Macintosh Mac OS
: High critical
Target Milestone: ---
Assignee: Dave Thomas
Depends on: 37971
  Show dependency tree
Reported: 2014-06-28 01:46 UTC by bryan costanich
Modified: 2017-09-04 22:16 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Repro solution (2.51 MB, application/zip)
2014-06-28 01:46 UTC, bryan costanich

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description bryan costanich 2014-06-28 01:46:07 UTC
Created attachment 7228 [details]
Repro solution

Embedded resources follow a convention of AssemblyName.folderStructure.resourcename. So for instance, if an embedded resource is in the folder structure /AFolder/AnotherFolder/SomeResource.json, and it's in the MyAwesomeApp assembly, the fully qualified resource path should be:


This seems to work everywhere in .net and in Xamarin using PCLs. 

It fails, however, in shared asset projects. instead, the resource would actually be:


As you can imagine, if you have resources with the same name, this is a problem.

You can see this in the attached repro project. There is a resource in the SAP that should resolve to: SapResourceBug.iOS.AFolder.AnotherDamnFolder.MyResource.json, however, if you run the app and click the enumerate resourcs button, you'll see in the application output that it finds the resource as "SapResourceBug.iOS.MyResource.json"
Comment 1 Miguel de Icaza [MSFT] 2014-06-28 12:44:26 UTC
Bryan, is this an issue with Xamarin Studio, or an issue in both IDEs?
Comment 2 bryan costanich 2014-06-28 12:48:25 UTC
Only tried it in Xam Studio. My Windows VM is not healthy currently.
Comment 3 Lluis Sanchez 2014-06-30 14:11:54 UTC
I tried with VS and it does the same. Embedded resources in shared projects don't include the folder name. In case of id collision you can use a custom id using the LogicalName element.
Comment 4 bryan costanich 2014-06-30 15:11:06 UTC
Is this right? do we need to file a bug with MS as well?

This doesn't seem to make sense as is.
Comment 5 bryan costanich 2014-06-30 15:12:08 UTC
Really sounds like a bug in both sides; this really doesn't map to what a developer would expect, and I'm more interested in getting this fixed up all around than just making it work as is.
Comment 6 Miguel de Icaza [MSFT] 2014-06-30 15:17:51 UTC
Sure, you should reach out to Microsoft.
Comment 8 Mikayla Hutchinson [MSFT] 2014-06-30 15:59:55 UTC
FYI this behavior comes from MSBuild. It'll be extremely difficult to change it without breaking things.
Comment 9 bryan costanich 2014-07-01 00:20:23 UTC
Something being difficult to fix doesn't preclude us from fixing it. :) 

I've reached out to MS on the issue, I'll let you know what comes of it.

Lluis, the LogicalName thing is a nightmare. You'd have to go hand edit the project file for each resource, creating a nightmare of maintenance.
Comment 10 Lluis Sanchez 2014-07-01 04:11:11 UTC
> Something being difficult to fix doesn't preclude us from fixing it

I agree, although in this case we depend on MS. We cannot fix it ourselves. This is not a bug in Xamarin Studio, it is a consequence of how shared projects work.

Sure, at the end it is a problem that our customers will suffer, so I think it is a good idea to talk to MS and try to find a solution.

BTW, in you example you say that the resource should be named SapResourceBug.iOS.AFolder.AnotherDamnFolder.MyResource.json. However, SapResourceBug.iOS is the name of the iOS project, not the name of the shared project. So I would expect the resource name to be SapResourceBug.AFolder.AnotherDamnFolder.MyResource.json.

> Lluis, the LogicalName thing is a nightmare. You'd have to go hand edit the
> project file for each resource, creating a nightmare of maintenance.

Not in XS, you can change the logical name in the properties pad :)
Comment 11 bryan costanich 2014-07-01 11:04:36 UTC
good to know about logical name

on the resource prefix, shared access files get copied into the consuming/executing assembly, so i would expect the prefix to take on the consuming assembly id. that's why SapResourceBug.iOS....
Comment 12 Lluis Sanchez 2014-07-01 13:22:15 UTC
BTW, the first string is not the assembly id, it is the default namespace for the project.

So the resource name would be composed by the default namespace of the including project + the folder in the shared project + the file name. IMO that's also confusing, since shared projects do have its own default namespace.
Comment 13 bryan costanich 2014-08-18 02:06:50 UTC
Microsoft has acknowledged this as a bug, and have fixed it. It'll be released in Dev14 CTP3. I'm trying to find out when that is, but it looks like we'll need to change our behavior as well.
Comment 14 Mikayla Hutchinson [MSFT] 2014-08-18 12:07:48 UTC
Curious to see how they will do that without breaking backward compatibility.
Comment 15 Lluis Sanchez 2014-08-25 09:01:25 UTC
According to MS, support for embedded resources was out of scope in VS 2013 update 2, even though it kinda worked. So from their point of view they are not breaking backward compatibility (but in practice they do).

I tried Dev14 CTP3 and they fixed the issue. This needs to be fixed in xbuild, not in XS.
Comment 17 bryan costanich 2014-10-04 12:15:36 UTC
by the way, this seems to work for PCL projects, if you go to the .NET Naming Policies in the solution/project settings, there's a setting to "Use Visual Studio-style Resource Names," so evidently, we already have some support for this.
Comment 18 Lluis Sanchez 2014-10-13 10:48:46 UTC
This is not a problem for libraries because they generate its own assembly. Shared projects are a completely different thing.
Comment 20 Lluis Sanchez 2015-01-15 05:13:16 UTC
Created a PR with a fix: https://github.com/mono/mono/pull/1508
Comment 21 bryan costanich 2016-01-24 19:55:48 UTC
what's happening with this bug???
Comment 22 bryan costanich 2016-01-25 00:24:41 UTC
So i think this has been fixed in C#, but is broken with F#.
Comment 23 Lluis Sanchez 2016-01-25 13:29:38 UTC
This needs to be fixed in the F# msbuild targets
Comment 25 Lluis Sanchez 2016-02-03 13:28:56 UTC
There is a more generic problem with F# and resources, which is tracked in bug #37971.
Comment 26 Marek Safar 2017-09-04 22:16:24 UTC
This seems to be fixed already