Déboguer l'application Build en localisant les assemblages de CRT

Question

Nous avons une application C++ que j'ai récemment portée de Linux/gcc pour construire sous Windows avec Visual Studio 2005. L'application utilise une bibliothèque tierce qui fournit uniquement des DLL utilisant la DLL CRT optimisée (c'est-à-dire qu'ils ne fournissent pas d'équivalents qui se lient à la DLL CRT de débogage). Avec VS2005 cela ne semble pas être un problème = la construction de débogage a trouvé la DLL CRT optimisée dans le répertoire System32.

Je suis maintenant en train d'essayer de créer et d'exécuter notre application avec VS2008 et la construction de débogage ne peut pas s'exécuter car elle ne trouve pas la DLL CRT optimisée (msvc690.dll). Les DLL VC9 CRT sont stockées dans des répertoires avec un nom de style GUID - je crois que c'est un assemblage côte à côte et l'application est censée le localiser en utilisant le manifeste de l'application. Cependant, le manifeste qui se construit et intégré dans l'application exe spécifie que l'ensemble CRT de débogage:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?> 
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> 
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
    <security> 
     <requestedPrivileges> 
     <requestedExecutionLevel level='asInvoker' uiAccess='false' /> 
     </requestedPrivileges> 
    </security> 
    </trustInfo> 
    <dependency> 
    <dependentAssembly> 
     <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> 
    </dependentAssembly> 
    </dependency> 
</assembly> 

Je ne suis pas un expert de Windows (pas plus au moins) si cela est nouveau pour moi. Quelle est la bonne solution ici? Dois-je indiquer au compilateur de manifeste d'ajouter la DLL CRT optimisée à l'assembly? Si oui, comment puis-je faire cela?

Answer 1

Ok. Si vous ouvrez la DLL de la bibliothèque tierce dans VS 2008 (assurez-vous qu'elle choisit OpenWith> Editeur de ressources), contient-elle un manifeste?

Si c'est le cas, ou même si ce n'est pas le cas, il est également utile d'obtenir DependencyWalker pour voir à quelle DLL d'exécution exacte tente de se lier.

Le fait qu'il a travaillé avec VS2005, et non VS2008, implique la dll veut utiliser les versions releasemode du moteur d'exécution VS2005: Msvcr80.dll

Vous mentionnez msvc690.dll, qui ne sonne pas une cloche avec moi: Visual Studio 6 utilisait simplement le msvcrt.dll nommé - la première version de Visual Studio pour utiliser une version dll runtime était VS 2003 .NET ou quelque chose: msvcrt7.dll

De toute façon, si la bibliothèque 3ème partie ne fonctionne pas contient sa propre ressource manifeste, la solution la plus simple consiste à ajouter les références d'assembly dépendantes à votre manifeste d'applications.

Il y a plusieurs façons de le faire - vous pouvez créer un fragement manifeste sous forme de fichier XML et l'ajouter à vos applications « Propriétés de configuration> Outil Manifest> Entrée et sortie> Manifest d'autres fichiers »

I trouver le moyen le plus pratique de fusionner des directives d'assemblage dépendantes supplémentaires dans VS2008 est d'utiliser l'option de ligne de commande linkers/manifestdependency.

Si vous ajoutez le code suivant dans un fichier dans votre projet, il donnera l'éditeur de liens l'indication nécessaire:

#define X_CRT_ASSEMBLY_VERSION "9.0.21022.8" 
#pragma comment(linker,"/manifestdependency:\"type='win32' "\ 
    "name='"Microsoft.VC80.CRT' " 
    "version='8.0.??.??' "       \ 
    "processorArchitecture='x86' "         \ 
    "publicKeyToken='????????'\"") 

sont là de l '?? parce que je ne connais pas les numéros de version ou jeton de clé publique des bibliothèques VS2005 en main. Si vous pouvez les regarder et les remplir, il devrait aller nager.