Visual Studio在开始构建之前等待很久

Question

我们有一个中等规模的解决方案,约有20个项目.在其中一个我有我的业务实体.在编译任何项目时,visual studio会在此BusinessEntities项目上等待并挂起大约一分半钟.

我在SharpDevelop中尝试了我们的解决方案,它在18秒内编译了我们的完整解决方案.与MSBuild类似的时机.

我的猜测是VS试图找出项目是否需要编译,但这个过程比实际执行编译慢了大约15倍!

我无法切换到伟大的尖锐开发,它缺乏一些小的,但我们的调试方案的基本要求.

我是否可以阻止VS检查这个项目,并让它在没有这样的检查的情况下编译项目,就像sharpdevelop一样？

我已经知道在配置管理中取消选中项目以防止构建一些项目,但是我的开发人员会忘记他们需要在更新到最新源之后编译这个项目,并且他们面临的问题对他们来说似乎很奇怪.

编辑:有趣的调查结果:延迟发生在其中一个项目中.在配置管理器中,我取消选中所有项目,然后单独编译它们.所有项目都在几秒钟内编译完成!! 关键在于:如果直接构建该特殊项目,则在几秒钟内编译,如果正在构建(或跳过,因为它是最新的),因为构建依赖于它的另一个项目,VS挂起约一分半钟,然后决定编译它(或跳过它).我的结论是:Visual Studio正在检查是否有任何文件被更改,但由于某些原因,对于这个特殊项目来说效率极低!

Answer 1

我去Tools -> Options -> Projects and Solutions -> Build and Run,然后将"MSBuild项目构建[输出|构建日志]详细程度"更改为Diagnostic.在该级别,它将包括可以帮助您追踪问题的时间安排.

Answer 2

为了当前编译项目的利益，您可能会遭受 VS 检查其他新构建的程序集的困扰。

当构建程序集时，VS 将检查目标程序集的引用，如果它们是新构建的或新版本，则可能包括将它们实际加载到 .Net 域中，该域承担加载程序集的所有负担，就像您在要去运行它。随着重建越来越多的项目，构建可能会逐渐变慢。当一个程序集更新时，其他程序集会做更多的工作。这是为什么单独建造、与已建造的建筑、与干净的建筑相比，似乎都有不同的结果的一种可能的解释。确实是其他的改变了，而不是正在编译的那个改变了。

VS 将“标记”引用程序集的最后一个“内部”构建号，并查看引用的程序集在构建过程中是否实际发生了更改。如果没有什么不同，大量的工作就会被跳过。是的，有些内部装配版本号是您无法控制的。这可能不是由于实际的 c# 编译器或其工作或任何后编译而导致的，而是大多数一般情况下所需的预编译步骤。

您可以使用多种面向参考的设置，根据您的开发、测试或部署需求，功能差异可能无关紧要，但可能会深刻影响 VS 的行为方式以及构建期间所需的时间。

转到解决方案资源管理器中的项目之一的引用：

1) 单击参考

2）如果没有打开属性窗格（不是属性页或属性管理器）

3）查看“复制本地”、“嵌入互操作类型”、“参考输出程序集”；这些可能非常适用，并且可能是值得了解的好东西。我强烈建议在 MSDN 上查找他们的工作。“参考输出组件”可能会也可能不会显示在列表中。

4）卸载项目，并在VS中将.proj文件编辑为文本。在 XML 中查找程序集引用并查找“Private”。这意味着从引用程序集的角度来看，引用的程序集是否被视为私有程序集，而不是共享程序集。这是一种冗长的说法，即该程序集是否会与其他程序集一起作为一个单元进行部署。这对于减轻负担非常重要。背景：http ://msdn.microsoft.com/en-us/magazine/cc164080.aspx

因此，这里的基本想法是，您希望将所有这些配置为最便宜的，无论是在构建期间还是部署之后。如果您将它们构建在一起，那么您可能真的不需要“复制本地”。我不想在不了解更多关于您的需求的情况下更多地谈论您应该如何配置它们，但是阅读关于每个的一些好的段落是一件非常好的事情。然而，这会变得非常棘手，因为在重建引用的版本之前进行解析时，您还会影响 VS 是否会使用过时的旧版本。作为进一步的示例，说明最好阅读这些内容，“本地复制”可以使用本地副本，即使它已经过时，因此拥有此集合可能会带来双重坏处。请记住，目前的目标是减轻 VS 加载新构建的程序集（然后编译其他程序集）的负担。

最后，就目前而言，我可以轻松地说，仅悬挂 1.5 分钟就已经非常幸运了。由于这样的事情，有些人的构建时间要差得多;)