The Old Joel on Software Forum: Part 4 (of 5) - DLL deployment best practices

DLL deployment best practices

In this thread I asked wether I could build a statically linked application using VC++. The short and only answer was yes, but this caused a massive discussion about DLL Hell.

Now, another question, are there any best practices regarding the deployment of DLL's? Any written text considered to be the norm? What do you personally do?

RP
Tuesday, April 27, 2004

The thread is this one:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=135989&ixReplies=13

RP
Tuesday, April 27, 2004

Unless disk space is at a premium (which isn't usually the case these days), I put all the DLLs in my app's dir. When the user removes the app, the DLLs are also removed. Nothing else uses those DLLs except my app.

I don't care if the user has dozens of versions of the DLLs I need on disk. It takes up more space, but, IMHO, give the user less problems.

Paulo Caetano
Tuesday, April 27, 2004

If I absolutely have to use DLLs, I _always_ put them in the application directory if it is possible. Unfortunately if the DLL contains COM objects it can get a little trickier.

For my projects I've gone from using runtime DLLs and COM objects to linking statically and embedding the COM objects in the executables that use them. Yes, it does result in a little wasted space, but we got too many support calls because of DLL mismatch and COM problems. It's amazing how some people manage to screw up their installs in ways you never thought possible.

Standalone executables is definitely the way to go if you can.

sid6581
Tuesday, April 27, 2004

I can't find the link now, but Microsoft recommends that you put all DLLs (even - sigh - system DLLs like MSVCP70.DLL) in your application's directory. This is essentially a final surrender to "DLL Hell".

Grumpy Old-Timer
Tuesday, April 27, 2004

The solution to DLL is simple.

Distinguish between feature releases and bug fix releases of your DLL. For purely bug fix releases, that don't change ANY behavior, you MIGHT be able to get away with releasing the DLL with the same name (I highlight MIGHT, because the truth is, people might write code to work around your bug, and then you break their code when you fix the bug).

Otherwise, different versions of DLLs should NOT be named the same. That way, if they are put into shared places, then only the proper version is used.

The better solution is, in my opinion, the side by side execution model of .NET. I believe this is also available for traditional DLLs, but only on recent versions of Windows (I believe only on Windows XP or later).

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, April 27, 2004

On Win2K and higher, you can create a zero byte file in the app directory called App.exe.local where App is the base name of your EXE. This causes the OS to look for all DLLs (including COM DLLs) in your app folder first, rather than through the normal mechanism.

Microsoft has an article of DLL redirection somewhere...

Bill Carlson
Tuesday, April 27, 2004

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/sidebyside.asp

Dennis Forbes
Tuesday, April 27, 2004