Where to install SDK DLLs on a system so that they can be found by apps that need them.

Question

I've got an SDK I'm working on and the previous developer just dropped the DLLs in System32 (Apparently a serious offense: see here)

So assuming I move them out into \Program Files\\SDK (or whatever), how do I make sure that all the apps that needs those DLLs can access them? And to clarify, all apps that access these are doing early (static) binding to the DLLs at compile time so I can't pass the full path to them or anything. They need to be able to find it just given the DLL filename only.

Along the same lines, what about including a particular version of MSVCR80.dll? They all depend on this but I need to make sure they get a specific version (the one I include). Any ideas?

Answer 1

You can put your install path in the search path, which will allow the applications to find them.

Alternatively, you can deploy the DLL's into the same directory as the application that depends on them.

I believe the first is better from an SDK perspective - it'll make development easier. But I think the second is better for when the application gets deployed to end-users, unless you expect there may be many consumers on a single system so the disk and memory footprint of having copies of the DLL are prohibitive.

Answer 2

If you can't install the dlls into the same directory as the exe using them you could append your directory to the PATH environment variable.

You don't say which version of Windows you're using, as the details are slightly different from what I remember.

You could also put your version of MSVCR80.dll in the same folder. However, you'd have to ensure that your folder was before the system one on the path otherwise the linker would pick up the "standard" one first. However, if you adopted the "local" dlls approach then you wouldn't have this problem as Windows searches the local directory first and so will pick up your version of MSVCR80.dll.

Is your version the latest or a previous version? You might be better off getting your app to work with that version or later and then allow the users to update their machines as required. This also illustrates why you should never mess with the dlls in \Windows or \Windows\system32 as, as others have pointed out, you could break other applications by changing the version of this dll.

Answer 3

Hi again, ;) An SDK is by definition a development kit. It's not a deployment patch...

What this means is that the applications that depend on those assemblies should ship with them and install them into their local \program files.. directories.

The reason for this is let's say you decide to do a breaking change by eliminating an entry point for example. By installing your "SDK", it has the potential to stop older programs from functioning.

You could take a play from the Java handbook and update the PATH environment variable. Whenever a program makes a call to an external assembly it searches along that environment variable until it finds it.

Of course, this could still result in the problem showing up. So your best bet is to just install the SDK into Program Files and let the developers of the products that depend on your toolkit decide whether they want to update their versions or not.

UPDATE

As I'm thinking about this, one last possibility is to GAC your assemblies. In the event you do so, bear in mind that they should be strongly named and properly versioned so as not to step on each other. I don't recommend this route because it hides the actual locations of the assemblies and makes uninstalling a little more difficult then simply hitting delete on your directory.

Answer 4

You are asking about "DLL Hell", something I had thought every Windows developer was familiar with. The order of search for DLLs is:

• the directory the exex that calls them was loaded from
• the current directory
• various Windows directories (as discussed in your previous question)
• directories in the PATH variable

As the Windows directories should be ruled out, that leaves you with three options.

Answer 5

I can't tell you about your own DLLs, but you should never redistribute Microsoft DLLs alone.

You always have to use Microsoft Redistributable Package.

For example, if your application depends on dll from Dev Studio 2005 SP1, you should redistribute your application with Microsoft Visual Studio 2005 SP1 redistributable. The same applies to 2008. MS provide MSI based installer and Merge Module to include in your own product installer.