小编She*_*hea的帖子

我有3个C#项目A,B和C.A和B都引用C.对A和B的C的引用设置为"Copy Local",暗示在C之后构建到C.dll(在C的输出目录中) C),它被复制到A或B的输出目录(无论哪个编译)

我有2个解决方案,SA和SB.SA包含A和C,SB包含B和C.我启动了Visual Studio 2015的2个实例.我在一个实例中打开SA,在另一个实例中打开SB.

我发现如果我从SA开始调试(F5)A,然后(当A仍在调试时),从SB更改C并尝试编译SB,我收到一个编译错误,说明C.dll不能被覆盖,因为它正在被另一个进程(运行SA的devenv.exe实例)使用.

这对我没有意义,因为在将C编译为C.dll并复制到A的输出目录之后,Visual Studio应该释放对该文件的锁定.

我已经验证(通过SA中的Modules窗口)已加载的C.dll版本是已复制到A的输出目录的版本.

这开始于我昨天开始使用Visual Studio 2015(而不是Visual Studio 2013)时.

有没有人有任何想法？我目前的解决方案是通过CTRL-F5运行SA(无需调试即可启动),但是当我想同时在调试模式下运行SA和SB时,这会变得很烦人.

谢谢.

UPDATE

我做了一些研究,为什么"编辑并继续"功能可能会导致所描述的行为,并根据此页面https://msdn.microsoft.com/en-us/library/ms164926.aspx >编辑并继续允许一个在调试会话中进行源代码修改,并使结果生效,而不必停止调试,重新编译和重新启动调试会话(这是一个多么严重的问题).启用该功能后,Visual Studio可能需要随时重新编译任何相关DLL,以解释锁定.

使用Visual Studio 2015,我注意到如果我打开了一个包含所有解决方案的公共项目的多个解决方案,如果我编辑并保存属于公共项目的一个.cs文件,则所有Visual Studio 2015实例将消耗10个CPU -15秒 请注意,常见项目相当大.

我不记得在Visual Studio 2013中发生这种情况.在我的工作流程中,通常使用引用公共项目的解决方案打开8-9个Visual Studio实例是很常见的,所以我觉得我会注意到Visual Studio的这种行为2013(我的开发机器有32 GB的RAM,这使得这种工作流程成为可能).

我试过了:

1. 禁用CodeLens
2. 卸载ReSharper
3. 禁用工具 - >选项中的四个C#Intellisense功能
4. 暂时禁用静态代码分析解决方案(适用于所有已加载的解决方案)

我还启动了一个单独的Visual Studio 2015实例,启用了Microsoft符号服务器,并在消耗高CPU时启动了(通过Debug-> Profiler-> Performance Explorer - > Attach/Detach)一个有问题的Visual Studio实例.

此图显示了分析器摘要,您可以从图中看到~12s和~27s之间的高CPU使用率.

84.46%的样本在Thread :: intermediateThreadProc中,并且大多数是独占样本,但是在包含样本中,似乎它正在进行某种代码分析.

有了这些信息,我假设正在对所有Visual Studio 2015实例(包括后台实例)执行某种背景代码分析.有谁知道如何禁用它？或者如果我的假设不正确,还有其他建议吗？

更新9/12/2015 有趣的是,如果我使用安装的ReSharper 9.2执行相同的分析,我会得到类似的结果,但使用JetBrains.Platform.Satellite.exe位于"Hot Path"的根目录(而不是devenv.exe) .

2015年10月11日更新

我相信这是问题所在:

如何在Visual Studio 2015中禁用实时编译

有没有办法在保存时禁用实时编译？或者至少它不是那么具有侵入性？最可能遵循"保存"的操作是"构建",并且因为所有可视工作室实例都在重新编译它们各自的解决方案(没有被询问),所以活动解决方案中的"构建"操作受到严重阻碍.