none
Confusing behavior in CSharpCodeProvider compiler after moving to .Net 4. RRS feed

  • Question

  • I'm seeing something very odd with a project that ran fine until I modified it to work with .Net 4.

    I run compilations of user code and I am seeing a very odd error related to System.Linq, here are the diagnostics:

    6/14/2011 2:21:27 PM: CS1684 on line 0 - Reference to type 'System.Func`3' claims it is defined in 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll', but it could not be found
    6/14/2011 2:21:27 PM: CS1684 on line 0 - Reference to type 'System.Func`2' claims it is defined in 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll', but it could not be found
    6/14/2011 2:21:27 PM: CS1684 on line 0 - Reference to type 'System.Func`2' claims it is defined in 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll', but it could not be found
    6/14/2011 2:21:27 PM: CS0570 on line 136 - 'System.Linq.ParallelEnumerable.Select<TSource,TResult>()' is not supported by the language
    6/14/2011 2:21:27 PM: CS0570 on line 136 - 'Select' is not supported by the language

    I have looked into this in some detail but its not making sense.

    Firstly Func is referenced in System.Core.dll (v4) which is in the list of referenced assemblies along with System, for example the class Queryable refers to Func, but Func is NOT defined in System.Core.dll (it was in .Net 3.5) but is now defined in mscorlib.dll (v 4).

    However inside that version of mscorlib.dll the entry for the delegate Func has an attribute like this:

    [TypeForwardedFrom("System.Core, Version=3.5.0.0, Culture=Neutral, PublicKeyToken=b77a5c561934e089")]

    Which I suspect is causing this confusing behaviour.

    I tried adding "mscorlib.dll" (both versions) to the compiler assembly reference list, but just complains then that "mscorlib" has already been added, when I run the compile.

    Surely the resolving should take place automatiucally and the compiler should find these DLLs all by itself.

    The app itself (the tool that does these compiles) is built to run under .Net 4.

     

    Does anyone have any suggestions for investigating this further?

    Thx

    Cap'n

     

     

    • Moved by Paul Zhou Thursday, June 16, 2011 9:03 AM (From:Building Development and Diagnostic Tools for .Net)
    Tuesday, June 14, 2011 6:52 PM

All replies

  • I have an update on this.

    I took the code and stuff (that I am unable to compile using CSharpCodeProvider) and created a simple class project alongside an empty test console project.

    The code compiles fine and specifies the SAME references as I use in the CSharpCodeProvider test.

    So I decided to exmine the compiled class assembly inside to see it's details.

    I saw that the class library itself has a reference to mscorlib.dll v4, but some of the other referenced assemblies (other support assemblies of mine) refer to mscorlib.dll v2.

    The code compiles and I can create instances of my class, so I know that this is all valid.

    This raises a few questions:

    1. How can any code refer to different versions of mscorlib?

    2. At runtime I can see that ONLY the v4 mscorlib.dll gets loaded, so what happens to the other dlls that refer to v2 of it?

    3. What is different about my compile using CSharpCodeProvider and apparently the SAME references as the Visual Studio build?

    I know that in VS2010 we set a project as being built against this or that version of the framework, but is there an equivalent way to specify this when one uses CSharpCodeProvider ?

    How does the CSharpCodeProvider build decided on what version of mscorlib to refer to, since if I try to explicit set a reference to it it complains about one already being set.

    Is there a way to force a CSharpCodeProvider build to refer to a specific mscorlib.dll?

     

    Thanks

    Cap'n


    Wednesday, June 15, 2011 5:32 PM
  • Different version of .NET Framework loads different CLR.

    .NET Framework 2.0 3.0 3.5 loads the same CLR--CLR2.0.

    .NET Framework 4.0 loads CLR 4.0.

    And in one .NET 4.0 process, different CLRs can be loaded. It means that we can load another version of CLR in a CLR 4.0 process.


    Hard hard work, Day day up!
    Thursday, June 16, 2011 9:06 AM
  • Different version of .NET Framework loads different CLR.

    .NET Framework 2.0 3.0 3.5 loads the same CLR--CLR2.0.

    .NET Framework 4.0 loads CLR 4.0.

    And in one .NET 4.0 process, different CLRs can be loaded. It means that we can load another version of CLR in a CLR 4.0 process.


    Hard hard work, Day day up!


    Thanks, I found the cause of my problem too.

    I was using an obsolete version of the compiler classes and these were (internally) forcing the assembly to be compiled with a reference to mscorlib v2. So when it tried to resolve the names that are now in mscrolib v4, it could not find them.

    I upgraded the code to use the current and non-obsolete compiler classes and they cause the code to be built for mscorlib v4 and all works fine.

    A problem area here is that one never adds or sees a referebce to mscorlib.dll in a project, the system somehow quietly does this behind the scenes and I am unsure of how one can run the compiler classes and force them to use some version of .Net (is it the "compiler version" that one can pass to the CShaprCodeProvider's constructor?)

    Anyway, this is running OK now but was pretty complicated to resolve.

    Thanks

    Cap'n

     

     

    • Proposed as answer by MarkusSchaber Sunday, July 24, 2011 1:24 PM
    Thursday, June 16, 2011 2:37 PM