Yes. Look how it works. Microsoft wants everyone to reference some assemblies (in .NET, the key unit is assembly, "DLL" is just one of
modules), use some types from them, and all works right away. For this purpose, by default, a separate output file is created for every assembly, per configuration. When you reference the assembly in another project, the executable modules of referenced assemblies are automatically copied to the corresponding (per configuration) output directories of the referencing assembly. Naturally, if that referencing assembly is itself referenced by some other assembly, all those modules are cascade-copied to another output directory, and so on.
Of course, this is not very efficient, but
nobody cares, because the principle "all should work right away" seems to be more important.
If you do serious development, however, and would not mind a bit of extra work for the sake of extra convenience, you can care about that. You can go to the project "Properties" window, the "Build" tab, and change all the relative paths for "Output directories", separately per each configuration. In rare cases when you just have to compile for different
instruction-set architectures (should be avoided whenever possible, "AnyCPU is the best), you do it per each platform-configuration pair.
I would strongly recommend to merge all output directories to one directory, but per configuration.
However, I make a step further and do something which is (too bad) cannot be done directly in the IDE. I manually edit the element
<OutputPath> of the project files to this string
<OutputPath>..\bin.$(Configuration)\</OutputPath>
In a default project, there are only two such elements (per default configurations "Debug" and "Release"), but I make these two elements identical — the MSBuild property system automatically calculates different paths based on configuration names. If all configuration-platfom combinations have to be distinct paths, you can add the property
$(Platform) to this naming schema. The number of ".." varies depending on the depth of the project file in the file structure of the solution.
When you see the result of such manipulations from withing IDE (Visual Studio), you can see correct paths in the property window. Only don't touch it manually in the IDE again, go to the raw project file.
This is easy and considerably simplifies the management of the output files, takes less disk space.
See also my past answer:
Error on Load mytest.dll at runtime.
—SA
Submit an article or tip