Discussion :

[khelkun]

Bonjour,

J'ai fait quelques recherches sur le forum et trouvé certains threads qui traitent de problèmes de manifestes (embarqués ou non) et deux reportant l'erreur qui s'oppose à moi : side-by-side configuration error
Je commence tout juste à cerner le problème et ne serait pas contre un peu d'aide pour qui aura le courage de lire ce qui suit.

Description du problème
Nous avons une application dont le core est en C++ compilé sous VS2005 SP1. L'ensemble de l'application et de de l'installeur livrés à nos clients sont compilés sur un serveur dédié sous un WinXP SP3 32bits.

Il y a 3 mois les mise à jours windows semi-auto de nos stations de développement ont été désactivées et verrouillées par l'admin sys.
Mais pas celles de notre serveur de compilation, où elles sont restées en semi-auto.Nous avons installé les mises à jour windows du serveur de compilation il y a une semaine.
Depuis l'application compilée par ce serveur, semble poser des problèmes de linkage sur les librairies MSVC. Librairies qu'on pense déployer comme des private assemblies :

• Deploying Visual C++ library DLLs as private assemblies : http://msdn.microsoft.com/en-us/libr...91(VS.80).aspx

Lorsqu'on exécute l'application déployée sur certains postes on obtient une erreur de type side-by-side configuration:

Error: The Side-by-Side configuration information for "c:\program files\myapplication\CLIENT_R.EXE" contains errors. Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller l'application pourrait résoudre ce problème (14001).

Sur cette erreur dependency walker montre que l'application a deux liens vers la MSVCR80.dll :

• c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8ca\MSVCR80.DLL
• c:\program files\myapplication\MSVCR80.DLL (version: 8.0.50727.762)

Contenu du manifeste que nous copions dans le dossier d'installation de l'application (Microsoft.VC80.CRT.manifest):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable></noInheritable>
    <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    <file name="msvcr80.dll" hash="10f4cb2831f1e9288a73387a8734a8b604e5beaa" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>n9On8FItNsK/DmT8UQxu6jYDtWQ=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcp80.dll" hash="b2082dfd3009365c5b287448dcb3b4e2158a6d26" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>0KJ/VTwP4OUHx98HlIW2AdW1kuY=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcm80.dll" hash="542490d0fcf8615c46d0ca487033ccaeb3941f0b" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>YJuB+9Os2oxW4mY+2oC/r8lICZE=</dsig:DigestValue></asmv2:hash></file>
</assembly>

Ainsi que les DLLs suivantes : msvcm80.dll, msvcp80.dll, msvcr80.dll

L'installeur que nous générons sur nos machines de développement semble toujours fonctionner correctement, partout où il a été testé. Dans ce cas dependency walker montre que l'application a un seul lien sur la MSVCR80.dll (celle du sous dossier de C:\WINDOWS\WinSxS).

Analyse des origines du problèmes

La configuration de tous les projets VS2005 ont l'option Embedded Manifest activée.

Il est plus que probable que notre stratégie de déploiement des librairies Visual C++ est erronée et que les mises à jour windows ont mis évidence le problème sur la configuration MasterRelease de notre solution VS2005.

Solutions envisagées

• Désinstaller KB971090 installé sur le VS2005 SP1 du serveur de compilation il y a une semaine n'a fait que produire aussi le problème sur la configuration Release de la solution VS2005. Mauvaise solution
  
• Chercher à comprendre mieux les dépendences de notre application vers les librairies du runtime Visual C++.
  
• Réinstaller notre agent de compilation Bamboo sur une machine vierge, ainsi que tout l'environnement de développement.

Votre avis m'intéresse beaucoup, quel qu'il soit. Merci de votre attention.

[bacelar]

On ne devrait jamais avoir 2 C-Runtime en même temps.
Dependency Walker devrait donner la liste des points d'entré dans chacune des dll. Vous devriez trouvez, avec les noms de ces points d'entrée, la partie du code qui est liée à la mauvaise dll, non ?

[khelkun]

Merci pour le conseil, c'est vrai que je n'avais pas bien observé les dépendences dans dependency walker et je vois un peu mieux la source du problème.

Quoiqu'il en soit, la réinstallation de VS2005 SP1 sans installer les autres correctifs de sécurité semble avoir restabiliser la procédure de déploiement après un bon gros rebuild all.

Cependant j'aimerais bien comprendre ce qui s'est passé.

On ne devrait jamais avoir 2 C-Runtime en même temps.

Ca paraît naturel en effet. Corrigez moi si je me trompe :
MSVCR80.dll version 8.0.50727.3053 == VC++ runtime distribué avec VS2005
MSVCR80.dll version 8.0.50727.762 == VC++ runtime distribué avec VS2005 SP1
Est ce que le correctif KB971090 a pu changer la version du C runtime utilisée par mon VS2005 SP1 quand il effectue le linkage de mon client_r.exe ?

Vous devriez trouvez, avec les noms de ces points d'entrée, la partie du code qui est liée à la mauvaise dll, non ?

C'est là que j'ai du mal :

• Pour Client_r.exe on voit un link sur MSVCR80.dll version 8.0.50727.762 (from application installation directory)
• LUA5.1.dll, linké par Client_r.exe, link aussi MSVCR80.dll version 8.0.50727.762 (from application installation directory)
• D'autre part Client_r.exe link LIBCURL.dll qui a aussi un lien sur MSVCR80.dll mais en version 8.0.50727.3053 (from WinSxS)

Finalement j'aimerais déjà savoir si l'erreur side-by-side configuration (14001) vient du fait que LIBCURL utilise une version antérieure de MSVCR80.dll ?
Si vous avez la réponse merci infiniment d'avance

[TkSand]

J'ai exactement le même problème avec notre application : Le nouvel .exe recompilé ne fonctionne plus sur les postes clients.
Grâce au message de khelkun, j'ai pu trouvé l'origine du problème :
Effectivement suite à la mise à jour de VC 2005 en juillet 09 (KB971090), les versions des modules MFC 8 ont changé pour la version 8.0.50727.4053.
Voici les solutions que j'ai pu trouvé :
1. Mettre à jour les MFC 8 sur les postes clients en utilisant le BON vcredist_x86.exe (que vous pouvez trouver sur le posete dev dans (C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86)
Cette solution nous permet de dépanner des clients temporairement.
Le problème est que le merge module correspondant à cette version de MFC n'est pas encore disponible (en tout cas je ne l'ai pas trouvé !) donc je ne peux pas l'intégrer avec l'installation complète de nos produits.

2. Installer un PC de compil où les mises à jour sont désactivées : cette solution n'est pas pratique car l'environnement de compil ne sera pas le même que celui des développeurs

3. J'ai trouvé un article avec un moyen pour forcer l'utilisation des MFC 8 version 762, voici le lien :
http://tedwvc.wordpress.com/2009/08/...date-kb971090/
Nous allons essayer cette solution aujourd'hui en espérant que cela fonctionne car ce serait la solution la plus "propre" pour nous et en plus nous n'avons pas besoin des MAJ de MFC 8.

Mais en tout cas merci à Microsoft pour ses mises à jour qui nous mette à dans la m....

[khelkun]

Merci de partager ma souffrance

http://www.installsite.org/pages/en/tt_app.htm

LoadLib et ShowDep ne m'ont pas apporté grand chose de plus que dependency walker. De plus il n'est pas impossible que ces outils fournissent des infos erronées en fonction de la version utilisée, de l'OS, du service pack, etc ...

Ne blamons pas microsoft. Certes la gestion du linkage sur les OS windows est complexe, mais je pense qu'en ce qui nous concerne il s'agit avant tout d'un manque de connaissance et de maîtrise sur les DLLs, les manifestes et autres concepts associés.

Je suis entrain de revoir toutes les config de nos projet VS2005 et en particulier ce qui touche au C Runtime Libraries. Le vc_redist_x86 reste sans doute la solution la plus simple si on choisi le ou les bons

si j'apprends d'autres choses intéressantes je compléterai ce thread

ADD
Be aware about that : Linker Tools Warning LNK4098
http://msdn.microsoft.com/en-gb/libr...k0(VS.80).aspx

The End of DLL Hell
http://msdn.microsoft.com/en-us/library/ms811694.aspx

"Moi j'dis qu'il bluff"

et Merci pour le lien sur le KB !!!