Desde nuestro interruptor del 6 de Visual Studio para Visual Studio 2008, hemos estado usando el MFC90.dll y msvc[pr]90.dll junto con los archivos de manifiesto en un privado al lado de la configuración, así como para no preocuparse de versiones o de una instalación para el sistema.

Pre-SP1, este estaba funcionando bien (y todavía funciona muy bien en nuestros equipos de desarrollador). Ahora que hemos hecho algunas pruebas de post-SP1 he estado tirando de mi pelo desde ayer por la mañana.

Primero, nuestro instalador NSIS script extrae los archivos dll y los archivos de manifiesto de la carpeta redist. Ya no eran correctos, ya que la aplicación sigue los enlaces a la versión RTM.

Así que he añadido el definir para _BIND_TO_CURRENT_VCLIBS_VERSION=1 a todos nuestros proyectos, para que se va a utilizar el SP1 de Dll en la carpeta redist (o posterior, como el nuevo servicio de paquetes de salir). Me tomó horas para encontrar esto.

He vuelto a revisar la genera archivos de manifiesto en el intermedio de la carpeta de los archivos de la compilación, y se muestra correctamente la 9.0.30729.1 versiones SP1. He doble y el triple para comprobar depende de una máquina de limpieza: todos los enlaces a los locales dll sin errores.

Ejecutando la aplicación todavía se pone el siguiente error:

La aplicación no se pudo inicializar correctamente (0xc0150002). Haga clic en ACEPTAR para terminar la aplicación.

Ninguna de las búsquedas que he hecho en google o microsoft han llegado a algo que se relaciona con mi tema específico (pero no se vuelve a 2005 con este mensaje de error).

Cualquiera tenido algún problema similar con SP1?

Opciones:

  • Encontrar el problema y solucionarlo de modo que funciona como debe (preferido)
  • Instalar el redist
  • desenterrar los viejos RTM dll y archivos de manifiesto y quitar el #definir el uso de los actuales. (Tengo en una anterior instalador de construir, ya que Microsoft explosiones fuera de su carpeta redist!)

Editar: he tratado de re-construcción con la de definir apagado (enlace a la versión RTM de dll), y que funciona siempre como el RTM dll se instalan en la carpeta. Si el SP1 de dll son caído en, se obtiene el siguiente error:

c:\Program Files\…\…\X.exe

Esta aplicación no pudo iniciar porque la configuración de la aplicación es incorrecta. Reinstalar la aplicación puede solucionar este problema.

Tiene nadie más tuvo que lidiar con este problema?

Editar: Sólo para sonríe, he descargado y corrió el vcredist_x86.exe para VS2008SP1 en mi máquina de prueba. Es funciona. Con el SP1 de Dll. Y mi RTM vinculado aplicación. Pero NO en privado side-by-side de distribución que trabajó pre-SP1.

InformationsquelleAutor crashmstr | 2008-09-12

5 Comentarios

  1. 40

    Me han luchado contra este problema yo mismo la semana pasada y me considero un poco de un experto ahora 😉

    Estoy 99% seguro de que no todos los archivos dll y bibliotecas estáticas se vuelve a compilar con la versión de SP1. Usted necesidad de poner

    #define _BIND_TO_CURRENT_MFC_VERSION 1
    #define _BIND_TO_CURRENT_CRT_VERSION 1

    en cada proyecto que está utilizando. Para cada proyecto de un mundo real tamaño, es muy fácil olvidar algunas pequeñas lib que no se vuelve a compilar.

    Hay más parámetros que definen lo que las versiones para atar; se documenta en http://msdn.microsoft.com/en-us/library/cc664727%28v=vs.90%29.aspx . Como una alternativa a las líneas de arriba, usted también puede poner

    #define _BIND_TO_CURRENT_VCLIBS_VERSION 1

    que se unen a la versión más reciente de todos los VC libs (CRT, MFC, ATL, OpenMP).

    A continuación, comprobar lo que el manifiesto incrustado dice. Descargar XM Editor de Recursos: http://www.wilsonc.demon.co.uk/d10resourceeditor.htm. Abierto todos los dll y exe en su solución. Busca en ‘XP Tema de Manifestar’. Compruebe que la ‘versión’ atributo en el lado derecho es ‘9.0.30729.1’. Si es ‘9.0.21022’, algunas biblioteca estática está tirando en el manifiesto para la versión antigua.

    Lo que he encontrado es que, en muchos casos, tanto versiones fueron incluidos en el manifiesto. Esto significa que algunas de las bibliotecas utilizan la versión de sp1 y otros no.

    Una gran manera de depuración que las bibliotecas no tienen las directivas de preprocesador conjunto: modificar temporalmente su plataforma de encabezados para que la compilación se detiene cuando se trata de incrustar el viejo manifiesto. Abierto C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\include\crtassem.h. Búsqueda de la «21022′ cadena. En que definir, poner algo no válido (cambio de ‘definir’ a ‘blehbleh’ o algo así). De esta manera, cuando se compila un proyecto en el que el _BIND_TO_CURRENT_CRT_VERSION preprocesador indicador no está definido, la compilación se detendrá y usted sabe que usted necesita para agregar o asegurarse de que se aplica en todas partes.

    Asimismo, asegúrese de utilizar Dependency Walker para que usted sepa qué archivos dll son arrastradas. Es más fácil instalar un nuevo Windows XP copia sin actualizaciones (sólo SP2) en una máquina virtual. De esta manera usted sabe con certeza que no hay nada en la carpeta SxS que se utiliza en lugar de la side-by-side archivos dll que usted suministra.

    • Depende nunca mostró lo que faltaba en mi limpio VM (puede ser que necesite para asegurarse de que tienes la última versión!), pero usando el Editor de Recursos, he encontrado la DLL errónea. Era un archivo DLL se compile pero que no es parte de nuestro proyecto. Gracias por la ayuda.
    • Tengo la versión más reciente de Dependency Walker, y llamó de inmediato los problemas con los archivos Dll específicos que eran un problema.
    • La bandera _BIND_TO_CURRENT_VCLIBS_VERSION también funciona.
    • Roel del crtassem.h edición técnica es ideal para la búsqueda de unidades de compilación que no incluyen stdafx.h que todavía puede ser vinculante el mal lib versiones.
    • Levanta las manos hacia el cielo Gracias, gracias, gracias! No sólo hizo que el trabajo, pero yo realmente entender por qué. Una combinación de sxstrace para determinar el componente que estaba llorando por lo que sxs de dependencia y de estos define a hacer el manifiesto apuntan en la dirección correcta, woot!
  2. 14

    Para comprender el problema, creo que es importante darse cuenta de que hay cuatro números de versión de los involucrados:

    • (A) La versión de la VC de los archivos de cabecera para que el .exe compilado.
    • (B) La versión del archivo de manifiesto que está incrustado en la sección de recursos de que .exe. De forma predeterminada, este archivo de manifiesto es generado automáticamente por Visual Studio.
    • (C) La versión de la VC .Los archivos dll (parte de la side-by-side de la asamblea) se copia en el mismo directorio que el .exe.
    • (D) La versión de la VC archivos manifest (parte de la side-by-side de la asamblea) se copia en el mismo directorio que el .exe.

    Hay dos versiones de la VC DE 2008 DLL en el running:

    • v1: 9.0.21022.8
    • v2: 9.0.30729.4148

    Para mayor claridad, voy a usar la v1/v2 notación. La siguiente tabla muestra una serie de situaciones posibles:

    Situation | .exe (A) | embedded manifest (B) | VC DLLs (C) | VC manifests (D)
    -----------------------------------------------------------------------------
    1         | v2       | v1                    | v1          | v1         
    2         | v2       | v1                    | v2          | v2          
    3         | v2       | v1                    | v2          | v1
    4         | v2       | v2                    | v2          | v2

    Los resultados de estas situaciones cuando se ejecuta el .exe y se limpia el SP1 de Vista de la instalación son:

    • Situación 1: un menú emergente se muestra, diciendo: «El punto de entrada del procedimiento XYZXYZ no se encuentra en la biblioteca de vínculos dinámicos».

    • Situación 2: parece que no sucede nada cuando se ejecuta el .exe, pero se registra el suceso siguiente en Windows’ «Visor de Sucesos /registro de Aplicación»:

      Contexto de activación de la generación de error de «C:\Path\file.exe».Error en el manifiesto o de directiva de archivo «C:\Path\Microsoft.VC90.CRT.MANIFEST» en la línea 4. Componente de identidad hallado en el manifiesto no coincide con la identidad de la componente solicitado. La referencia es Microsoft.VC90.CRT,processorArchitecture=»x86″,publicKeyToken=»1fc8b3b9a1e18e3b»,type=»win32″,version=»9.0.21022.8″. Definición de Microsoft

    • Situación 3: todo parece funcionar bien. Este es remicles2 la solución.

    • Situación 4: este es cómo debe hacerse la. Lamentablemente, como Roel indica, puede ser bastante difícil de implementar.

    Ahora, mi situación (y creo que es el mismo que crashmstr del) es n ° 1. El problema es que Visual Studio, por una razón u otra, se genera el código de cliente (A) para la v2, pero por una razón u otra, genera una v1 archivo de manifiesto (B). No tengo idea de donde la versión (A) puede ser configurado.

    Nota de que toda esta explicación es todavía en el contexto de ensamblados privados.

    Actualización: por fin empiezo a entender lo que está pasando. Al parecer, Visual Studio genera el código de cliente (A) para la v2 por defecto, contrario a lo que he leído en algunos blogs de Microsoft. El _BIND_TO_CURRENT_VCLIBS_VERSION bandera sólo selecciona la versión en generar el archivo de manifiesto (B), pero esta versión va a ser ignorados cuando se ejecuta la aplicación.

    Conclusión

    Una .exe que está compilado con Visual Studio 2008 enlaces a las versiones más recientes de la VC90 Dll de forma predeterminada. Usted puede el uso de la bandera _BIND_TO_CURRENT_VCLIBS_VERSION para el control de la versión de la VC90 bibliotecas se genera en el archivo de manifiesto. Este hecho evita la situación 2 de donde se obtiene el mensaje de error «manifiesto no coincide con la identidad de la componente solicitado». También explica por qué la situación 3 funciona bien, ya que incluso sin el _BIND_TO_CURRENT_VCLIBS_VERSION bandera de la aplicación está vinculada a las versiones más recientes de la VC Dll.

    La situación es incluso más raro con el público side-by-side asambleas, donde vcredist fue ejecutar, poner el VC 9.0 archivos Dll en Windows SxS directorio. Incluso si el .exe el archivo de manifiesto de los estados que las versiones antiguas de los archivos Dll debe utilizar (este es el caso cuando el _BIND_TO_CURRENT_VCLIBS_VERSION bandera no está definida), Windows ignora este número de versión por defecto! En su lugar, Windows utilizará una versión más reciente si está presente en el sistema, excepto cuando un «archivo de configuración de aplicación» se utiliza.

    Soy yo el único que piensa que esto es confuso?

    Por lo que resumen:

    • Para ensamblados privados, el uso de la _BIND_TO_CURRENT_VCLIBS_VERSION bandera en el .exe del proyecto y todos dependiente .lib proyectos.
    • Para las reuniones públicas, esto no es necesario, ya que Windows seleccione automáticamente la versión correcta de la .Dll desde el SxS directorio.
    • Qué irónico es que este LÍO se supone que para resolver el DLL hell. Ahora tenemos SxS el infierno, que es incluso peor.
  3. 4

    Acabo de recordar otro truco que he utilizado para averiguar qué bibliotecas estáticas estaban mal comportarse: ‘grep’ a través de las bibliotecas estáticas para la cadena ‘21022’. Sin EMBARGO, no utilice el ‘normal’ grep herramientas como wingrep, ya que no muestran estas cadenas (que creo que es un archivo binario y buscar la materia prima, no de cadena unicode). El uso de las «cuerdas», de la utilidad del kit de recursos (ahora en el Russinovich sitio, creo). Que uno grep a través de los binarios de aceptar. Así que vamos a este ‘cuerdas’ ir a través de todo el árbol de código fuente y verás los archivos binarios (archivos dll y bibliotecas estáticas) que contienen referencias a el mal manifiesto (o al manifiesto con la versión incorrecta en ella).

  4. 4

    Otra buena herramienta para la visualización de archivos exe y dll se manifiesta es Manifiesto De Vista, que oportunamente suficiente no se ejecutará en una instalación limpia de XP, porque se depende de 9.0.21022.

  5. 2

    Para su tercera opción, usted probablemente puede encontrar los archivos Dll y se manifiesta por la 9.0.21022 versión en la C:\WINDOWS\WinSxS directorio dev máquina. Si usted puede, a continuación, puede configurar su propio directorio redist e instalar los archivos con la aplicación.

    Como alternativa, puede utilizar la 9.0.30729.1 suministrados con Visual Studio y forjar el manifiesto de instalar con la aplicación para informar de que los suministros de la 9.0.21022 Dll, y no 9.0.30729.1. El enlazador dinámico no parece a la mente. Ver este blog, que ha sido de gran utilidad para la solución de estos problemas, para más información.

    Ambas soluciones solucionado el problema que he tenido con la implementación de los archivos Dll como privado asambleas con VS2008 Express.

    Roel, la respuesta es el camino a seguir para su primera opción («fix it right»), pero si usted depende de una biblioteca que depende de 9.0.21022 (y su manifiesto, por tanto, las listas de ambas versiones), luego la tercera opción puede ser la única manera de ir si usted no desea ejecutar vcredist_x86.exe.

Dejar respuesta

Please enter your comment!
Please enter your name here