Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 7228 [details]
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"
Bryan, is this an issue with Xamarin Studio, or an issue in both IDEs?
Only tried it in Xam Studio. My Windows VM is not healthy currently.
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.
Is this right? do we need to file a bug with MS as well?
This doesn't seem to make sense as is.
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.
Sure, you should reach out to Microsoft.
FYI this behavior comes from MSBuild. It'll be extremely difficult to change it without breaking things.
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.
> 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 :)
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....
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.
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.
Curious to see how they will do that without breaking backward compatibility.
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.
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.
This is not a problem for libraries because they generate its own assembly. Shared projects are a completely different thing.
Created a PR with a fix: https://github.com/mono/mono/pull/1508
what's happening with this bug???
So i think this has been fixed in C#, but is broken with F#.
This needs to be fixed in the F# msbuild targets
@Lluis: in here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Build/Microsoft.FSharp.targets
There is a more generic problem with F# and resources, which is tracked in bug #37971.
This seems to be fixed already