views:

38

answers:

1

I have a couple of isolated applications that I am writing that all rely on dlls that are also written by myself and team. Things were fine when we only had a few dlls but not the build output directory is getting rather cluttered and hard to navigate. I would ultimately like to have the output build directory contain the following structure:

  • $(OutDir)
    • --(Application.exe)
    • --(Application.exe)
    • --Libs Folder
      • --(LibA.dll)
      • --(LibB.dll)
      • (etc)

Is there a way to have the applications look in the "Libs Folder" for these libraries at runtime using something like the manifest files?

A: 

Dynamic-Link Library Search Order describes what possibiites you have to modify the search path. It describes the search order and mentions manifests and the SetDllDirectory() function as possibilities of changing the search order.

While SetDllDirectory looks promising, it only will reliably work if you dynamically load your DLLs, which you don't do from what I understand.

Now, as to using manifests: Application Configuration Files talks about a privatePath attribute that can be used to [specify] the relative paths of subdirectories of the application's base directory that might contain assemblies. It sound to me as if it's only supposed to work for side-by-side assemblies but you may want to give it a try.

I will readily admit I have never bothered with manifests (except for what you need to know in VS 2005 to get anything running at all) and I would recommend to skip the idea of the library subdirectories for implicitly loaded DLLs and put them in the app directory and be done with it. For explicitly (dynamically) loaded DLLs, you can just deduce their full path from your executable path and supply that to LoadLibrary() and don't need to bother with the search path either.

Martin