Where to install shared DLLs on Windows

Question

I have a driver which can be installed on Windows (XP/Vista/7). It's accessed via a native C++ DLL that 3rd-party applications link to, and which is also a Winsock Provider (WSP). It used to be installed under System32, but having seen advice not to, I changed it to install under ProgramFiles instead.

Now, the problem is that people are having to either copy it back into System32 or copy it into the application directory whenever they want to use it in their own applications, because Windows won't search the install directory under ProgramFiles when the application tries to load the DLL.

I've been unable to find any Microsoft documentation discussing this issue, so if System32 shouldn't be used then where should shared DLLs be installed?

Answer 1

Anywhere on the path would work.
If this is only to be used with your set of apps (eg Qt4.dll) then in the root of "c:\program files\my company" would be good, or have a 'shared' folder below that.

If it's to be used by other apps that you don't know about (eg a video codec) then system32 makes sense (you will need admin rights when you install)

Answer 2

Fixed filesystem location

One possibility would be to install them in a sub-directory of Program Files, as already suggested by @Martin Beckett.

Variable filesystem location, fixed entry in Registry

If you don't want to install them at a fixed location, you could also store their location in the Windows Registry. You'd install some keys under HKEY_LOCAL_MACHINE\SOFTWARE that your applications could read to find out where the DLLs are located. Then the DLLs can be loaded at run-time.

P.S.: Preventing orphaned DLLs

You could go one step further and use the Registry, or some other storage (a file, say), to store information about which of your applications uses which of your DLLs. For example:

FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll    <- FooApp1, FooApp3
FooBaz.dll    <- FooApp2, FooApp3

Whenever one of your applications is un-installed, it removes itself from this map. Any uninstaller can then safely delete a DLL that is no longer in use by any application. That method is akin to reference-counting, and the idea is to prevent orphaned DLLs from accumulating on users' filesystem.

Answer 3

Since it's a DLL linked to your driver maybe it's less of an issue, but I'd be wary of trying to share the DLL and would instead try to get all developers of client apps to keep their own version of the dll in their applications folders. I've had too much fun in DLL Hell to want any more weird bugs because AppX overwrote the DLL with an old version that breaks AppY etc.

Answer 4

Native DLLs can be stored as side-by-side assemblies. See this reference for more information. This is separate from the .NET Global Assembly Cache, but it uses similar concepts. This blog post also has quite a few useful details about how DLLs get resolved as side-by-side assemblies.

Answer 5

The Windows side-by-side cache. Backgrounder info is here, technical reference is here.

I haven't seen anybody actually do this yet, other than Microsoft. Quite notable is that MSFT gave up on winsxs deployment for the C/C++ CRT and MFC runtime DLLs for VS2010, it was causing too many problems. They're back in c:\windows\system32. The managed equivalent of this (the GAC) is going strong though. Better tool support, probably.

I'm fairly sure that by a large margin everybody chooses app-local deployment.