SidBySide: Dll 3ème partie se réfère à deux versions de MSVCR80.DLL

Question

Nous incluons une bibliothèque DLL + 3rd Party qui a récemment causé beaucoup de problèmes sur les installations. En utilisant dependencywalker, nous avons constaté que la dll se réfère à deux différentes versions de

MSVCR80.DLL: 
Version 8.0.50727.4053 and 
Version 8.0.50727.42 

alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg

Dans la plupart des cas l'installation fait aucun problème, même si nous diffusons aucune des deux versions. Mais dans un certain nombre de cas, notre installation ne démarre tout simplement pas. Nous trouvons ensuite des messages dans le journal des événements du système Windows depuis le gestionnaire SideBySide: "La version de la DLL ne correspond pas". Dans la plupart des cas, ce problème peut être résolu en installant le framework .NET (bien que nous ne l'utilisions pas). Mais maintenant nous avons un cas où cela n'aide pas.

Je sais qu'une solution serait, d'installer les deux versions en tant qu'assemblage partagé, mais cela ne semble pas être facile, et en plus de cela, je préférerais une solution beaucoup plus simple. Est-ce que quelqu'un sait une solution de contournement? Puis-je d'une manière ou d'une autre utiliser une seule version de la DLL?

EDIT: Je maintenant essayé cristians conseil:

D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest 
Microsoft (R) Manifest Tool version 5.2.3790.2075 
Copyright (c) Microsoft Corporation 2005. 
All rights reserved. 

mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found. 

Si je considère les dépendances dll avec les chemins complets, je vois les suivantes: alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg

Le Msvcr80.dll inférieur est le un avec la Version ... 42. Je ne comprends pas ça. Pourquoi MSVC P 80.DLL fait-il référence à une version différente de MSVC R 80.DLL à celle d'ailleurs? Est-ce peut-être un problème du Dependencywalker?

Answer 1

Votre meilleure option consiste à expédier les DLL nécessaires dans votre package d'installation d'applications. Utilisez au moins la version dont dépend votre DLL tierce.

Microsoft propose des programmes d'installation autonomes pour ses DLL d'exécution (vcredits_ *). La dernière version de VisualStudio 2005 peut être téléchargée here. C'est aussi la version avec laquelle votre DLL est liée. Vous pouvez lancer le package redistribuable depuis votre installateur en mode silencieux.

Comme solution de contournement manuelle pour les systèmes déjà installés, il suffit d'appliquer le programme d'installation redist sur la machine cible.

Si vous choisissez cette méthode, vous n'avez pas besoin d'avoir peur des conflits de version, car les applications qui dépendent d'une version plus ancienne seront redirigées pour toujours utiliser la plus récente.

Pour une meilleure compréhension, regardez MSDN articles.

Answer 2

Vous devez modifier/mettre à jour la ressource du manifeste à partir des DLL.

mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1

Parfois, le type de ressource RT_MANIFEST (type 24) n'a pas l'index n ° 1 dans le tableau des ressources, vous devez utiliser une visionneuse de ressources (ResourceHacker ou ResEdit) et découvrir l'index nombre. J'ai vu des cas où le manifeste a le numéro d'index # 2.