Question

I have a Windows, C++ software project (built with Visual Studio 2005, SP1) that has the following (simplified) file layout:

{App. Root Directory}
|-- bin
|   |-- Microsoft.VC80.CRT
|   +-- Microsoft.VC80.MFC
+-- utils

There are various executables that live in both the bin and utils directories. Each of these executables rely on the side-by-side assembly (C++ run-time DLLs) that we store in bin, but we have segregated them into these separate folders for various reasons (e.g., the exes in the utils folder are supplemental tools to our primary application, and are run infrequently). As a direct result of this file organization, the apps in the utils folder fail to run on systems that don’t already have the appropriate side-by-side assembly installed (they fail with the usual “The system cannot execute the specified program” error message).

My Question: Is there a way I can tell the apps in the utils folder to explicitly look in the ..\bin folder for the appropriate side-by-side assembly? The Assembly Searching Sequence article at Microsoft makes no mention of this being possible or not. Is there a clever way I can fix this run-time requirement for these applications?

Potential Options I See:

1. Place a copy of the side-by-side assembly into the utils folder. This could be done at run-time (to prevent bloating our application installation package), but seems a little dirty.
2. Statically link the run-time DLL’s. I don’t want to do this!
3. Have the end user install the usual redistributable package. I’d rather not do this either.

Answer 1

My first response is, what actual benefit is derived from separating the utilities from the .\bin folder? Having OCD tendencies myself, I understand the sense of neatness but it seems a bit pointless to continue a practice once it so tangibly can be seen to negatively effect your ability to deploy your application.

That said, it is actually technically possible. To do this you make use of the probing privatePath element in your app.config file.
Application config files work similarly to application manifests, except that they cannot be embedded as resources: Create a file, in the same folder as the exe, with the exe’s full name (including exe extension) and append .config.

<!-- acme.exe.config -->
<configuration>   
  <windows>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;..\bin" />
    </assemblyBinding>
  </windows>
</configuration>

There are a number of caveats that make this solution potentially unworkable – any dll’s that specify their own dependent assemblies need to have an application config file with a probing privatePath element.
Also support for the probing node was only added in Windows NT 6.0 (Vista) so this solution is inappropriate if you still need to target XP.