[Tip]dotNet project Add Reference

We are so used to adding dotNet module references and project references, but rarely meet situations requiring adding other dotnet module directly. The Other dotnet module consists of 3 kinds:
--precondition of installing my app. Like installing a acad addin app requires ACAD to be there as precondition. So refering to ACAD modules requires NOT adding
the referred dlls adding into my app installer.
--my app's 3rd party library. My app installer should make sure deploying required modules into user machine.
--my app's component modules. NP here..

The question is: how to add a local-directory dependent dotNet module as reference and can still keep this project compiled successfully and deployed successfully?

Well, to answer it, we need to understand:

1. how dotnet CLR locates a assembly at runtime.

Firstly, it totally has no relationship with the local directory you specified in the VS project for adding reference. In my understanding, building the dotnet project will embed its dependent assmemblies into its manifest file while it doesn't contain where to find it and its platform (x32/x64) info. When at runtime, CLR will follow its locating rule and its platform version to find and load required assembly. I didn't read enough. so still put articles below for further reading:
http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx http://support.microsoft.com/kb/837908#appliesto http://msdn.microsoft.com/en-us/library/4191fzwb.aspx
and two books:

a. Don Box's "Essential dotNet"

b. and Steven Pratschner's "Customzing the Microsoft .NET Framework CLR"

which has detailed description on .NET runtime's assembly binding andloading.

2. what about CLR's handling of x32 / x64 in loading assembly for dotnet application?

NOT ready more yet.. need further reading.

3. What's the correct way to add reference about a separate dotnet dll living in a local directory?

You need to add $(XX)---environment variable into project file manually instead of using VS to specify the local path so that on the build machine and other's machine, as we share the same set of environment variables, so in this way, the project building can be no problem; while it has no relationship with the deployment of the refered dotnet modules.

Refer to: http://blog.csdn.net/ham235/archive/2010/08/09/5800073.aspx
Coming here, it's resolved.