2009-09-11 5 views
20

J'ai une collection de bibliothèques statiques (.lib) dont l'une peut avoir été construite avec une version différente de Visual Studio. Cela provoque l'échec de la génération de code d'un projet qui est lié à tous les projets. Est-il possible de déterminer quelle version de Visual Studio a été utilisée pour compiler une bibliothèque statique?Existe-t-il un moyen de déterminer quelle version de Visual Studio a été utilisée pour compiler une bibliothèque statique?

+3

Une meilleure question à poser est la version du compilateur. Il est possible de compiler des bibliothèques statiques C++ sans l'utilisation de Visual Studio. – JaredPar

+0

Assez juste. Dans mon cas, ils sont tous compilés avec une version de Visual Studio. Il y a une question plus générale qui se cache cependant. –

Répondre

20

Pour les bibliothèques de versions, il est peu probable que vous puissiez déterminer la version.

Pour les bibliothèques de débogage, vous pouvez utiliser dumpbin:

dumpbin /rawdata:1 library.lib 

Le manifeste de montage devrait être au début de la décharge et contiendra la version du CRT la bibliothèque exige ainsi que le chemin complet vers le compilateur utilisé pour construire la bibliothèque.

Pour les exécutables et les DLL, vous pouvez obtenir la version de l'éditeur de liens en utilisant dumpbin; il est sous la rubrique « EN OPTION VALEURS Entête »

dumpbin /headers program.exe 

quelqu'un Peut-être sait d'autre d'une façon d'obtenir la version pour les bibliothèques de libération; Je suis certainement intéressé aussi s'ils le sont.

+0

Pouvez-vous partager quelques détails sur où trouver cet outil ou, si ce n'est pas disponible par défaut avec l'installation de Visual Studio, d'où nous pouvons l'obtenir? –

+0

L'approche 'dumpbin/headers program.exe' ne fonctionne-t-elle pas avec les binaires de version? Je l'ai essayé et cela a fonctionné. – stackoverflowwww

5

J'ai toujours utilisé quelque chose comme (dans une fenêtre Cygwin):

strings -f *.lib | grep 'Visual Studio' 

Le compilateur colle le chemin du compilateur dans la bibliothèque de debug et l'emplacement par défaut du compilateur Visual Studio est sous un chemin Cela inclut le texte "Visual Studio".

Alors, comme James McNellis de réponse, cela fonctionne aussi que pour le débogage construit et est en outre limité aux builds qui utilise en fait un compilateur qui se trouve dans un répertoire avec « Visual Studio # » dans le chemin.

J'ai trouvé cette méthode il y a des années grâce à un peu de sérendipité et elle n'a pas encore échoué.

Ceci a l'avantage qu'il est facile de se rappeler si vous êtes familier avec les outils de ligne de commande Unix.

-2

Vous n'avez pas spécifié la langue, mais en C# la réponse pour connaître le système d'exploitation et la version .NET (dans votre code à l'exécution) est:

System.Version osVersion = System.Environment.OSVersion; 
System.Version cliVersion = System.Environment.Version; 

Il y aurait un équivalent en C++ géré/CLI

Cela ne vous dira pas la verison du compilateur ou de l'IDE , mais vous dira la verison des runtimes .NET. Vous pouvez ou ne pas avoir besoin de connaître la version du système d'exploitation.

-Jesse

+0

Ce n'est même pas lié à distance à la question posée. Bien qu'il n'y ait pas de langage spécifié dans la question (ce qui est correct, étant donné la question), il parle de bibliothèques statiques. Les bibliothèques statiques impliquent du code natif. La question est essentiellement de savoir quelle version d'exécution est compilée dans le code binaire. La version OS n'a aucun intérêt ici. – IInspectable

3

Si vous avez les fichiers correspondants .PDB vous pouvez voir la version du compilateur à partir de là avec un outil comme Pdb Inspector.

Ou ouvrez la PDB dans une visionneuse hexadécimale et recherchez la chaîne "Microsoft (R) Optimizing Compiler".La version sera en quatre valeurs hexa 2 octets juste avant cette chaîne, comme dans cet exemple:

000000A060: .. .. .. .. .. .. . ... .. .. .. .. .. .. 13 00    .. 
000000A070: 00 00 6E 5D 00 00 4D 69 63 72 6F 73 6F 66 74 20 ......Microsoft 
000000A080: 28 52 29 20 4F 70 74 69 6D 69 7A 69 6E 67 20 43 (R) Optimizing C 
000000A090: 6F 6D 70 69 6C 65 72 00 .. .. .. .. .. .. .. .. ompiler ........ 

La version est donc HEX 13 00, 00 00, 6E 5D, 00 00, ou 19.0.23918.0.

0

Si la bibliothèque statique a été écrite en C++ et a été construite avec MSVC 2010 ou une version plus récente, une directive FAILIFMISMATCH peut avoir été placée par le compilateur dans les fichiers objets.

Je ne trouve pas le document officiel de Microsoft à propos de la directive FAILIFMISMATCH, mais il semble être utilisé par l'éditeur de liens pour détecter les incompatibilités entre les versions de la bibliothèque standard C++.

Vous pouvez utiliser la commande suivante pour imprimer ces directives à partir d'une bibliothèque statique:

find "FAILIFMISMATCH" xyz.lib 

(ou utiliser la manière dont mheyman a mentionné si vous privilégiez dans Cygwin ou MSYS)

Le résultat peut être similaire à ceci:

[email protected] /FAILIFMISMATCH:"_MSC_VER=1900" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=0" /FAILIFMISMATCH:"RuntimeLibrary=MD_DynamicRelease" /DEFAULTLIB:"msvcprt" /FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" 

Notez la première directive: "_MSC_VER = NNNN". Dans mon observation, le NNNN correspond toujours à la version du compilateur utilisée pour créer le fichier objet. Dans mon cas, le xyz.lib a été créé avec MSVC 2015 mise à jour 3, sa version du compilateur C++ est 19.00.24215, donc il a mis/FAILIFMISMATCH: "_ MSC_VER = 1900" dans le fichier objet.

Un mappage détaillé entre la version de Visual Studio et la version du compilateur C/C++ de Microsoft peut être trouvé at here.

Questions connexes