Visual Studio 2015在调试期间锁定DLL

Question

我有三个C#项目A、B和C。 A和B都引用C。从A和B对C的引用设置为“复制本地”，这意味着在将C构建为C.dll（在C的输出目录中）之后，它会被复制到A或B的输出目录中（正在编译的目录）。

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

我发现，如果我从SA启动调试（F5）A，然后（当A仍在调试时），从SB更改C并尝试编译SB，我会收到编译错误，指出无法覆盖C.dll，因为它正在被另一个进程使用（运行SA的devenv.exe实例）。

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

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

自从我开始使用Visual Studio 2015（而不是Visual Studio 2013）以来，这种情况就开始发生。

有没有人有什么想法？我目前的解决方案是通过CTRL-F5（启动而不调试）运行SA，但当我要同时以调试模式运行SA和SB时，这变得很烦人。

谢谢。

更新

我对“编辑并继续”功能可能会导致上述行为的原因进行了一些研究，根据此页面https://msdn.microsoft.com/zh-cn/library/ms164926.aspx>，编辑并继续允许在调试会话中进行源代码修改，并使结果生效而无需停止调试、重新编译和重新启动调试会话（这肯定是一个棘手的问题）。启用该功能后，Visual Studio可能需要随时重新编译任何相关的DLL，这就解释了锁定的原因。

- Shea

---

我的预感是实际上被锁定的是PDB文件。 - Hans Passant

有趣的建议，但是SB编译错误明确指出DLL被锁定，尝试从Windows资源管理器中删除DLL失败。也许PDB也被锁定了（虽然它也被复制到A的输出目录中）。无论如何，我感觉是从VS2013切换到VS2015导致了我看到的行为，希望有一种方法来解决它。错误：无法写入“C:\BUILD\C\x86\obj\Debug\C.dll”--“另一个进程正在使用文件'C:\BUILD\C\x86\obj\Debug\C.dll'。” - Shea

Answer 1

我曾经遇到过同样的问题。我更改了我的VS2015设置，看起来问题已经解决：

• 禁用选项\调试\编辑并继续
• -选项\源代码管理从TFS更改为无-
• -调试时禁用选项\调试\诊断工具-

不确定是哪个导致了锁定，但我怀疑是诊断工具，因为在VS2013中没有它。（我从德语翻译成英语版本的设置名称，不知道它们在英语VS版本中的确切名称。）

编辑：根据Shea的研究，造成DLL锁定的是编辑并继续功能。

- Matmok

---

谢谢！禁用“选项\调试\编辑并继续”对我解决了这个问题。 - Shea

我的VS2015中没有名为“编辑并继续”的设置！ - GorvGoyl

@JerryGoyal 当你通过快速启动搜索时找不到它（他们肯定应该修复这个问题），但是如果你打开调试，你可以找到它。 - Bent Rasmussen

绕过文件锁定错误，关闭整个调试功能并不是一个解决方案。这也是间歇性的；在第一次构建时，我会遇到文件锁定错误，而不关闭正在锁定DLL的其他运行实例（当前项目甚至不需要构建该DLL），第二次尝试构建时则没有问题。 - Triynko

Answer 2

在我的情况下，是“熊猫免费杀毒软件”监视了“C”项目的dll文件，导致出现错误：“由于另一个进程正在使用该文件，因此无法访问该文件”。

- Developer

---

我在调试C# Web应用程序时遇到了同样的问题，禁用“Panda免费杀毒软件”解决了它。 - Dev Shah

Answer 3

在我的情况下，.pdb 文件被锁定了。这与调试时应该锁定的 .exe 不同。

假设只是 .pdb，只需将其移动到新文件夹中（我拖放了它）。奇怪的是，它不能被删除，但肯定可以被移动！一旦 .pdb 文件消失了，程序集就能再次编译。

另一种解决方案（可能是最不方便的）涉及完全关闭项目，然后重新打开它（.pdb 文件会神奇地解锁！）。

编辑：发生第二次后，移动文件没有起作用；似乎重新启动项目是唯一可靠的方法。

- user1618054

Answer 4

我曾经遇到同样的问题，但在搜索互联网时，我找到的其他推荐解决方案都没有起作用。最终，在“修复”Visual Studio 2015 Enterprise之后，我尝试以安全模式启动Visual Studio：devenv.exe /SafeMode

在安全模式下，我终于能够构建我的解决方案了。当我再次启动而没有使用该开关时，我准备逐个关闭扩展程序，直到找到罪魁祸首为止。幸运的是，这是不必要的，随后的构建顺利进行。

- GabeFC