Bug 8490 - Tricky to write a LANG.targets that is portable across xbuild and msbuild for resource name processing.
Summary: Tricky to write a LANG.targets that is portable across xbuild and msbuild for...
Status: NEW
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-11-19 00:56 UTC by Ben Winkel
Modified: 2012-11-19 05:40 UTC (History)
2 users (show)

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

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 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 original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Ben Winkel 2012-11-19 00:56:22 UTC
[ 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.

Detailed Description: 

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:
         ResxWithNoCulture
         NonResxWithNoCulture
         ResxWithCulture
         NonResxWithCulture

   (b) the CreateManifestResourceNames in LANG.targets produces

         ManifestResourceWithNoCultureName
         ManifestNonResxWithNoCulture
         ManifestResourceWithCultureName
         ManifestNonResxWithCulture

   (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)
Comment 1 Andres G. Aragoneses 2012-11-19 04:46:05 UTC
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)?

Thanks
Comment 2 Ben Winkel 2012-11-19 05:10:35 UTC
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.
Comment 3 Andres G. Aragoneses 2012-11-19 05:14:19 UTC
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.)
Comment 4 Ben Winkel 2012-11-19 05:38:20 UTC
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.
Comment 5 Andres G. Aragoneses 2012-11-19 05:40:58 UTC
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 :)