This is how it is resolved in most general (custom) case:
http://msdn.microsoft.com/en-us/library/ff527268.aspx[
^].
However, I wouldn't advice your to go for it. Please also see my comment to the question.
I personally do just the opposite: I put the
source code of AForge.NET in the same solution with my application projects, and I references the assemblies by project (the "Projects" tab of the Visual Studio "Add Reference" window), which give me an additional abstraction layer, should I change some paths, the build is not destroyed. Additionally, it gives me the opportunity to vary Platform/Configuration of the whole solution by one common option. (Moreover, at this time I use the custom AForge.NET build, only some subset I really need; and I manually assembled the AForge.NET project out of separate source files. Not to recommend it, just to give an idea that this is easy enough.)
By the way, one more advice, not related to the question, but in neighboring area related to project/solution setup:
By default, when you add projects to solution, output goes to individual "bin/Release", "bin/Debug" directories per project. When some assembly depends on others, all required dependency assemblies are copied to its output directory. This way, you end up with multiple copies of the same assemblies after the build. This is very redundant, by why is it so? Microsoft does it for one purpose: to make all added and depended project "work right away". This is not your goal in an advanced product. So, I modify all output paths to some common directory on top. Like this: "../../bin.$(Configuration)" or even, when some platform-dependent solutions "../../bin.$(Configuration).$(Platform)".
(To make different platforms compilations for the same .NET project, you need to use Configuration Manager; I hope this is not within your scope now; it's always the best to use "AnyCPU" platform in all cases when it is possible.)
Now, the problem is: if you do it through Visual Studio, such path using MSBuild
property references
will make '$' be escaped (!) won't be resolved into the property value, so such "macro definition" if the path won't work (but it does work for C++). The workaround is simple: 1) in Visual Studio, manually enter "../../bin.Release" and "../../bin.Debug" (for example), per configuration, or 2) alternatively, use some text editor and manually enter "../../bin.$(Configuration)" in the project file. When you activate Visual Studio, it will request reloading the project, after it is reloaded, it will work as desired.
—SA