Clarification needed: How does .NET runtime resolve assembly references from parent folder?

Question

I have the following output structure of executables in my solution:

%ProgramFiles%
    |
    +-[MyAppName]
          |
          +-[Client]
          |     |
          |     +-(EXE & several DLL assemblies)
          |
          +-[Common]
          |     |
          |     +-[Schema Assemblies]
          |     |     |
          |     |     +-(several DLL assemblies)
          |     |
          |     +-(several DLL assemblies)
          |
          +-[Server]
                |
                +-(EXE & several DLL assemblies)

Each project in solution references different DLL assemblies, some of which are outputs from other projects in solution, and others are plain 3rd-party assemblies. For example, [Client] EXE might reference an assembly in [Common], which is in a different directory branch.

All references have "Copy Local" set to false, to mirror the layout of the files in the final installed application.

Now, if I take a look at reference properties in the Visual Studio IDE, I see that "Path" of every reference is absolute and that it corresponds to the actual output location of the assembly. That's understandable and correct. As expected, solution compiles and runs just fine.

What I don't understand is, why everything seems to work even when I close the IDE, rename the [MyAppName] directory and run the [Client] EXE manually? How does the runtime find the assemblies if the reference paths aren't the same as they were at the time of linking?

To be clear - this is actually exactly what I'm after: a semi-dispersed set of application files that run fine regardless of where the [MyAppName] directory is located or even what it's named. I'd just like to know, how and why this works without any specific path resolution on my part.

I've read the answers to this similar question, but I still don't get it.

Help much appreciated!

Answer 1

AFAIK the only solution is to have at least "stub" exes in MyAppBase and then define subdirectories as sources for DLL's in app.config for each application.

NTFS does support "mounting" other directories (ie. hard links) as subdirectories, but they're very unautomatic and since I've not tried going that way except theoretizing, I can't tell if that would work as a hack.

Answer 2

Here's how .Net finds the assemblies that are needed: http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

Step 4 is what might be interesting for you to read: http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

Answer 3

Have you considered using GACutil to add your shared assemblies to the Global Assembly Cache

Answer 4

Maybe the Common folder was specified as a binpath parameter when it was compiled?

(See Probing the Private binpath)

http://msdn.microsoft.com/en-us/library/15hyw9x3%28VS.71%29.aspx

-Matt