Bug 14886 - mscorlib not resolved for custom frameworks
Summary: mscorlib not resolved for custom frameworks
Status: RESOLVED FIXED
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Martin Baulig
URL:
Depends on:
Blocks:
 
Reported: 2013-09-20 14:09 UTC by Mikayla Hutchinson [MSFT]
Modified: 2016-11-11 09:35 UTC (History)
1 user (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 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:
Status:
RESOLVED FIXED

Description Mikayla Hutchinson [MSFT] 2013-09-20 14:09:25 UTC
xbuild does not resolve mscorlib for custom frameworks.

The MS Microsoft.CSharp.Targets do it like this:
* If NoCompilerStandardLib is empty, set NoCompilerStandardLib to true
* if NoCompilerStandardLib is true and NoStdLib is not true, add an _ExplicitReference item with the value $(FrameworkPathOverride)\mscorlib.dll

The Mono Microsoft.Common.targets doesn't set the FrameworkPathOverride property or respect _ExplicitReference items. Setting the property will be tricky because it's set in the same propertygroup that sets TargetFrameworkMoniker, by calling a property function (http://msdn.microsoft.com/en-us/library/dd633440.aspx) that gets the mscorlib location from the TargetFramework* properties.

The Mono PCL targets hack around this by setting NoStdLib and adding their own mscorlib directly, instead of fixing it...
Comment 1 Mikayla Hutchinson [MSFT] 2013-09-20 14:12:32 UTC
Note also that the MS target do not pass NoStdLib to the csc task, they pass NoCompilerStandardLib. So the compiler will always use /nostdlib unless NoCompilerStandardLib is set to something other than "true". The NoStdLib value set by users is instead used to control whether msbuild adds the mscorlib reference.
Comment 2 Martin Baulig 2016-11-11 09:35:04 UTC
Closing ancient bugs, please reopen if you're still having this problem.