Sigo escuchando sobre el infierno de DLL, ¿qué es esto?

Question

Sigo escuchando sobre el infierno de las DLL: ¿de qué se trata todo esto?

Answer 1

Es cuando la Aplicación A instala una DLL compartida v1. 0, la aplicación B viene y actualiza la DLL compartida a v1.1 que debería ser compatible, pero hay comportamientos ligeramente diferentes, luego la aplicación A deja de funcionar correctamente y reinstala v1.0 luego la aplicación B deja de funcionar ... ahora imagínese esto con más de 2 aplicaciones digamos una docena: DLL Hell.

Answer 2

En pocas palabras, en los buenos viejos días COM cada componente COM tenía que registrarse (se creó una entrada en el registro) antes de ser utilizado. Entonces su programa crearía un nuevo objeto al proporcionar el nombre de tipo (que era una clave en el registro). Y ahora no tenía ningún control sobre qué dll realmente se cargaría, cualquier otro software registraría alguna versión más nueva/antigua/completamente diferente de este dll, etc.

Answer 3

Ocurre cuando una aplicación instala un dll en el sistema, y ​​otra aplicación lo reemplaza con otra versión de la DLL que no es compatible con la anterior.

No es un problema en C# (y .NET en general) porque los ensamblados .NET son lo suficientemente inteligentes como para ser compatibles con la versión (y .NET tiene el GAC que maneja diferentes versiones).

Answer 4

DLL infierno era en su mayoría de los días COM, donde tenía que registrarse un dll COM, y los clientes de la buscarían en el registro. Fue una pesadilla porque el sistema de archivos (* .dll, * .ocx) podría modificarse dejando entradas obsoletas en el registro. Las aplicaciones dejarían de funcionar, fue horrible.

A continuación, obtendrá el escenario donde se instala una nueva aplicación y registra una nueva versión de la DLL, rompiendo así las aplicaciones que realmente querían la versión anterior. Volverías a instalar la aplicación anterior y romperías la nueva en el proceso.

Con .NET, no es necesario registrar los archivos DLL (el GAC es un caso especial y tiene una disposición para evitar el problema de control de versiones descrito anteriormente), el cargador solo recoge los ensambles buscando en las rutas correctas.

Answer 5

Simple: en las versiones anteriores de Windows, era posible tener múltiples aplicaciones intentando acceder a la misma biblioteca compartida. No hay problema allí, es por eso que son compartidos. el problema surge cuando diferentes aplicaciones intentan acceder a diferentes versiones del mismo ensamblaje desde una ubicación central. Si todas las versiones posteriores del dll son compatibles con versiones anteriores, y si tiene la versión más reciente, no debería haber ningún problema, pero si instala una aplicación que requiere v2, y luego instala una aplicación que requiere (e incluye) la versión 1. x, es posible que la primera aplicación deje de funcionar (porque la dll v2 se sobrescribió con v1.x).

Las versiones recientes de Windows son capaces de almacenar múltiples versiones de un dll, y suministrar el correcto a pedido.