2008-12-01 21 views
7

He creado un proyecto DLL en VS 2005 para C++ nativo Win32/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.dependencia de msvcr90.dll en el proyecto VS 2005 C++

Mi proyecto DLL se compila perfectamente 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; ¿es así de cerca?)

Mi problema es que, en tiempo de ejecución, la aplicación de prueba no puede encontrar msvcr90.dll (ni msvcp90.dll), cuya dependencia deriva del 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, msvcr90.dll y msvcp90.dll no se encuentran.

Supongo que hay algo que debo configurar en VS2005 para que el .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 copiar los archivos * 90.dll msvc a mi directorio de aplicación, a continuación, la dependencia se ha resuelto, pero me sale el error de tiempo de ejecución sobre la carga incorrecta de std C++ DLL, etc.

Gracias inmensamente por adelantado.

Respuesta

1

Me gustaría preguntarle a las personas dll de terceros sobre esto.

+0

Quizás esa sea la mejor manera. Sin embargo, puede haber algo corrupto. Si ese es el caso, intente con una instalación limpia de Windows (vmware). De esa manera, puede escribir todo lo que está haciendo para explicarles los pasos para reproducir este problema. – wimh

+0

Gracias, Wimmel. Sí, eso es lo que estoy pensando que haré hoy. Y, también estoy en contacto con la gente de terceros. Por cierto, una cosa que he olvidado mencionar es que en realidad hay un tercer componente: una biblioteca enlazada estáticamente (.lib) de otra tercera parte. Incluye el clib. –

+0

(límite de caracteres tontos!) ... y entonces me veo forzado a compilar myProj.dll con/MT (d) (nuevamente, con VS2005). –

2

¿Ha instalado el SP1 version del rediseño msvc 2008?

No es un problema si depends.exe no puede encontrar msvcr90.dll, si utiliza el instalador de Microsoft, se instala 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 here y here con respecto al manifiesto.

+0

Instalé la versión SP1 de la redista de msvc 2008. El mensaje de error exacto es "la aplicación no se pudo iniciar porque no se encontró msvcr90.dll. Reinstalar la aplicación ..." Esto ocurre cuando construyo una aplicación que usa myProj.dll. –

+0

Quizás este hilo: http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/6d16ecce-f92b-4c53-a45b-40119c4566a6/ le puede dar cierta información para resolver el problema. – wimh

6

Esto se parece a un "Uniones de lado a lado" problema para mí.

De lo que puedo decir, Microsoft, en un intento de detener el DLL Infierno problemas de los últimos años ha introducido un concepto de "lado a lado" Asambleas.

En una cáscara de nuez significa que su aplicación tiene que decirle de Windows qué versión del CRT que fue diseñado para trabajar con ellos. Cuando se instala la aplicación, Windows se asegurará de que la aplicación obtenga su propia copia privada de estos archivos DLL.

para hacer que todo funcione es necesario para incrustar dependencias DLL de la aplicación en las aplicaciones manifiesto de archivo y lo conecta con el proyecto mediante el Manifiesto de herramientas, de entrada y la sección de salida de la configuración del proyecto de aplicación.

Como un ejemplo de ello es el manifiesto que utilizo para la Zeus for Windows IDE:

<?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> 

Por último, si va a hacer un instalador tendrá que añadir las mismas versiones de estos archivos DLL para el instalador de aplicaciones o alternativamente, haga que su instalador ejecute el instalador redistribuible de Microsoft CRT.

Fwiw que sólo tuvo conocimiento de ello cuando un usuario informó que Zeus ya no corrió en Windows XP debido a un archivo DLL MSVCRT tiempo de ejecución que falta, sin embargo, Zeus había estado trabajando muy bien por más de 10 años sin que ni una sola vez tener que enviar con una Archivo DLL de tiempo de ejecución MSVCRT.

+0

Intenté copiar el contenido del manifiesto desde el directorio de redirección de VS 2008 en un archivo en el directorio de mi proyecto, y luego indiqué que era un "archivo de manifiesto adicional" en las propiedades de manifiesto de mi proyecto, que funcionaba bien pero no resolvía el problema. –

+1

user42279 "intenté copiar el contenido". También debe asegurarse de que los detalles contenidos en el manifiesto también sean correctos. Son los detalles del manifiesto los que determinan cómo se carga y ejecuta el programa, por lo que si no son correctos, no se ejecutará. – high5

0

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úrate de que NO msvcr90 esté en la RUTA. Puede usar el explorador de procesos (procexp.exe de SystemInternals) para averiguar 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. incruste el manifiesto dll en myProj.dll. Después de que cl.exe y link.exe produzcan myProj.dll, también se genera un manifiesto correspondiente. A continuación, utilice Mt.exe -inputresource myProj.dll.manifest salida privado myProj.dll; 2

El anteriores resuelve mi problema, espero que podría ser de alguna ayuda para usted. BTW, estoy usando VC 2008 en Windows 2008 R

Cuestiones relacionadas