52

I keep hearing about DLL hell - what is this all about?

Michael Mrozek
  • 169,610
  • 28
  • 168
  • 175
MarcoPolo
  • 1,076
  • 1
  • 10
  • 8

5 Answers5

82

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.

John Smith
  • 7,243
  • 6
  • 49
  • 61
Pop Catalin
  • 61,751
  • 23
  • 87
  • 115
  • 11
    And this problem is now happening with .NET, although it's less common. If you have an application that uses two assemblies, and those two both use a third assembly then you're in the .NET Hell. Especially if those two assemblies each use a different version of this third assembly... – Wim ten Brink Sep 04 '09 at 13:56
  • 4
    But wait, haven't they solved this problem by implementing side-by-side versioning? – user3509153 Aug 07 '14 at 19:00
16

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.

Neil Barnwell
  • 41,080
  • 29
  • 148
  • 220
  • 5
    It stands for Component Object Model (http://en.wikipedia.org/wiki/Component_Object_Model). It was supposed to be a common way for Windows software to talk to each other/reuse libraries etc. ActiveX is a good example. A library could expose COM interfaces as it's contract, and another app written in a different language could still consume that library as long as it had COM support. Any libraries built using VB6 were COM libraries - they have to be registered in the Windows registry for other apps to discover them. – Neil Barnwell Mar 10 '14 at 14:45
6

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.

Grzenio
  • 35,875
  • 47
  • 158
  • 240
6

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.

John Smith
  • 7,243
  • 6
  • 49
  • 61
ZombieSheep
  • 29,603
  • 12
  • 67
  • 114
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).

Tamás Szelei
  • 23,169
  • 18
  • 105
  • 180
  • 4
    Except that .NET ignores the revision number (4th element in the version) and it's possible to have incompatible revisions. Happened to a colleague with a component supplied by Microsoft, no less. – Michael Borgwardt Sep 04 '09 at 13:38
  • @Michael Borgwardt: That's a valuable addition, thank you. – Tamás Szelei Sep 04 '09 at 13:43