sp1 - No se encontró MSVCR90D.dll en modo de depuración con Visual C++ 2008
microsoft visual c++ 2008 x64 offline (10)
Tengo un problema con Visual C ++ 2008. He instalado opencv y he creado un nuevo programa y lo construyo sin errores. Sin embargo, se queja de no encontrar MSVCR90D.dll al depurar. En el modo de lanzamiento no hay ningún problema.
Tengo MSVCR90D.dll en una de las carpetas de Winsx. ¿Alguien sabe cómo solucionar este problema? ¿Es esto un error conocido?
Gerard
Esta es una de las razones por las que estoy vinculado estáticamente; EXEs más grandes, pero nunca antes había tenido un problema de dependencia como este. Probablemente vale la pena una pregunta en sí misma ...
Hay varias soluciones potenciales descritas en esta publicación del foro . Vea si alguno de esos ayuda.
Una pista desde allí:
Vaya a% System Drive% / Windows / WinSxS y busque el directorio x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456
Si esto no existe, vaya a la configuración de VS y asegúrese de tener todas las bibliotecas instaladas en VC ++.
Y otro:
Tuve el mismo problema, pero lo solucioné desactivando el enlace incremental (Propiedades del proyecto ... Enlazador ... General ... Habilitar enlace incremental: No).
Confirmando el último:
Los proyectos creados en una unidad montada en software se quejan de la falta de MSVCR90D.dll. El problema desaparece si desactiva el enlace incremental (y reconstruye todo, por supuesto).
La solución de problemas de DLL es mucho más fácil con Dependency Walker. Le permite perfilar su aplicación, capturando tanto las DLL cargadas al inicio como las DLL cargadas más tarde. Escupirá una gran cantidad de mensajes relacionados con la carga de archivos DLL o la falla al cargarlos. También comprende la carga de SxS de archivos DLL.
Puede pasar un EXE como argumento a Depends.EXE, y dará un perfil a esa aplicación. Esto se puede combinar con la mayoría de los IDEs. Por ejemplo, en Visual Studio puede establecer el "Comando para depurar". Por defecto, ese es tu propio EXE. /pb your.debug.exe
y establezca los argumentos del comando en (al menos) /pb your.debug.exe
.
Al tener el mismo problema, encontré una publicación que me llevó a las DLL de depuración en la instalación de VS9.0. Para la instalación predeterminada en la que se encontraban: C:/Program Files/Microsoft Visual Studio 9.0/VC/redist/Debug_NonRedist/x86/Microsoft.VC90.DebugCRT
.
Hay tres DLL y un archivo de manifiesto. Puede agregarlos a su directorio System32
, agregar el directorio a la PATH
entorno PATH
o copiar los archivos en el mismo directorio que su ejecutable al depurar.
La vinculación incremental acelera sus compilaciones (el enlazador solo vuelve a vincular las bibliotecas que han cambiado en lugar de volver a vincular todo el proyecto). De lo contrario, no tiene ningún efecto en la salida de compilación. Para un proyecto grande, no recomendaría desactivar el enlace incremental.
No puedo dar una solución definitiva, pero aquí hay algunos enlaces útiles:
- Blog de David Lenihan sobre WinSxS
- Conjuntos uno al lado del otro
- Solución de problemas de aplicaciones aisladas en C / C ++ y ensamblajes lado a lado
- Secuencia de búsqueda de ensamblaje
Y, por supuesto, hay mucho más en MSDN si sigues los enlaces.
Tuve el problema:
No se pudo cargar el archivo o ensamblado ''AudioInterface, Version = 1.0.3548.29920, Culture = neutral, PublicKeyToken = null'' o una de sus dependencias. Esta aplicación no ha podido iniciarse porque la configuración de la aplicación es incorrecta. Reinstalar la aplicación podría resolver el problema. (Excepción de HRESULT: 0x800736B1)
AudioInterface fue el nombre de mi proyecto C ++.
Cambiando a la configuración "Release", todo funcionó.
Lo rastreé hasta la falta del archivo de manifiesto junto con mi DLL, que además rastreé hasta tener un conjunto de identidades de conjunto. (Propiedades> Herramienta de manifiesto> General> Identidad de conjunto)
Eliminé esta configuración, y el manifiesto cayó en el lugar correcto, y todo funcionó.
Tuve el mismo problema, aunque otro proyecto de VC9.0 lo hizo bien. Así que comparé ambas configuraciones del proyecto. La diferencia crucial estaba en ''Propiedades del proyecto'' -> ''Propiedades de configuración'' -> ''Herramienta de manifiesto'' -> ''Entrada y salida'' -> ''Insertar manifiesto''. Esta opción debe establecerse en SÍ.
Recompile su proyecto en VC ++ 2008 usando la función Archivo-> Nuevo-> Proyecto desde código existente. Me ayudó a mí mismo, probablemente te ayudará. Saludos.
Probé todas las soluciones sugeridas sin suerte. Finalmente encontré que el manifiesto faltaba en la carpeta "C:/WINDOWS/WinSxS/Manifests"
.
Busque la carpeta en C:/WINDOWS/WinSxS
donde se encuentra su dll. Compruebe si hay un manifiesto en C:/WINDOWS/WinSxS/Manifests
que coincida con el nombre de la carpeta de su dll. Si falta el manifiesto, copie el manifiesto correcto de otra máquina y péguelo en la carpeta de manifiesto. Los nombres de archivo de manifiesto son:
"x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456.cat"
"x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456.manifest"
He resuelto el mismo problema como a continuación:
- Seleccione proyecto, haga clic derecho y abra la página de propiedades.
- Seleccione Propiedades de configuración.
- Seleccione C / C ++ de la lista de árbol.
- Seleccione Generación de código.
- Mire la lista de propiedades en el lado izquierdo y vea la propiedad Biblioteca de tiempo de ejecución .
- Seleccione Multi-threaded Debug en lugar de DLL Multi-threaded.
Cuando haces eso, tu proyecto incorpora dlls dependientes y escapa a los problemas de dependencia.
Nota: trabajé en un proyecto dll y tuve ese problema. Después de hacer los pasos anteriores funcionó para mi situación.