2010-07-19 7 views
3

J'essaie de ne pas cibler une version spécifique d'une DLL, mais je ne sais pas très bien comment. J'ai mis l'option Version spécifique sur les propriétés de l'assemblée à faux, si je tente de lancer l'application et la version de l'Assemblée est un précédent, je reçois un:Cibler une version non spécifique d'un assemblage

FileLoadException: Could not load file or assembly 

C'est passe lorsque la version de la DLL référencée ne correspond pas exactement à la version actuelle. Je crois que le problème est de savoir comment référencer cet assemblage.

+0

est-nom fort l'assemblée? –

+0

oui son fortement nommé (existe-t-il une solution de contournement?) – roundcrisis

+1

Le but des assemblys fortement nommés est que vous ne pouvez pas modifier une autre version. Donc reconstruit votre application avec la nouvelle version de l'assemblage. Si vous avez besoin de changer les assemblages fréquemment, vous devriez penser à utiliser [MEF] (http://mef.codeplex.com/). – Oliver

Répondre

2

En général, si vous essayez d'utiliser une version spécifique d'un assemblage, ce qui suit ne s'applique pas vraiment, vous devriez juste utiliser la version dont vous avez besoin

Cependant, parfois, vous pouvez exécuter dans une situation où vous avez ceci:

AssemblyX - références version 1.2.1 de AssemblyZ
AssemblyY - références de la version 1.2.2 AssemblyZ

Mais votre le projet a besoin des deux AssemblyX et AssemblyY.

Alors, comment résolvez-vous cela? Vous pouvez soit mettre 1.2.1 et 1.2.2 de AssemblyZ dans le GAC, ou, si vous êtes sûr qu'il n'y a pas de problèmes de compatibilité, vous pouvez utiliser la reliure d'assemblage. Voici un exemple (cela va dans votre fichier Web.config ou App.config):

<configuration> 
    <runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
      <assemblyIdentity name="myAssembly" 
           publicKeyToken="32ab4ba45e0a69a1" 
           culture="neutral" /> 
      <bindingRedirect oldVersion="1.0.0.0" 
          newVersion="2.0.0.0"/> 
     </dependentAssembly> 
     </assemblyBinding> 
    </runtime> 
</configuration> 

Cela dit essentiellement est que si les assemblées dans la référence de votre solution 1.0.0.0 de myAssembly, alors ils devraient vraiment utiliser la version 2.0.0.0. Et vous devez avoir la version 2.0.0.0 présente dans le chemin.

Un hack vous pouvez utiliser quand vous voulez toujours les utiliser une version spécifique de l'ensemble est de spécifier une plage de versions, comme ceci:

 <dependentAssembly> 
      <assemblyIdentity name="MyAssembly" publicKeyToken="B7567367622062C6" culture="neutral" /> 
      <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="1.2.1.0" /> 
     </dependentAssembly> 

Cela forcera la version 1.2.1.0 de MyAssembly être utilisé pour toute référence de version de MyAssembly entre 0.0.0.0 et 3.0.0.0.

+1

Cela ne résout pas spécifiquement le problème que j'ai, mais je pense qu'il pourrait être dans certaines situations donc je vais prendre cela comme une réponse – roundcrisis

+0

Comment puis-je spécifier pour ** AssemblyX ** faire référence à une version de ** AssemblyZ **? Puis-je simplement ajouter un fichier ** AssemblyX.dll.config ** à mon dossier d'installation et personnaliser la référence pour une application déjà compilée? –

+0

@Mehrdad Mirreza - Le fichier de configuration doit correspondre au nom de votre fichier exe, avec un suffixe .config. Donc, si votre exe était MyProgram.exe, alors le fichier de configuration devrait s'appeler MyProgram.exe.config. En ce qui concerne l'ajout d'une liaison d'assembly à une application déjà compilée, vous pouvez essayer, cependant, la plupart du temps vous ne pourriez pas compiler pour commencer car il ne serait pas capable de trouver la bonne version de l'assemblage . Donc, la meilleure approche serait probablement de recompiler les versions de l'assemblage que vous souhaitez cibler. – dcp

0

les seules façons de contourner ce problème que je trouve à ce jour sont:

1) ILMerge la dll avec la dépendance je 2) fournir la dépendance (dans ce cas, une dll) 3) ne signong la l'assemblage, ce qui serait assez difficile, parce que je devrais "désinsérer" la hierarchie

0

Vous pouvez avoir les deux dll et peut utiliser bindingRedirect comme lien ci-dessous

dll versioning in dotnet

<configuration> 
    <runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
      <assemblyIdentity name="AssemblyName" 
           publicKeyToken="32ab4ba45e0a69a1" 
           culture="neutral" /> 
      <bindingRedirect oldVersion="1.0.0.0" 
          newVersion="2.0.0.0"/> 
     </dependentAssembly> 
     </assemblyBinding> 
    </runtime> 
</configuration> 
0

Bien que l'exemple de code pour App.Config ci-dessous est correct, vous voudrez peut-être garder la politique de GAC ne remplace pas votre En ajoutant l'instruction publisherPolicy suivante = "non" dans l'arborescence assemblyBinding, tous les assemblys doivent ignorer la règle d'éditeur GAC ou vous pouvez placer la propriété publisherPolicy apply = "no" /> dans l'arborescence dependentAssembly, ce qui permet de contourner publisherPolicy pour cet assemblage seulement.

{ <configuration> 
    <runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <publisherPolicy apply="no" /> // This applies to the whole application - all references 
     <dependentAssembly> 
     <publisherPolicy apply="no" /> // This applies only to this assembly 
      <assemblyIdentity name="AssemblyName" 
           publicKeyToken="32ab4ba45e0a69a1" 
           culture="neutral" /> 
      <bindingRedirect oldVersion="1.0.0.0" 
          newVersion="2.0.0.0"/> 
     </dependentAssembly> 
     </assemblyBinding>} 

Pour plus d'informations, voir: MSDN reference

Questions connexes