Linking to a .Net v2.0 assembly from a .Net v4.0 assembly also appears to link (and alias) mscorlib v2.0. Why?

Question

I have a .Net assembly which imports an assembly linked against the v2.0 runtime. The problem I'm having is that when I try to run some tests on my assembly, Fusion trys to load the wrong version of a dependent assembly.

After looking at the assembly manifest, I can see why: the wrong version of FSharp.Core is linked. In my build file, I make FSharp.Core, Version=4.0.0.0 explicit, but FSharpPowerPack appears to link to v2.0.0.0, and some how seems to "win" this linking battle.

Here's the manifest:

// 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 System.Core
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern System
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 4:0:0:0
}
.assembly extern FSharp.PowerPack
{
  .publickeytoken = (A1 90 89 B1 C7 4D 08 09 )                         // .....M..
  .ver 2:0:0:0
}
.assembly extern mscorlib as mscorlib_8
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
.assembly extern System.Core as System.Core_9
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 3:5:0:0
}
.assembly extern FSharp.Core
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 2:0:0:0
}

Note that it seems that by including FSharpPowerPack the v2.0 and v3.5 of other .Net assemblies (mscorlib, System, System.Core) are included and aliased. Why does this happen? Is this related to the issue of loading the wrong version of FSharp.Core?

Edit: To clarify, my assembly is being generated by the C# v4.0 compiler.

Injector

This quacks like a F# compiler bug. Check if you can repro it with the C# compiler referencing those assemblies and creating some objects. I doubt it. If not then ping connect.microsoft.com. – Materialist

@Hans Passant - this is actually the C# compiler producing this manifest. I just linked to the F# libs... – Injector

Answer 1

Are you in control of the application which will load the compiled assembly? If so, you could use a binding redirect in your app.config file to force all FSharp.Core references to use version 4.0:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="4.0.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

If you are having the problem with an automated test application, you might be able to edit its config file in a similar way, assuming it doesn't affect its operation.

Vile

Mike - the problem isn't with FSharp.Core. It is with mscorlib.dll and System.dll. – Injector

From your description, it seems like loading the correct version of FSharp.Core might also fix the mscorlib.dll and System.dll issues – Joselyn

I think you should be able to do the same thing with the other assemblies as long as you change the name and public key token to match that of the other assemblies. – Vile