visual-studio-2010 - language - visual studio code golang

Visual C++ 2010: Cambios en la implementación en tiempo de ejecución de MSVC(no más SxS con manifiesto) (2)

Solo un par de enlaces sobre el tema, espero que alguien los encuentre útiles:

¿Dónde puedo encontrar una nota oficial, un artículo de KB u otra documentación que describa los cambios en la política de implementación y vinculación del tiempo de ejecución de Visual Studio 2010 C / C ++?

En Visual Studio 2008 (con el tiempo de ejecución de VC90) se incrustó un manifiesto en las imágenes nativas, y las bibliotecas de tiempo de ejecución se implementaron como conjuntos de lado a lado (WinSxS). Esto causó problemas al reconstruir un exe nativo o una biblioteca con VS 2008 SP1, ya que el manifiesto incrustado requería una versión actualizada del tiempo de ejecución de C ++.

Para VS 2010 y la versión de tiempo de ejecución MSVCR100, la política parece haber cambiado completamente.

El archivo msvcr100.dll y las otras bibliotecas de tiempo de ejecución C / C ++ ya no se instalan como ensamblajes SxS.
Al compilar en VS2010, no se agrega ninguna entrada de "dependencia" en tiempo de ejecución al manifiesto incrustado, lo que significa que cualquier versión de msvcr100.dll podría cargarse en tiempo de ejecución.
En las máquinas con .NET 4 instalado, el tiempo de ejecución coincidente se llama msvcr100_clr0400.dll y no se cargará con el código nativo, aunque una copia renombrada a msvcr100.dll funciona bien. Creo que esto significa que cualquier proceso con código C / C ++ siempre tendrá dos versiones del mismo tiempo de ejecución de C / C ++ cargadas.

Esto parece ser un cambio significativo en la política, el retroceso de la implementación de SxS y las dependencias de manifiesto que teníamos en VS 2008. ¿Podría alguien arrojar más luz sobre lo que cambió, y tal vez apuntar a alguna documentación, un archivo readme o blog que describe estos cambios? ¿La motivación y el impacto relacionado?

Creo que es mejor de esta manera (el manifiesto de la versión sólida y la implementación de SxS fue una pesadilla), pero me sorprenden estos cambios inesperados y aparentemente indocumentados en VS 2010.

Pregunta extra: ¿Cómo puedo compilar mi biblioteca C ++ / CLI en VS 2010 para vincular a msvcr100_clr0400.dll en lugar de msvcr100.dll? Esta idea es que el ensamblado de C ++ / CLI debe ejecutarse sin más dependencias que la instalada por .NET 4 (sin enlace estático).

Ya respondiste la mayor parte de tu pregunta, el despliegue paralelo del CRT fue una pesadilla que puso demasiados programadores en problemas. Microsoft estuvo de acuerdo y lo abandonó para el lanzamiento de VS2010. Ha vuelto a una DLL en c: / windows / system32, llamada msvcr100.dll. Y msvcp100.dll, vcomp100.dll, atl100.dll, mfc100.dll, mfcm100.dll, las otras DLL de soporte de tiempo de ejecución. Así fue para VS2003 y ediciones anteriores. Ahora es nuevamente la carga del usuario resolver un problema de DLL Hell. La persona con menos probabilidades de poder hacerlo, pero tienden a tener un presupuesto para pagar la manutención. A diferencia de los programadores que necesitan obtener ayuda de un sitio web gratuito :)

Pero puede ayudar, la implementación local de la aplicación ahora está nuevamente habilitada, puede implementar msvcr100.dll en el mismo directorio que su EXE principal. Eso fue explícitamente verificado y prohibido en versiones anteriores. App-local tiene algunas sutilezas, lo aísla de las actualizaciones bien intencionadas pero desafortunadas que rompen su aplicación. Si bien ahora usted mismo es responsable de implementar actualizaciones que corrijan un agujero de seguridad. Si eso es incómodo, entonces implemente y confíe en la copia en el directorio del sistema.

No intente enlazar a msvr100_clr0400.dll, es una copia privada para que la use el CLR. Al igual que msvcr.dll es una copia privada para el uso de DLL de Microsoft. No tiene el archivo .lib que necesita para vincular a estas DLL.