dll hell (LoadLibrary) – solved in dotnet

Very common IV question…

[[Beginning vc++ 2010 ]] P 1178 has a good half-pager. Some pointers in my own language:
* a DLL is loaded (into mem) separately from the host app
* when you overwrite a dll on disk, the host app can load fine, which will automatically get the new dll to load. Happy scenario
* however, the same dll might be needed by another host app, which may now fail.

—-dll hell defined
http://www.desaware.com/tech/dllhell.aspx (circa 1998) covered pre-DLL era, good-DLL era, bad-DLL era

The reason for this issue was that the version information about the different components of an application was not recorded by the system.

The Re-install scenario: It would not be unusual to own several installers each embedding a different version of the same DLL. It is not unusual for users to reinstall software. In many cases users would install software that included an older version of commdlg.dll on a system that already contained a newer version. This would cause the more recently installed version to replace the newer version. As soon the user attempted to run the program that required the newer version, problems would occur ranging from operational difficulties to general protection faults.

Dotnet solved the problem. GAC can hold 2 versions of the same DLL. Earlier app would still use the version she likes.

I guess late binding via LoadLibrary() can also reduce dll hell.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s