devenv.com在VS 2013中卡住了

Question

当在我们的自动化构建中通过命令行或FinalBuilder操作调用devenv.com时，有时会出现挂起并永远无法完成编译步骤的情况。

它是从C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE目录下调用以下参数：

devenv.com /build "Release|Any CPU" "D:\MyProject\MySolution.sln"

在这一步上它一直卡住。当我在VS 2013中打开并重新构建解决方案时，每次都可以正常工作。

有什么想法吗？我还尝试在其他构建机器上运行它，但结果都是一样的。所以问题不是机器相关的。

- Oliver Nilsen

---

дҪҝз”Ёdevenv.comжһ„е»әе·ІеңЁVS2010дёӯиў«ејғз”ЁгҖӮжҳҜж—¶еҖҷиҪ¬еҗ‘MSBuild.exeдәҶпјҢиҝҷеә”иҜҘи¶іеӨҹжҝҖеҠұдәәеҝғ :) еҰӮжһңжӮЁд»Қ然йҒҮеҲ°й—®йўҳпјҢиҜ·еҸ‘еёғдҪҝз”Ё/v jacked-upиҺ·еҸ–зҡ„жһ„е»әи·ҹиёӘгҖӮ - Hans Passant

MSBuild.exe不是一个选项，而是一个策略问题。我们的自动化构建应该与开发人员在VS中本地构建的方式相同。所以你是说我应该将“/v”参数附加到devenv.com吗？ - Oliver Nilsen

当你被非常愚蠢的政策卡住时，很难得到帮助。我必须推荐这个网站：http://careers.stackoverflow.com/。 - Hans Passant

https://connect.microsoft.com/VisualStudio/feedback/details/586358/msbuild-ignores-projectsection-projectdependencies-in-sln-file-and-attempts-to-build-projects-in-wrong-order 和 https://connect.microsoft.com/VisualStudio/feedback/details/586875/msbuild-4-0-incorrectly-processes-project-dependencies-specified-in-solution-file 是关于编程的内容。微软已经将这些问题标记为已解决，但问题仍然存在。这就是为什么VS不信任msbuild进行解决方案处理，而是自己组合依赖关系图，并使用msbuild构建单个项目。使用devenv build是有很多意义的。 - mark

在VS2019中，解决方案或项目文件名需要出现在/build或/rebuild之前。不确定这是否适用于VS2013。 - MikeOnline

Answer 1

经过大量的故障排除和查看各种日志、解决方案以及搜索，我发现这是由于Visual Studio 2013中的扩展管理器引起的。

您可以在所有Visual Studio版本中找到扩展管理器 -> 工具 -> 扩展和更新。

因此，通过从Visual Studio 2013中卸载Nuget包管理器，每次都可以成功编译解决方案。

- Oliver Nilsen

---

任何想法为什么扩展名会导致失败？ - Steve L.

我在VS 2010上安装了包管理器，看起来还不错。但是版本不同。VS 2010使用的是v2.7，而VS 2013使用的是2.8。 - Steve L.

Answer 2

我们注意到并且可以每次重现的另一个修复方法是，当我们的Hyper-V虚拟机被分配了2个CPU时，构建每次都会挂起。将虚拟机减少到只有1个CPU可以解决问题。

- Oliver Nilsen

Answer 3

我们通过创建一个新的 .sln 文件并向其中添加现有项目来解决了这个问题。NuGet 信息现在已从 .csproj 文件中删除，我们现在使用 "nuget.exe restore" 在调用 devenv.com 之前更新 NuGet 包。这已经为一些项目解决了这个问题。

- Oliver Nilsen