为什么 Visual Studio 将 DLL/EXE 复制到 C# 中引用的项目构建文件夹中？

Question

Say I have four projects:

ABCD

such that A references B, B references C and C references D.

It appears in visual studio (2017) that building A also triggers a build in B, C, D, as is expected. It only builds them once. However, it seems the build copies the DLLs into each projects bin directory, leaving the directory structure (assuming building in Debug mode) looking something like this:

A -> bin -> Debug -> A.exe, B.exe, C.exe, D.exe

B -> bin -> Debug -> B.exe, C.exe, D.exe

C -> bin -> Debug -> C.exe, D.exe

D -> bin -> Debug -> D.exe

This seems to imply that there is an O(n^2) where n is the number of projects (and they references each other like so) in terms of the number of executables/dlls copied . This results in terrible scaling of the build time versus the number of projects. However having more projects becomes very necessary for increased granularity of files.

In the worst case, for n projects, adding another project results in (n + 1) extra file copies, using the (1 + 2.. + n) = (n(n+1))/2 formula.

Why does visual studio do this? Why not just copy only to A's bin directory? The only advantage I see to the current approach is that you can run DLLs/EXEs in the bin folders of B, C and D.

Answer 1

Looks like this behaviour can be turned off. The name for this is the copylocal property in visual studio. If you turn this off, then you are now responsible for copying the DLLs manually to where an output folder (for example, via a custom MSBuild step).

These questions deal with it well:

What is the best practice for "Copy Local" and with project references?

Best practices for large solutions in Visual Studio (2008)