How can I organise third-party Windows DLLs into a subfolder in my application folder?

Question

Hi,

We have an application that depends on a number of groups of third-party DLLs. Unfortunately, none of the writers of these third-party DLLs have named them very consistently so it is hard to see which DLL is part of what group.

To try and manage this, we would like to put groups of third-party DLLs in a folder in our application folder rather than along-side the application something like this.

--> Application Folder
    --> Application.exe
    --> MyDLL1.dll
    --> MyDLL2.dll
    --> Third Party 1 DLL folder
        --> Third Party 1 DLL 1.dll
        --> Third Party 1 DLL 2.dll
        --> Third Party 1 DLL 3.dll
    --> Third Party 2 DLL folder
        --> Third Party 2 DLL 1.dll
        --> Third Party 2 DLL 2.dll
        --> Third Party 2 DLL 3.dll

My question is how to get the dynamic linker to find them and load them?

We could do this manually with LoadLibrary() and GetProcAddress(), however this is intensely tedious. It looks like we might be able to do this with manifests and "probing", but this seems to be Windows 7 only (we need to work on XP and above).

Answer 1

You can use SetDLLDirectory function to specify path(s) for your DLLs. Alternatively read information about using application-specific paths.

Answer 2

You can do it with manifests without probing. Create "fake" assemblies - by defining .manifests, that contain the dlls. (No change is requried in the dll's for this) Since assembly support was added to NT 5.1 (Windows XP) the windows loader first looks for assemblies by scanning for a folder with the assemblies name.

So, for example, if you need to distribute the Microsoft Visual C runtime for Visual C 2008 with your application, you could create a folder structure that looks like this:

--> Application Folder
  --> Application.exe
  --> MyDll1.dll
  --> MyDll2.dll
  --> Microsoft.VC90.CRT
    --> Microsoft.VC90.CRT.manifest
    --> msvcr90.dll
    --> msvcp90.dll
    --> msvcm90.dll

This same scheme would work for your 3rd party dlls. All you would then need to do would be to add the "fake" assemblies as dependent assemblies to your application's manifest (if your dlls have manifests, (and they access the 3rd party dlls) then their manifests will have to have entries too.

The manifest files describing the assemblies need an assemblyIdentity, and a file node per dll:

<assembly manifestVersion="1.0">
  <assemblyIdentity type="Win32" name="Assembly Name" version="1.0.0.0" processorArchitecture="x86" />
  <file name="dll1.dll" />
  <file name="dll2.dll" />
</assembly>

And your application, and dlls are built with MS Visual Studio 2005 or later, the following pragma directive would make your app look for the dlls in the assemblies:

 #pragma comment(linker, "/manifestDependency:\"name='Assembly Name' processorArchitecture='*' version='1.0.0.0' type='win32' \"")