Lado a lado de la locura - binarios en el mismo equipo que ejecuta

Question

Aquí está mi configuración:

• El equipo A - Windows 7, MS Visual Studio 2005 parches para la compatibilidad Win7 (8.0.50727.867)
• equipo B - SP2 de Windows XP, MS Visual Studio 2005 instalado (8.0.50727.42)

Mi proyecto tiene algunas dependencias externas (DLL prediseñados - ya sea en la construcción o descargado de Internet), un par de DLL construidas a partir de fuentes y un ejecutable. Estoy en su mayoría en desarrollo y todo está bien allí. En algún momento trato de construir mi proyecto en el equipo B , la copia de los archivos DLL creados previamente a la carpeta de salida. Todo se construye muy bien, pero tratando de iniciar mi solicitud consigo

La aplicación no se pudo inicializar correctamente (0xc0150002) ....

El registro de eventos contiene dos de los:

Dependiente Asamblea Microsoft.VC80.CRT no se pudo encontrar y último error fue el montaje de referencia no está instalado en su sistema.

más el ligeramente más divertido

Generar Activación de Contexto falló para some.dll. Referencia mensaje de error: El operación se completó correctamente.

En este punto estoy haciendo mi Google-Fu, pero en vano - prácticamente todos los golpes son acerca de la ejecución de binarios en máquinas sin instalado Visual Studio. En mi caso, sin embargo, los ejecutables no se ejecutan en el equipo que se construyen.

El siguiente paso fue tratar la dependencia Walker y me desconcertó aún más - mis DLL construidas a partir de fuentes en la misma caja no puede encontrar MSVCR80.DLL y MSVCP80.DLL, sin embargo el ejecutable parece estar bien en lo que respecta a esos dos archivos DLL, es decir, cuando abro la ejecutable con Dependency Walker muestra que los MSVC?80.DLLs se pueden encontrar, pero cuando uno abierto de mis archivos DLL que dice que no pueden. Ahí es donde yo estoy completamente fuera de las ideas qué hacer, así que te pido, querido stackoverflow:)

Me admitir que estoy un poco borrosa en todo el asunto de lado a lado, por lo que también se observará la lectura general sobre el tema.

Answer 1

Su pregunta tiene la respuesta a su problema:. El equipo A tiene VC tiempo de ejecución de la versión 8.0.50727.867 , y el equipo B tiene sólo la versión 8.0.50727.42

Usted construyó sus bibliotecas en el equipo A, y dependen de la versión de 867 CV en tiempo de ejecución. (Esto se puede encontrar en el manifiesto incrustado en las bibliotecas.) Cuando se copian al equipo B, estas bibliotecas aún requieren la versión 867 del tiempo de ejecución pero sólo dispone de la versión 42.

Para resolver las dependencias de montaje de ejecución VC, tiene que instalar redistributables VC de tiempo de ejecución de la versión 867 en el equipo B. Sin embargo, te aconsejo para actualizar Visual Studio en el equipo B para que tenga la misma versión en ambos equipos. Y aún mejor, instalar Visual Studio 2005 SP1 en ambos equipos y luego instalar esta actualización de seguridad de SP1 . Después de instalar este último, sus bibliotecas dependerán de la versión 8.0.50727.4053 .

Answer 2

es posible que el problema está relacionado con las diferentes versiones de tiempo de ejecución CRT instalado en ambas máquinas. es posible la construcción de todos los módulos de utilizar el tiempo de ejecución CRT enlazado estáticamente para verificar esto?

Answer 3

primero que haría el que los archivos DLL creados previamente mediante la preparación de proyecto ficticio para cargarlos

Answer 4

recientemente he tenido el mismo tipo de error en la construcción de proyectos en una máquina y luego moverlos a otra máquina. El mayor culpable aquí es probable que una configuración de depuración para uno de los componentes binarios. Es decir, MSVC tiene el requisito bastante rígida de todas las DLL / EXE que se construye con la misma biblioteca de tiempo de ejecución, depuración o liberación, de lo contrario no van a trabajar juntos.

Cuando me había ocurrido esto también tienden a compilar muy bien, pero cuando se intenta ejecutar ellos se obtiene ese mensaje de error muy críptica.

Usted necesita asegurarse de que cada módulo se construye en conjunto utiliza la misma configuración, por tanto, de depuración o la liberación a través de toda la cadena de generación. Este error también es probable que se le ocurre desajustes en otras bibliotecas, así que asegúrese de que su MSVC es exactamente la misma versión en las máquinas donde se está construyendo.