visual - dependencia msvcr90.dll en el proyecto VS 2005 C++

microsoft visual c++ 2005 x64

Question

Creé un proyecto DLL en VS 2005 para Win32 nativo / C ++ no administrado, llámalo myProj.dll. Depende de una DLL comercial de terceros que a su vez depende de msvcr90.dll (supongo que fue creada a partir de un proyecto de VS 2008). Lo llamaré thirdParty.dll.

Mi proyecto DLL se compila muy bien en VS2005. Creé una aplicación de prueba (de nuevo, VS 2005 Win32 C ++) que enlaza con myProj.lib. (Por otro lado, a juzgar por el tamaño pequeño de la .lib y por el hecho de que, en tiempo de ejecución, la aplicación debe ubicar myProj.dll, supongo que la .lib es solo un contenedor para una llamada a loadLibrary () que carga el DLL real, ¿está cerca?)

Mi problema es que, en tiempo de ejecución, la aplicación de prueba no puede ubicar msvcr90.dll (ni msvcp90.dll), cuya dependencia proviene de thirdParty.dll.

He instalado el paquete de redist de Microsoft y también todas las bibliotecas de C ++ estándar (9.0) en c: / WINDOWS / WinSxS / x86_Microsoft.VC90.CRT _.... Además, si señalo el ladrón de dependencias en thirdParty.dll, felizmente resuelve las referencias a esa ubicación.

Pero, si señalo depends.exe en mi aplicación de prueba (.exe) o myProj.dll, no se encuentran msvcr90.dll y msvcp90.dll.

Supongo que hay algo que debo configurar en VS2005 para que el archivo .exe o myProj.dll conozcan la ubicación de las versiones 9.0 de las bibliotecas std C ++ (presumiblemente donde el paquete de redistribución las instaló en C: / WINDOWS / WinSxS ), pero parece que no puedo descifrar de qué se trata. ¿Estoy en el camino correcto?

Observo que, si simplemente copio los archivos msvc * 90.dll en el directorio de mi aplicación, entonces la dependencia se resuelve, pero obtengo el error en tiempo de ejecución sobre la carga incorrecta de archivos DLL estándar de cd, etc.

Gracias inmensamente por adelantado.

Answer 1

Esto se parece a un problema de "Conjuntos lado a lado" .

Por lo que puedo decir, Microsoft en un intento de detener el DLL Los problemas del infierno de los últimos años han introducido un concepto de "Asambleas lado a lado".

En pocas palabras, significa que su aplicación necesita decirle a Windows con qué versión del CRT se diseñó para que funcione. Cuando se instala la aplicación, Windows se asegurará de que la aplicación obtenga su propia copia privada de estos archivos DLL.

Para que todo funcione, debe incrustar las dependencias DLL de la aplicación en el archivo Manifest de la aplicación y adjuntarlo al proyecto utilizando la sección Manifest Tool , Input and Output de la configuración del proyecto de la aplicación.

Como ejemplo, aquí está el manifiesto que uso para el IDE de Zeus para Windows :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Xidicone.Windows.Zeus for Windows"
version="3.9.6.69"
processorArchitecture="X86"
type="win32" />
<description>Zeus for Windows</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50608.0"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
</assembly>

Finalmente, si planea crear un instalador, deberá agregar las mismas versiones de estos archivos DLL al instalador de la aplicación o, alternativamente, hacer que el instalador ejecute el instalador redistribuible de Microsoft CRT.

FWIW Solo me enteré de esto cuando un usuario informó que Zeus ya no se ejecutaba en Windows XP debido a que faltaba un archivo DLL de tiempo de ejecución MSVCRT, pero Zeus había estado funcionando bien durante más de 10 años sin tener que enviar un archivo DLL de tiempo de ejecución MSVCRT. .

Answer 2

Le preguntaría a la gente de tercera parte sobre esto.

Answer 3

Tengo el mismo problema hace algunos días. myProj.dll depende de un thirdParty.dll, que usa msvcr90. Si construyo un test.exe usando myProj.dll directamente, está bien. Pero si uso loadLibrary (myProj.dll) en test.exe, la llamada simplemente fallará. Lo mismo ocurriría si pruebo loadLibrary (myProj.dll) en un programa Java.

Después de algunas investigaciones e investigaciones en Internet, los siguientes pasos han resuelto mi problema.

1. Asegúrese de que NO msvcr90 esté en la RUTA. Puede usar el explorador de procesos (procexp.exe de SystemInternals) para descubrir todos los msvcr90 actualmente cargados en su entorno. De hecho, a partir de VC 2005, las bibliotecas de tiempo de ejecución de C solo deben instalarse en la Caché de ensamblados global (/ winsxs ....), ni siquiera en Windows o Windows / System32.

2. incrustar el manifiesto dll en myProj.dll. Después de que cl.exe y link.exe produzcan myProj.dll, también se produce un manifiesto correspondiente. A continuación, utilice mt.exe -inputresource myProj.dll.manifest -out myProj.dll; 2

Lo anterior resuelve mi problema, espero que pueda ser de alguna ayuda para usted. Por cierto, estoy usando VC 2008 en Windows 2008 R

Answer 4

¿Instaló la versión SP1 del rediseño msvc 2008?

No es un problema si depends.exe no puede encontrar msvcr90.dll. Si utiliza el instalador de Microsoft, se instalará automáticamente en la ubicación correcta y se encontrará si se ejecuta su aplicación. No ayuda si copia los dll''s al directorio de su aplicación si no crea un manifiesto.

¿Pero puede decir el mensaje de error exacto que recibe?

También puede echar un vistazo aquí y aquí con respecto al manifiesto.