How can I organize third-party Windows DLLs into a subfolder in the application folder?

Question

We have an application that depends on a number of groups of third-party DLLs. Unfortunately, none of the authors of these third-party DLLs named them very sequentially, so it is difficult to understand which DLL is part of which group.

To try to manage this, we would like to place groups of third-party DLLs in a folder in our application folder, and not on the application side, 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 it manually using LoadLibrary () and GetProcAddress (), but it is very tedious. It looks like we could do this with manifests and "sensing", but it only looks like Windows 7 (we need to work with XP and above).

Update

We used manifests to do this at the end (thanks @Chris) - there were several other hoops that we had to jump over if someone was looking for a solution!

Firstly, our “assembly” actually has several DLLs that we associate with them, and then refer to others. For all these DLLs, you will need to add the assembly to their manifests (you can use mt.exe to do this without having access to the source code of these DLLs).

Secondly, the assembly should go along with the DLL, and not next to the EXE - our DLL was actually a plugin that was already in the application subfolder.

Here is our final layout:

 --> Application Folder --> Application.exe --> Plugins folder --> MyDLL1.dll --> Third Party 1 --> Third Party 1.manifest --> A.dll --> B.dll --> C.dll 

If MyDLL1.dll is a plugin that references A.dll and A.dll links to B.dll and C.dll, then:

• "Third Party 1.manifest" should include all A.dll, B.dll and C.dll files as an assembly
• "MyDLL1.dll" needs to write a dependency in its manifest for "Third Party 1", or the dynamic linker will not find A.dll
• A.dll needs a dependency record in its manifest for "Third Party 1" or the dynamic linker will not find B.dll and C.dll
• The "Third Party 1" folder should go next to "MyDLL1.dll", and not next to "Application.exe"

For me (3) is a bit annoying. You might think that the linker would look in the assembly for the dependent DLLs.

Answer 1

You can do this with manifests without probing. Create fake assemblies by defining .manifests containing DLLs. (No changes to the dll are required for this) Since assembly support was added in NT 5.1 (Windows XP), the window loader first searches for assemblies by looking at the folder with the assembly name.

So, for example, if you need to distribute the Microsoft Visual C environment for Visual C 2008 with your application, you can 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 

The same scheme will work for your third-party DLLs. All you would have to do is add the “fake” assemblies as dependent assemblies to the application manifest (if your DLL files have manifests (and they access the third-party DLLs), then their manifests should also have entries.

The manifest files that describe assemblies need an assemblyIdentity file and a node file for each 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> 

Both your application and dll are created using MS Visual Studio 2005 or later, the following pragma directive will force your application to look for DLLs in assemblies:

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

Answer 2

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