This is normal; you will see the .NET 2.0 assembly links for any framework classes that display as public types in an obsolete assembly. For example, a class library project compiled in VS2008 using this code:
using System; using System.Text; public class Class1 { public static void Run(out StringBuilder sb) { sb = new StringBuilder(); } }
And it is used in the VS2010 console mode application, the purpose of which is 4.0:
using System; using System.Text; class Program { static void Main(string[] args) { StringBuilder sb; Class1.Run(out sb); } }
Produces assembly references in its manifest as follows:
// Metadata version: v4.0.30319 .assembly extern mscorlib { .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4.. .ver 4:0:0:0 } .assembly extern ClassLibrary3 { .ver 1:0:0:0 } .assembly extern mscorlib as mscorlib_2 { .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4.. .ver 2:0:0:0 }
Pay attention to the link to the version of mscorlib version 2.0 called "mscorlib_2". This is allowed at runtime. There is no sign in the merge log that has ever requested permission to link to the assembly mscorlib_2. The object of the StringBuilder class that is created is version 4.0. This probably means that the CLR assembly loader redirects the version. I do not know any configuration that does the mapping, assuming it is hardcoded.
This, of course, could potentially lead to breaking code that has only ever been tested with the .NET versions of the v2.0-v3.5sp1 assembly. I have not heard a single case.
Hans passant
source share