2010-10-01 33 views
4

J'ai un assemblage .Net qui importe un ensemble lié avec le moteur d'exécution v2.0. Le problème que j'ai est que quand j'essaye d'exécuter quelques tests sur mon assembly, Fusion essaye de charger la mauvaise version d'un assembly dépendant. Après avoir regardé le manifeste d'assemblage, je peux voir pourquoi: la mauvaise version de FSharp.Core est liée. Dans mon fichier de construction, je fais FSharp.Core, Version=4.0.0.0 explicite, mais FSharpPowerPack semble lier à la version 2.0.0.0, et certains semblent gagner cette bataille de liaison.Liens vers un ensemble de v2.0 .Net d'un ensemble de v4.0 .Net semble également un lien (et alias) v2.0 mscorlib. Pourquoi?

est ici manifeste:

// 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 
} 

Notez qu'il semble que, en incluant FSharpPowerPack la v2.0 et v3.5 d'autres ensembles .Net (mscorlib, système, System.Core) sont inclus et aliasé. Pourquoi cela arrive-t-il? Est-ce lié au problème de chargement de la mauvaise version de FSharp.Core?

Modifier: Pour clarifier, mon assembly est généré par le compilateur C# v4.0.

+0

Ce charlatan ressemble à un bug du compilateur F #. Vérifiez si vous pouvez le reprocher avec le compilateur C# référençant ces assemblages et créant des objets. J'en doute. Si ce n'est pas le cas, envoyez un ping à connect.microsoft.com. –

+0

@Hans Passant - c'est en fait le compilateur C# produisant ce manifeste. Je viens de me lier aux librairies F # ... – codekaizen

Répondre

2

Contrôlez-vous l'application qui chargera l'assemblage compilé? Si oui, vous pouvez utiliser une redirection de liaison dans votre fichier app.config pour forcer toutes les références FSharp.Core à utiliser la 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> 

Si vous rencontrez le problème avec une application de test automatisé, vous pourriez être en mesure pour modifier son fichier de configuration d'une manière similaire, en supposant que cela n'affecte pas son fonctionnement.

+0

Mike - le problème n'est pas avec FSharp.Core. C'est avec mscorlib.dll et System.dll. – codekaizen

+0

De votre description, il semble que le chargement de la version correcte de FSharp.Core peut également résoudre les problèmes mscorlib.dll et System.dll – matheeeny

+0

Je pense que vous devriez être en mesure de faire la même chose avec les autres assemblys tant que vous changez le le jeton de nom et de clé publique pour correspondre à celui des autres assemblys. –