Échec de la liaison d'assemblage .NET (différentes versions avec redirection), bizarre!

Question

J'essaye de dépanner une application construite contre la version 9.1 des bibliothèques d'un fournisseur sur une machine qui a leur version 9.3 installée. Le fournisseur a fourni un fichier de stratégie d'éditeur qui redirige toutes les versions à partir de la version 9.0 vers leurs dll 9.3, et il est installé dans le GAC.

Avec une version plus récente de notre application, construite contre la version 9.2, le fichier de politique de l'éditeur est trouvé et tout fonctionne. Avec la version 9.1-linked, le fichier de politique de l'éditeur n'est jamais mentionné du tout dans les résultats fuslogvw.

Voici un exemple d'une charge réussie de fuslogvw:

LOG: This bind starts in default load context. 
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe.Config 
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config. 
LOG: Publisher policy file is found at C:\WINDOWS\assembly\GAC_MSIL\policy.9.2.ESRI.ArcGIS.System\9.3.0.1770__8fc3cc631e44ad86\ESRI.ArcGIS.System.config. 
LOG: Publisher policy file redirect is found: 9.2.0.1324 redirected to 9.3.0.1770. 
LOG: ProcessorArchitecture is locked to MSIL. 
LOG: Post-policy reference: ESRI.ArcGIS.System, Version=9.3.0.1770, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86, processorArchitecture=MSIL 
LOG: Found assembly by looking in the GAC. 
LOG: Binding succeeds. Returns assembly from C:\WINDOWS\assembly\GAC_MSIL\ESRI.ArcGIS.System\9.3.0.1770__8fc3cc631e44ad86\ESRI.ArcGIS.System.dll. 
LOG: Assembly is loaded in default load context. 

Et, voici l'échec:

LOG: This bind starts in default load context. 
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe.Config 
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config. 
LOG: Post-policy reference: ESRI.ArcGIS.System, Version=9.1.0.722, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86 
LOG: GAC Lookup was unsuccessful. 
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System.DLL. 
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System/ESRI.ArcGIS.System.DLL. 
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System.EXE. 
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System/ESRI.ArcGIS.System.EXE. 
LOG: All probing URLs attempted and failed. 

Remarque: le nom d'affichage, la culture et les jetons de clé publique sont identiques .

Alors, qu'est-ce qui est différent (en plus de la version #)? Pourquoi .NET ne trouve-t-il pas le fichier de stratégie? Quelle magie noire faudra-t-il faire pour surmonter cela (jusqu'à ce que nous puissions simplement abandonner notre support pour leur plate-forme 9.1)?

Answer 1

Ah, la magie de l'affichage de vos problèmes sur Internet:

Il semble que le chemin d'accès au fichier de stratégie comprend la chaîne de version « 9.2 » dans le cadre d'un nom de dossier, que je suis ne peut assumer signifie qu'il ne sera résolu que pour les demandes de la version 9.2 des bibliothèques du fournisseur. Il semble donc incomplètement installé (puisque le fichier de politique lui-même redirige la version 9.0 à partir de la version 9.0.1).

Nous pourrions inclure les redirections dans un fichier de configuration d'application, comme décrit here; bien qu'il devrait être conditionnel à quelle version du logiciel du fournisseur est présent. J'avoue que je ne suis pas trop excité à ce sujet comme solution ...