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

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

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

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

我不能切换到伟大的尖锐的开发，它缺乏一些小的，但我们的调试方案的基本要求。

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

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

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

Answer 1

为了当前编译项目的利益，您可能会遇到VS检查其他新建组件。

构建程序集时，VS将检查目标程序集的引用，如果它们构建得很好或者新版本，可能包括实际将它们加载到.Net域中，这会承担加载程序集的所有负担，就好像你是要去运行它。 随着重建越来越多的项目，构建可能会逐渐变慢。 当一个组件变得更新时，其他组件会做更多的工作。 这是一个可能的解释，为什么建筑本身，而不是已经建成，而不是建筑清洁，所有都有看似相关的不同结果。 它真的是其他人改变了而不是被编译的那个。

VS将“标记”引用程序集的最后一个“内部”构建号，并查看引用的程序集在其构建过程中是否实际更改。 如果没有差别，就会跳过大量的工作。 是的，有一些你无法控制的内部assembly体编号。 这不是以任何方式由于实际的c＃编译器或其工作或任何后编译，而是对于大多数一般情况所必需的预编译步骤。

您可以使用几种面向参考的设置，并且根据您的开发，测试或部署需求，function差异可能无关紧要，但可能会严重影响VS的行为方式以及构建过程中需要多长时间。

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

1）点击参考

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

3）查看’Copy Local’，’Embed Interop Types’，’Reference Output Assembly’; 那些可能是非常适用的，可能是一件好事，无论如何。 我强烈建议查看他们在MSDN上做的事情。 “参考输出组件”可能会也可能不会显示在列表中。

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

---

因此，这里的基本思想是，您希望在构建期间和部署之后将所有这些配置为最便宜的。 如果你一起构建它们，那么你可能真的不需要“复制本地”。 我不想更多地谈论你应该如何配置它们而不了解更多关于你的需求，但是阅读一些关于每个的好段落是一件非常好的事情。 然而，这变得非常棘手，因为在重建引用的一个之前，你也会影响VS是否会使用陈旧的旧版本。 作为进一步解释这些内容的另一个例子，Copy Local 可以使用本地副本，即使它过时，因此拥有此设置可能是双坏。 记住目前的目标是降低VS加载新构建的程序集jsut以编译其他程序的负担。

最后，就目前而言，我可以很容易地说，只停留1.5分钟就是非常幸运。 由于这样的事情，有些人的构建时间要差得多;）

Answer 2

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

Answer 3

我们在Visual Studio 2013中运行的ASP.NET MVC Web项目遇到了同样的问题。我们构建项目并且大约一分钟左右没有任何事情发生，然后输出窗口显示我们正在编译。

以下是修复它的问题…在文本编辑器中打开.csproj文件并将MvcBuildViews设置为false：

 false 

我不得不使用sysinternals进程监视器来解决这个问题，但这显然是我的情况的原因。 该网站现在在不到5秒的时间内编译，以前需要花费一分钟。 在那一分钟，Asp.net编译过程将文件和目录放入Temporary Asp.net Files文件夹。

警告：如果设置了此项，则不会再预编译视图，因此您将无法在构建时查看视图中的语法错误。

Answer 4

听起来很傻，但首先删除所有断点。 它大大加快了我的预建检查 – 但仍然不知道为什么。

Answer 5

一些未提及的故障排除想法：

• 清洁解决方案

• 删除Obj和Bin文件夹？ 仅供参考，Clean和Rebuild都不会删除非构建文件，例如在预构建命令期间复制的文件。

• 关闭VS扫描外部文件。 选项>工具>环境>文档>检测何时在环境外更改文件？

• 回滚SVN历史记录以确认它何时开始发生？ 改变了什么？ 如果第1天的项目文件需要相同的时间，请重新创建项目，添加所有文件并构建。

否则，您可以运行Process Monitor并让我们知道Visual Studio在准备构建阶段正在做什么吗？

Answer 6

根据提供的（有限的）信息，一种可能性是项目文件中指定的预构建操作编译速度慢。

Answer 7

尝试禁用此处所述的平台validation任务。

Answer 8

如果您的各个项目正在正确编译，那么您所能做的就是通过在配置中显式设置相关项目来更改编译顺序。

尝试可视化项目依赖关系层次结构并设置依赖项目。 例如，如果在每个项目中引用了业务实体项目，则在每个项目的配置中，必须将此项目选择为依赖项目。

如果未设置显式构建顺序，Visual Studio将分析项目以创建构建项目的顺序。 设置显式依赖项目wiki使visual studio跳过此步骤并使用您提供的顺序。

Answer 9

由于在单个项目上出现如此极端的延迟而且没有其他途径似乎提供了一个原因，我将尝试在从sysinternals运行procmon时构建该特定项目并过滤掉所有成功消息。 您也可以将其缩小到仅适用于文件系统操作。 从您的描述中我可能会猜到文件被外部源（如事件集合或工作流管理流程服务）锁定。

其他要考虑的事情是这是否是一个完全干净的构建机器，或者它是否已被用于测试构建？ 如果是这样，是否有人有可能直接将IIS应用程序路径映射到项目或将其注册为服务位置？

如果您运行procmon并且看不到明显的锁定或冲突，我会创建一个全新的解决方案和项目并复制文件以查看该项目是否也具有相同的延迟。 如果它确实具有相同的延迟，我将创建一个相同类型的示例项目，但是通用数据（基本上是空的），看看它是否也很慢。 如果具有相同文件的新项目构建正常，则可以对目录进行区分以查看导致问题的方差（可能是配置或项目设置）。