SidBySide: Une tierce partie DLL fait référence à deux versions de MSVCR80.DLL

Nous incluons une lib + tierce DLL qui pose récemment beaucoup de problèmes lors de l’installation. En utilisant dependencywalker , nous avons constaté que la dll elle-même fait référence à deux versions différentes de

MSVCR80.DLL: Version 8.0.50727.4053 and Version 8.0.50727.42 

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

Dans la plupart des cas, l’installation ne pose aucun problème, même si nous ne dissortingbuons 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 système Windows à partir du 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 nous avons maintenant 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 à part cela, je préférerais une solution beaucoup plus simple. Est-ce que quelqu’un connaît une solution de contournement?

Puis-je en quelque sorte utiliser une seule version de la Dll?

EDIT: J’ai maintenant essayé le conseil cristians:

 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 visualise les dépendances des dll avec des chemins complets, je vois ce qui suit: alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg

Le MSVCR80.DLL inférieur est celui avec la Version … 42. Je ne comprends pas cela. Pourquoi MSVC P 80.DLL fait-il référence à une version différente de celle de MSVC R 80.DLL? Est-ce que c’est peut-être un problème de dependencywalker?

Votre meilleure option est d’expédier les DLL nécessaires dans le 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 ici . C’est également la version à laquelle votre DLL est liée. Vous pouvez lancer le package redissortingbuable en mode silencieux à partir de votre programme d’installation.

Pour contourner manuellement les systèmes déjà installés, appliquez simplement l’installateur Redist sur la machine cible.

Si vous choisissez cette méthode, vous n’avez pas à craindre les conflits de versions, car les applications dépendant d’anciennes versions seront redirigées pour utiliser toujours la plus récente.

Pour une meilleure compréhension, consultez les articles MSDN .

Vous devez changer / mettre à jour la ressource 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) ne possède pas l’index n ° 1 dans la table de ressources, vous devez utiliser un visualiseur de ressources ( ResourceHacker ou ResEdit ) et rechercher le numéro d’index. J’ai vu des cas où le manifeste porte le numéro d’index n ° 2.