Pourquoi mon application utilise-t-elle toujours la dernière version de GAC au lieu de la version référencée ?

StackOverflow https://stackoverflow.com//questions/10700669

Question

Contexte

J'ai 2 versions différentes d'un assembly installé dans GAC, version 1.0 et version 2.0.J'ai créé une application qui fait référence à 1.0 comme version spécifique.

Problème

Lorsque j'exécute mon application, elle chargera toujours la version 2.0 alors que l'application fait spécifiquement référence à la version 1.0.

Question

Pourquoi cela arrive-t-il?Comment puis-je forcer mon application à charger la version pour laquelle elle a été compilée ?

Il ne me semble pas que cela ait quelque chose à voir avec une redirection de liaison car mon application n'était même pas au courant de la version 2.0 lorsque je l'ai construite et que les métadonnées de référence "Version spécifique" sont définies sur true.

Merci.


Modifier:

L'assembly auquel je fais référence est en fait Oracle.DataAccess du package ODAC.J'ai remarqué que d'autres assemblys nommés Policy.x.xxx.Oracle.DataAccess étaient publiés dans GAC.


Modifier 2 :

Après avoir examiné la politique Oracle.DataAccess, j'ai trouvé la configuration définissant la redirection de liaison :

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/>
            <bindingRedirect oldVersion="4.112.0.0-4.112.3.0" newVersion="4.112.3.0"/>
        </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Même si j'ai ajouté la redirection de liaison inversée dans la configuration de mon application, la politique du GAC semble avoir la priorité.j'ai trouvé un Article MSDN traiter le sujet et suggérer d'ignorer la politique avec cette configuration :

<publisherPolicy apply="no" />

Mais cela ne fonctionne toujours pas...


Modifier 3 :

J'ai essayé de supprimer la stratégie du GAC et j'ai redémarré ma machine.Cela a finalement fonctionné.Cela ne semble pas être un développement de solution confortable, mais cette politique a cassé l'une de mes applications, ce qui signifie que la désactivation de la politique est la bonne chose à faire dans mon cas.


Modification finale :

Igor m'a donné la bonne réponse.Tout ce que j'avais à faire pour contourner ces politiques était d'utiliser le publisherPolicy réglage dans la bonne section de configuration :

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/>
      <publisherPolicy apply="no"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>
Était-ce utile?

La solution

Après avoir modifié votre question, il devient clair que c'est le fichier de stratégie qui affecte la liaison d'assembly.

Dans le cas d'Oracle, il existe un fichier appelé Policy.X.Y.Oracle.DataAccess.config avec un contenu similaire à celui-ci :

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/>
            <bindingRedirect oldVersion="10.1.0.000-10.2.0.100" newVersion="10.2.0.100"/>
        </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

La stratégie est installée par le programme d'installation d'Oracle et redirige Oracle.DataAccess.dll à la dernière version, car Oracle estime que la bibliothèque est rétrocompatible.

MODIFIER:Si vous ne souhaitez pas que les règles relatives aux éditeurs soient appliquées pour une assemblée particulière, mettez l'élément dans l'élément :

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="myAssembly" publicKeyToken="..."  culture="en-us" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
            <publisherPolicy apply="no" />
    </dependentAssembly>
</assemblyBinding>
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top