Simple question but I keep hearing about DLL hell - what is this all about?
Thanks, MarcoPolo
+3
A:
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
2009-09-04 13:34:42
+10
A:
It's when Application A installs a Shared DLL vers 1.0, Application B comes and updates the Shared DLL to vers 1.1 which should be compatible but there are slightly different behaviors, then App A stops working correctly and reinstalls vers 1.0 then App B stops working ... now imagine this with more than 2 apps let's say a dozen: DLL Hell.
Pop Catalin
2009-09-04 13:35:15
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...
Workshop Alex
2009-09-04 13:56:43
+3
A:
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
2009-09-04 13:35:25
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
2009-09-04 13:38:34
+5
A:
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
2009-09-04 13:35:45
+3
A:
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 version 2, 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.
ZombieSheep
2009-09-04 13:35:48
+3
A:
The Wikipedia entry is quite comprehensive:
http://en.wikipedia.org/wiki/DLL%5Fhell
And it even goes into the related Dependency_hell...
Joe R
2009-09-04 13:36:08
I was just reading about anti-patterns and noticed they had alot of material on DLL Hell.
Mayo
2009-09-04 13:37:24