文涛-
问题描述
我有一个大型 c# 百家乐凯发k8的解决方案文件(约 100 个项目)，我正在努力缩短构建时间.我认为复制本地"在很多情况下对我们来说是一种浪费，但我想知道最佳实践.
i have a large c# solution file (~100 projects), and i am trying to improve build times. i think that "copy local" is wasteful in many cases for us, but i am wondering about best practices.
在我们的 .sln 中，应用程序 a 依赖于程序集 b，而程序集 b 又依赖于程序集 c.在我们的例子中，有几十个b"和少数c".由于这些都包含在 .sln 中，因此我们使用的是项目引用.当前所有程序集都构建到 $(solutiondir)/debug(或 release)中.
in our .sln, we have application a depending on assembly b which depends on assembly c. in our case, there are dozens of "b" and a handful of "c". since these are all included in the .sln, we're using project references. all assemblies currently build into $(solutiondir)/debug (or release).
默认情况下，visual studio 将这些项目引用标记为复制本地"，这会导致每个c"被复制到 $(solutiondir)/debug 中，对于每个构建的b".这似乎很浪费.如果我只关闭复制本地"会出现什么问题?其他拥有大型系统的人是做什么的?
by default, visual studio marks these project references as "copy local", which results in every "c" being copied into $(solutiondir)/debug once for every "b" that builds. this seems wasteful. what can go wrong if i just turn "copy local" off? what do other people with large systems do?
跟进:
很多回复建议将构建分解为更小的 .sln 文件...在上面的示例中，我将首先构建基础类c"，然后是大部分模块b"，然后是一些应用程序，a".在这个模型中，我需要从 b 获得对 c 的非项目引用.我遇到的问题是调试"或发布"被纳入提示路径，我最终构建了b"的发布版本针对c"的调试版本.
lots of responses suggest breaking up the build into smaller .sln files... in the example above, i would build the foundation classes "c" first, followed by the bulk of the modules "b", and then a few applications, "a". in this model, i need to have non-project references to c from b. the problem i run into there is that "debug" or "release" gets baked into the hint path and i wind up building my release builds of "b" against debug builds of "c".
对于那些将构建拆分为多个 .sln 文件的人，您如何处理这个问题?
for those of you that split the build up into multiple .sln files, how do you manage this problem?
推荐答案
在之前的项目中，我使用了一个带有项目引用的大型百家乐凯发k8的解决方案，但也遇到了性能问题.百家乐凯发k8的解决方案是三倍:
in a previous project i worked with one big solution with project references and bumped into a performance problem as well. the solution was three fold:
始终将 copy local 属性设置为 false 并通过自定义 msbuild 步骤强制执行此操作
always set the copy local property to false and enforce this via a custom msbuild step
将每个项目的输出目录设置为同一个目录(最好相对于$(solutiondir)
set the output directory for each project to the same directory (preferably relative to $(solutiondir)
框架附带的默认 cs 目标计算要复制到当前正在构建的项目的输出目录的引用集.由于这需要在参考"关系下计算传递闭包，这可能会变得非常代价高昂.我的解决方法是在导入 microsoft 后在每个项目中导入的通用目标文件(例如 common.targets )中重新定义 getcopytooutputdirectoryitems 目标.csharp.targets.导致每个项目文件如下所示:
the default cs targets that get shipped with the framework calculate the set of references to be copied to the output directory of the project currently being built. since this requires calculating a transitive closure under the 'references' relation this can become very costly. my workaround for this was to redefine the getcopytooutputdirectoryitems target in a common targets file (eg. common.targets ) that's imported in every project after the import of the microsoft.csharp.targets. resulting in every project file to look like the following:
... snip ...
这将我们在给定时间的构建时间从几个小时(主要是由于内存限制)减少到了几分钟.
this reduced our build time at a given time from a couple of hours (mostly due to memory constraints), to a couple of minutes.
可以通过从 c:window**icrosoft.netframeworkv2.0.50727microsoft 复制第 2,438–2,450 和 2,474–2,524 行来创建重新定义的 getcopytooutputdirectoryitems.common.targets 变成 common.targets.
the redefined getcopytooutputdirectoryitems can be created by copying the lines 2,438–2,450 and 2,474–2,524 from c:window**icrosoft.netframeworkv2.0.50727microsoft.common.targets into common.targets.
为了完整起见，生成的目标定义变为:
for completeness the resulting target definition then becomes:
有了这个解决方法，我发现在一个百家乐凯发k8的解决方案中拥有多达 120 个项目是可行的，这主要的好处是项目的构建顺序仍然可以由 vs 确定，而不是通过拆分手动完成提出你的百家乐凯发k8的解决方案.
with this workaround in place i found it workable to have as much as > 120 projects in one solution, this has the main benefit that the build order of the projects can still be determined by vs instead of doing that by hand by splitting up your solution.
