Bug 2971 - Monodevelop Included System.Core.dll in compilation regardless if it's included in the project file.
Summary: Monodevelop Included System.Core.dll in compilation regardless if it's includ...
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.8.6
Hardware: Macintosh Mac OS
: Low minor
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-01-19 11:29 UTC by Eric Beisecker
Modified: 2012-04-24 14:02 UTC (History)
2 users (show)

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

Comparison of the csproj file and build output. (1.35 KB, application/octet-stream)
2012-01-19 11:29 UTC, Eric Beisecker
VS and MD Projects using Linq with no System.Core.dll ref (35.93 KB, application/zip)
2012-01-20 17:55 UTC, Eric Beisecker

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 Developer Community or GitHub 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 Eric Beisecker 2012-01-19 11:29:41 UTC
Created attachment 1234 [details]
Comparison of the csproj file and build output.

Current Behavior: When compiling a new project, a reference to System.Core.dll is provided to the compiler even if none is specified in the Project File.

Expected Behavior: Only references in the project file should be provided to the Compiler. 

MonoDevelop 2.8.6
Mono: 2.10.8

Attached is a Comparison of the CSProj file and the Build Output.

Note: A side effect of this is no Autocomplete displayed for functionality in System.Core but the Project compiles without any errors.
Comment 1 Mikayla Hutchinson [MSFT] 2012-01-19 19:01:24 UTC
This appears to be by design:

That said, I'm not sure why we also do it for 3.5 projects. It's needed for C# 3.0 feature such as extension methods, but we should check this behaviour is compatible with VS/msbuild.
Comment 2 Eric Beisecker 2012-01-20 12:00:00 UTC
From what I've seen, if you create a new Project in Monodevelop which does not explicitly reference System.Core.dll in the csproj file it will NOT build using MSBuild. (If you use members from System.Core such as Linq)

What I have also seen is when creating a new Project in Visual Studio 2010, you can remove the Reference to System.Core.dll in the csproj file and MSBuild will still reference System.Core.dll.
Comment 3 Mikayla Hutchinson [MSFT] 2012-01-20 17:15:21 UTC
I don't really understand your first paragraph, and the second seems to support MD's current behaviour.

Just to get few things clear here:
* The project files that MD uses are MSBuild files.
* MonoDevelop is (very) slowly migrating to the MSBuild build engine from its old internal build engine.
* The MD internal build engine is still used by default for everything except Mono for Android projects.
* Although the MD internal build engine only supports a subset of MSBuild's features, those it does support are supposed to be compatible with the MSBuild behavior.
* Visual Studio uses MSBuild as its build engine.
* The linked bug mentions that MSBuild implicitly adds a reference to System.Core for 4.0 projects, even if the project does not reference it explicitly. My question was about whether this is true for 3.5 projects.
* The implicit reference is probably because several C# features depend on types in System.Core - extension methods depend on ExtensionAttribute, dynamic depends on DynamicType, etc.
* Just because we add a reference implicitly to support C# features doesn't mean we should provide code completion. For that, the reference should be explicit. 
* Mono's xbuild is supposed to be a compatible clone of MSBuild, so when I say MSBuild behaves a certain wasy, xbuild should behave the same way. However, it may have bugs.
Comment 4 Eric Beisecker 2012-01-20 17:54:55 UTC
I've attached an experiment that shows the Behavior that I am seeing:

Project TestingCore: 
* Created in Visual Studio
* Builds in Visual Studio 2010
* Builds in MonoDevelop (When Target is Switched to Mono/.Net 4.0
* Builds in Terminal with MSBuild
* Builds in Terminal with XBuild

Project TestingCoreMD:
* Created in MonoDevelop
* Builds in MonoDevelop
* Builds in Visual Studio 2010 (After running Solution Conversion Tool)
* Does NOT Build in terminal with Xbuild 
* Does NOT Build in terminal with MSBuild
Comment 5 Eric Beisecker 2012-01-20 17:55:43 UTC
Created attachment 1247 [details]
VS and MD Projects using Linq with no System.Core.dll ref
Comment 6 Mikayla Hutchinson [MSFT] 2012-01-20 18:19:14 UTC
My reading of that list is that MD's behaviour is correct for projects that use VS2010 format and framework 4.0, but is not correct for projects that use VS2008 format and framework 3.5. Does that sound correct?

So my question remains, what happens with 3.5 framework projects is VS2010 format? Is this behaviour framework-specific or format-specific?

I assume the reason you had to switch the framework in MD was that VS created a project that used the client profile?
Comment 7 Eric Beisecker 2012-01-23 13:33:27 UTC
After talking with Hutch the problem seems to be with the Project File Version.

MSBuild 4.0 adds the reference to System.Core.dll and MSBuild 3.5 does NOT add this reference. This is regardless of what Target Framework (3.5 or 4.0) is set.
Comment 8 Miguel de Icaza [MSFT] 2012-04-24 12:34:34 UTC
Does this mean that we can close this bug?
Comment 9 Eric Beisecker 2012-04-24 14:01:45 UTC
I think
Comment 10 Eric Beisecker 2012-04-24 14:02:12 UTC
What I meant to say, I think this bug can be safely closed.