I keep hearing about DLL hell - what is this? [closed]

Answer 1

It's when Application A installs a Shared DLL v1.0, Application B comes and updates the Shared DLL to v1.1 which should be compatible but there are slightly different behaviors, then App A stops working correctly and reinstalls v1.0 then App B stops working ... now imagine this with more than 2 apps let's say a dozen: DLL Hell.

Answer 2

DLL hell was mostly from the COM days, where a COM dll had to be registered, and clients of it would look it up in the registry. It was a nightmare because the filesystem (*.dll, *.ocx) could be modified leaving obsolete entries in the registry. Apps would stop working, it was horrible.

You'd then get the scenario where a new app installs and registers a new version of the DLL, thus breaking apps that really wanted the old version. You'd reinstall the old app, and break the new one in the process.

With .NET, there's no need to register the DLLs (the GAC is a special case, and has provision to avoid the versioning issue described above), the loader just picks up assemblies by looking in the correct paths.

Answer 3

In a nutshell in the good old COM days each COM component had to be registered (an entry was created in the registry) before it was used. Then your program would create a new object by supplying the type name (which was a key in the registry). And now you didn't have any control over which dll would really be loaded, would any other software register some newer/older/completely different version of this dll, etc.

Answer 4

It happens when an application installs a dll into the system, and another application replaces it with another version of the dll which is not compatible with the older one.

It is not a problem in c# (and .NET in general) because .NET assemblies are smart enough to be version-aware (and .NET has the GAC which manages different versions).

Answer 5

Simple - in previous versions of windows, it was possible to have multiple applications all trying to access the same shared library. No problem there, that's why they are shared. the problem comes when different apps were trying to access different versions of the same assembly from a central location. Providing all the later versions of the dll are backward-compatible, and that you have the latest version there should be no problem, but if you install an app that requires v2, and then install and app that requires (and includes) version 1.x, you may find the first app stops working (because the v2 dll has been overwritten with v1.x).

Recent versions of windows are capable of storing multiple versions of a dll, and supplying the correct one on request.