visual-studio - visual - vs code autoclose html
¿Hay alguna forma de determinar qué versión de Visual Studio se usó para compilar una biblioteca estática? (5)
Tengo una colección de archivos de bibliotecas estáticas (.lib), uno de los cuales puede haber sido creado con una versión diferente de Visual Studio. Esto está causando que la generación de código de un proyecto que enlaza contra todos ellos falle. ¿Hay alguna forma de determinar qué versión de Visual Studio se utilizó para compilar una biblioteca estática?
No especificó el idioma, pero en C # la respuesta para conocer la versión del sistema operativo y .NET (en su código en tiempo de ejecución) es:
System.Version osVersion = System.Environment.OSVersion;
System.Version cliVersion = System.Environment.Version;
Habría un equivalente en Managed C ++ / CLI
Eso no le dirá la versión del compilador o del IDE , pero le dirá la versión de los tiempos de ejecución de .NET. Puede que necesite o no saber la versión del sistema operativo.
-Jesse
Para las bibliotecas de versiones, es poco probable que pueda determinar la versión.
Para las bibliotecas de depuración, puede usar dumpbin :
dumpbin /rawdata:1 library.lib
El manifiesto del ensamblaje debe estar al principio del volcado y contendrá la versión del CRT que la biblioteca requiere junto con la ruta completa al compilador utilizado para construir la biblioteca.
Para los archivos ejecutables y los archivos DLL, puede obtener la versión del vinculador utilizando el dumpbin; está bajo "VALORES OPCIONALES DE LA CABEZA"
dumpbin /headers program.exe
Tal vez alguien más sepa de una manera de obtener la versión para las bibliotecas de lanzamiento; Ciertamente estoy interesado también si lo son.
Si la biblioteca estática se escribió en C ++ y se creó con MSVC 2010 o una versión más reciente, el compilador puede haber colocado una directiva FAILIFMISMATCH en los archivos de objetos.
No puedo encontrar el documento oficial de Microsoft sobre la directiva FAILIFMISMATCH, pero parece que el enlazador lo utiliza para detectar incompatibilidades entre las versiones de la biblioteca estándar de C ++.
Puede usar el siguiente comando para imprimir esas directivas desde una biblioteca estática:
find "FAILIFMISMATCH" xyz.lib
(o use la forma que ha mencionado mheyman si prefiere en cygwin o msys)
El resultado puede ser similar a este:
0@ /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"
Tenga en cuenta la primera directiva: "_MSC_VER = NNNN". En mi observación, la NNNN siempre coincide con la versión del compilador utilizada para crear el archivo objeto. En mi caso, xyz.lib se creó con la actualización 3 de MSVC 2015, su versión del compilador de C ++ es 19.00.24215, por lo que puso / FAILIFMISMATCH: "_ MSC_VER = 1900" en el archivo objeto.
Una asignación detallada entre la versión de Visual Studio y la versión del compilador de Microsoft C / C ++ se puede encontrar aquí .
Si tiene los archivos .PDB correspondientes, puede ver la versión del compilador desde allí con una herramienta como Pdb Inspector .
O abra el PDB en un visor hexadecimal y busque la cadena "Microsoft (R) Optimizing Compiler". La versión estará en cuatro valores hexadecimales de 2 bytes justo antes de esa cadena, como en este ejemplo:
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 versión es, por lo tanto, HEX 13 00, 00 00, 6E 5D, 00 00 o 19.0.23918.0.
Siempre he usado algo como (en una ventana de cygwin):
strings -f *.lib | grep ''Visual Studio''
El compilador pega la ruta del compilador en la biblioteca en las compilaciones de depuración y la ubicación predeterminada del compilador de Visual Studio se encuentra en una ruta que incluye el texto ''Visual Studio''.
Entonces, al igual que la respuesta de James McNellis, esto también funciona solo para compilaciones de depuración y está más restringido a las compilaciones que en realidad usan un compilador que se encuentra en un directorio con ''Visual Studio # '' en la ruta.
Encontré este método hace años a través de un poco de serendipia y todavía tiene que fallar.
Esto tiene la ventaja de que es fácil de recordar si está familiarizado con las herramientas de línea de comandos de Unix.