J’entends toujours parler de l’enfer des DLL – qu’est-ce que c’est?

Je continue à entendre parler de l’enfer des DLL – qu’est-ce que c’est?

C’est lorsque l’application A installe une DLL partagée v1.0, l’application B vient et met à jour la DLL partagée vers la v1.1 qui devrait être compatible mais il y a des comportements légèrement différents, puis l’application A cesse de fonctionner et réinstalle v1.0 Travailler … maintenant imaginez ceci avec plus de 2 applications, disons une douzaine: DLL Hell.

DLL hell provenait principalement des jours COM, où une DLL COM devait être enregistrée, et les clients de celle-ci la recherchaient dans le registre. C’était un cauchemar car le système de fichiers (* .dll, * .ocx) pouvait être modifié en laissant des entrées obsolètes dans le registre. Les applications cesseraient de fonctionner, c’était horrible.

Vous obtiendrez alors le scénario où une nouvelle application installe et enregistre une nouvelle version de la DLL, brisant ainsi les applications qui voulaient vraiment l’ancienne version. Vous devez réinstaller l’ancienne application et en casser une nouvelle.

Avec .NET, il n’est pas nécessaire d’enregistrer les DLL (le GAC est un cas particulier et il est possible d’éviter le problème de gestion des versions décrit ci-dessus), le chargeur ne fait que ramasser les assemblages en recherchant les chemins appropriés.

En un mot, dans les bons vieux jours COM, chaque composant COM devait être enregistré (une entrée avait été créée dans le registre) avant d’être utilisé. Ensuite, votre programme créera un nouvel object en fournissant le nom du type (qui était une clé dans le registre). Et maintenant, vous n’avez aucun contrôle sur la dll qui serait réellement chargée, est-ce que d’autres logiciels enregistreraient une version plus récente / plus ancienne / complètement différente de cette DLL, etc.

Simple – dans les versions précédentes de Windows, il était possible d’avoir plusieurs applications essayant d’accéder à la même bibliothèque partagée. Pas de problème, c’est pourquoi ils sont partagés. le problème vient du fait que différentes applications essayaient d’accéder à différentes versions du même assemblage à partir d’un emplacement central. À condition que toutes les versions ultérieures de la DLL soient compatibles avec les versions antérieures et que vous ayez la dernière version, cela ne devrait poser aucun problème, mais si vous installez une application nécessitant v2, puis installez et appliquez la version 1. x, vous pouvez constater que la première application ne fonctionne plus (car la DLL v2 a été remplacée par v1.x).

Les versions récentes de Windows sont capables de stocker plusieurs versions d’une DLL et de fournir la bonne version sur demande.

Cela se produit lorsqu’une application installe une DLL dans le système et qu’une autre application la remplace par une autre version de la DLL qui n’est pas compatible avec l’ancienne.

Ce n’est pas un problème dans c # (et .NET en général) car les assemblys .NET sont suffisamment intelligents pour être compatibles avec la version (et .NET a le GAC qui gère différentes versions).