msvcrt - objetos - crear variables en tiempo de ejecucion c#

¿Debo enlazar el tiempo de ejecución de Visual Studio C de forma estática o dinámica?

Question

He leído argumentos en ambos lados sobre si se debe vincular de forma estática o dinámica a la biblioteca de tiempo de ejecución de C en los proyectos de Visual Studio, y todavía no estoy completamente seguro de qué pensar.

Mi proyecto incluye algunas bibliotecas de terceros (Python, HDF5, Trilinos y Microsoft MPI), cada una de las cuales debe compilarse con la misma biblioteca de tiempo de ejecución que mi ejecutable final (de lo contrario, no se podrán vincular). Al enlazar estáticamente, cada una de estas bibliotecas contendrá una copia del tiempo de ejecución de C. Leí que esto puede causar problemas porque el ejecutable final contendrá varias copias del tiempo de ejecución, ninguna de las cuales puede interactuar entre sí. ¿Pero no se quejaría el enlazador si los mismos símbolos se definieran de manera múltiple?

Me gustaría evitar "DLL Hell", pero me preocupan los errores insidiosos que pueden surgir al vincular estáticamente varias copias del tiempo de ejecución. ¿Estoy leyendo cosas mal?

Además, estoy usando Visual Studio 2005 y leí que el tiempo de ejecución del Service Pack 1 no es compatible con versiones anteriores. ¿Significa esto que una aplicación creada sin SP1 no se ejecutará en una máquina que tenga las dll SP1, incluso si tienen el mismo nombre (por ejemplo, msvcr80.dll)?

Answer 1

... Hágalo de forma estática ... los intentos de reparar DLL Hell no han funcionado tan bien ... solo agregue 200k adicionales a su instalación con el enlace estático.

Answer 2

La única vez que obtendrá varias copias del tiempo de ejecución es cuando vincula de forma estática una biblioteca a una DLL: cada DLL obtendrá una copia, al igual que el archivo exe. Si todas son bibliotecas estáticas y no DLL, todas se vincularán y todas sus bibliotecas compartirán el mismo tiempo de ejecución.

Ese es el trabajo del enlazador.

Answer 3

La vinculación estática inflará todos tus EXE y DLL, y puede causar bloqueos (por ejemplo, si el código en una DLL llama a free () con un puntero asignado por malloc () en una DLL diferente).

Puede obtener lo mejor de ambos mundos mediante la vinculación dinámica y la implementación de las DLL de tiempo de ejecución como ensamblajes privados. Esto simplemente significa poner una copia de un directorio con un nombre especial que contenga las DLL de tiempo de ejecución y sus manifiestos al lado de su ejecutable.

Consulte la sección "Implementación de las DLL de la biblioteca de Visual C ++ como ensamblajes privados" en http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx para obtener más información, pero básicamente su aplicación se ve así:

c:/Program Files/My App/MyApp.exe
c:/Program Files/My App/MyLibrary.dll
c:/Program Files/My App/Microsoft.VC80.CRT/Microsoft.VC80.CRT.manifest
c:/Program Files/My App/Microsoft.VC80.CRT/msvcr80.dll

En cuanto a su última pregunta, sí, la máquina de destino necesita las versiones correctas de las DLL de tiempo de ejecución para funcionar, pero al implementarlas como ensamblajes privados, lo garantiza.

Otro beneficio es que los usuarios que no son administradores pueden instalar su aplicación (no en Archivos de programa, pero en otros lugares), no necesitan permiso para escribir archivos en el área de WinSxS.

Answer 4

Las bibliotecas estáticas no necesitan estar vinculadas estáticamente a otras bibliotecas estáticas. Solo necesita vincular todas las bibliotecas estáticas en su proyecto principal. De esa manera el compilador no se quejará de múltiples símbolos.