【发布时间】：2019-11-16 17:19:07
【问题描述】：
假设我有四个项目：
一个 乙 C D
使得 A 引用 B，B 引用 C，C 引用 D。
在 Visual Studio (2017) 中显示，正如预期的那样，建筑 A 也会触发 B、C、D 中的构建。它只构建一次。但是，似乎构建将 DLL 复制到每个项目的 bin 目录中，使目录结构（假设在 Debug 模式下构建）看起来像这样：
一个 -> 斌 -> 调试 -> A.exe、B.exe、C.exe、D.exe
B -> 斌 -> 调试 -> B.exe、C.exe、D.exe
C -> 斌 -> 调试 -> C.exe、D.exe
D -> 斌 -> 调试 -> D.exe
这似乎暗示有一个 O(n^2) 其中 n 是项目的数量（并且它们像这样相互引用）就复制的可执行文件/dll 的数量而言 .这导致构建时间与项目数量的可怕缩放。然而，拥有更多的项目对于增加文件的粒度变得非常必要。
在最坏的情况下，对于 n 个项目，添加另一个项目会导致 (n + 1) 个额外的文件副本，使用 (1 + 2.. + n) = (n(n+1))/2 公式。
Visual Studio 为什么要这样做？为什么不只复制到 A 的 bin 目录？我看到当前方法的唯一优势是您可以在 B、C 和 D 的 bin 文件夹中运行 DLL/EXE。
【问题讨论】：
-
为什么人们反对这个？在盲目地否决它之前，请尝试理解我在问什么。对于 Visual Studio for C# 中的大型解决方案来说，这是一个严重的问题。
标签： c# visual-studio msbuild