2

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.
ildjarn
  • 62,044
  • 9
  • 127
  • 211
Jonah Bishop
  • 12,279
  • 6
  • 49
  • 74

1 Answers1

4

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.

Chris Becke
  • 34,244
  • 12
  • 79
  • 148
  • I have seen your posts here & elsewhere and tried to apply it for my case but it doesn't seem to work if you only deploy dlls and you want to have an acme.dll.config. The exact same content you have posted above on a dll configuration file seems to have no effect. – ForeverLearning Dec 15 '16 at 19:49
  • Are you sure the dll doesn't contain a manifest as a resource? – Chris Becke Dec 19 '16 at 07:47
  • thanks for getting back to me. I found a different way to do this but its too lengthy to explain it in a comment section. Will try to put it up somewhere on github for a wider audience. – ForeverLearning Dec 19 '16 at 17:17