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 for Bug 8490 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
[ This is a fairly low priority bug because it only affects the rare scenario of adding new languages to xbuild, and even then only affects the portability of the LANG.targets for that language across xbuild and msbuild, and even then there are workarounds. See https://github.com/fsharp/fsharp/issues/61. ]
Bug: Each LANG.targets should be portable across xbuild and msbuild, and mostly this is the case, but not for resource name processing.
The lack of portability is because Microsoft.Common.targets (part of xbuild and msbuild) differs between xbuild and msbuild. In particular the inputs/outputs expected for CreateManistResourceNames differ between xbuild and msbuild.
The details are murky and the exact range of behaviors accepts by msbuild are particularly hard to work out because there is a lot of 'legacy' stuff that seems to be allowed.
Roughly speaking, the current xbuild behavior is:
(a) Microsoft.Common.targets produces lists:
(b) the CreateManifestResourceNames in LANG.targets produces
(c) these are picked up by later processing in Microsoft.Common.targets
Roughly speaking, the MSBuild behavior is:
(a) Microsoft.Common.targets produces the list 'EmbeddedResource'
(b) the CreateManifestResourceNames in LANG.targets modifies this list
(c) lots of legacy things also seem partially supported (based on browsing Microsoft.Common.targets)
To make the bug a bit clearer, can you: list steps to reproduce (with a minimal testcase), expected results (of MSBuild), current results (of xbuild)?
TBH I don't even know if you want to fix this - we only noticed the difference in behavior when writing a new LANG.targets file that has a CreateManifestResourceNames task, and you try to use that LANG.targets with both msbuild and xbuild. Even then we worked around it.
The steps are something like
- Take github.com/fsharp/fsharp
- Remove the 'UsingXBuild' detection logic from src/fsharp/FSharp.Build/Microsoft.FSharp.targets (assume UsingXBuild=false)
- Compile a project file that has an EmbeddedResource element
- Notice that the resource is not in the command line flags
There would be a simpler repro but it would mean writing a completely new LANG.targets for an artificial language and that doesn't seem worth it.
Ok, if you're saying it applies to any language, does that mean you can reproduce the bug with C# then? (If yes, working on the bug without taking in account F# will be easier.)
I guess the test would be if you could take msbuild's Microsoft.CSharp.targets and it 'just worked' against xbuild's Microsoft.Common.targets. Maybe that even works today?
That would show you could 'add a new language' on top of Microsoft.Common.targets in a way that was portable between xbuild and msbuild.
I don't think this is necessarily an important scenario - the targets files are so intertwined. I was already surprised at the level of compatibility reached.
I think you're focusing too much in your particular scenario. ".targets" files are just MSBuild files with <Target> elements that are imported from other MSBuild files. One could write a small testcase that mimics the problem at hand, without needing to imagine any "new language" scenario :)