有没有办法*完全*禁用编辑并继续？答案

【问题标题】：Is there a way to *completely* disable Edit and Continue?有没有办法*完全*禁用编辑并继续？
【发布时间】：2011-01-04 05:50:34
【问题描述】：

我想知道是否有办法在 Visual Studio 2008 中调试代码时完全锁定我的代码。作为 64 位应用程序运行时，代码文档会自动锁定，我非常喜欢；但是，我的大部分编码都是为 32 位的 Excel 制作插件。结果是，即使我以“AnyCPU”为目标，VS 主机也知道它在 32 位进程中运行，因此，当代码运行在 Visual 中时，源代码不会被锁定工作室。

我可以通过转到工具 > 选项 > 调试 > 编辑并继续，然后取消选中“启用编辑并继续”复选框来关闭编辑并继续。然而，这并没有完全锁定代码。这确实会阻止代码中的任何编辑在当前运行中执行，但不会阻止鼠标单击或击键实际更改代码。

同样，在使用 64 位应用程序时不会发生这种情况——代码完全锁定。我非常喜欢将代码完全锁定，至少有两个原因：

在调试时我可能会不小心按到某个键或类似的东西，我绝对不想这样做。这很少见，但这是一个问题。
我的许多自动化测试通过 SendKeys 驱动用户界面。但是，当使用调试器逐步完成此类测试时，我有时会忘记某些方面涉及 SendKeys，这意味着击键最终会被发送到 Visual Studio IDE 而不是 Excel。

在上面的问题 #2 中，单元测试失败了，这很好——我的错——但是将所有击键发送到代码模块并破坏我的代码是完全不可接受的。

这里有人有什么想法吗？在 Visual Studio 中运行并针对 32 位 CPU 编译时，可以完全锁定代码吗？

关于这个问题的一些相关帖子，但没有一个直接解决这个问题：

提前感谢您的任何帮助或想法...

迈克

【问题讨论】：

请注意，与外部软件对话的单元测试称为集成测试。
@Lasse：好的，很公平。我将把上面的内容编辑为“自动化测试”，因为我正在运行一套从孤立的单元测试到集成测试的测试。谢谢。不过，这并不重要——问题在于 SendKeys，无论您要考虑哪种测试。

标签： c# visual-studio-2008 debugging editing edit-and-continue

【解决方案1】：

这是我在 Visual Studio 2005 下使用的一个技巧（没有机会在 Visual Studio 2008 下测试，但应该可以）：

打开可执行程序集的属性
转到调试标签
选中启用非托管代码调试复选框

代码文档应保持锁定状态，即使遇到断点也是如此，并且任何更改它的尝试都应触发一个弹出窗口，提示“启用非托管调试时不允许更改”。

【讨论】：

Laurent，这听起来很有希望......但是当针对'x86'编译时它对我不起作用。不幸的是，这种行为根本没有改变。我是否需要在某处添加一些“不安全”操作来强制发生这种锁定效果？
在“工具 > 选项 > 调试 > 常规”中，是否有“当一个进程中断时中断所有进程”。检查？我将尝试使用 Visual Studio 2008 进行一些测试并随时通知您。
嗨 Laurent，是的，选中“当一个进程中断时中断所有进程”。感谢您付出的努力。（事实上，为到目前为止的努力 +1，我真的很感激。）
这里是另一个线索：您可以通过在模块级别使用 DebuggableAttribute 启用/禁用程序集的“编辑并继续”行为。其属性 DebuggingFlags 允许指定是否可以使用“编辑并继续”。该标志由编译器在“调试”模式下自动添加。不知道它是否适合你...
嗨 Laurent，我感谢您的努力，但我已经可以全局打开或关闭“编辑并继续”，并且在针对 x86 CPU 编译时这不会锁定代码，所以我没有看看为任何给定的装配个体设置这个有什么帮助...... :-(

【解决方案2】：

这是我能想到的最好的。它有效，但您可能不想采取一些步骤。

本质上，该技术是在运行应用程序时将项目文件设置为只读，然后在应用程序结束时将它们设置回可写。

但是，在 VS2k8 中，默认情况下，将文件设置为只读仍然允许您编辑文件。您需要先在工具 > 选项 > 环境 > 文档中关闭“允许编辑只读文件...”设置。

其次，您需要将以下键作为 DWORD 添加到注册表中，并将其值设置为 1：

HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed

这仍然不会完全工作。然后您需要做的是将该项目的源代码控制设置为 Visual Source Safe。（

然后重启VS2k8。

此时，如果您将其中一个文件设置为只读，您将看到 Visual Studio 根本不允许您编辑此文件。当您尝试时，它会播放您计算机的异常音乐。

现在，要在运行应用程序时将文件设为只读，请设置构建后进程来执行此操作。这很容易。

更难的是，在您的应用程序完成运行后将它们设置回可写状态。最简单的解决方案可能是批处理文件快捷方式。

【讨论】：

+1 哇，令人印象深刻。我正在寻找更清洁、更容易的东西，但似乎确实需要某种 hack 或宏。如果没有人想出更简单的方法，我会给你打勾，但我会让这继续几天，看看是否有人可以做得更好。（顺便说一句，这在 VS 2010 中会更清洁或更容易吗？请不要投入任何工作来研究这个，但如果你知道的话。）
在源代码控制提供者背后搞乱只读位似乎是个坏主意。
“搞乱源代码控制提供者背后的只读位似乎是个坏主意”。这是一个很好的观点，乔什。使用 Visual Source Safe 的要求也绝对是一个问题。我想我将不得不违背我对“聪明人”的承诺，在这里打勾……我认为这个问题确实仍未解决。 :-( :-(
聪明人：有没有简单的方法可以暂时禁用VS2005或其他版本中选定文档和/或所有文档的代码编辑？有时，当我打算打开另一个窗口时，我最终不小心在我的代码中输入了一些东西。（思考）更好的是：有什么方法可以阻止文档“默认”或通过断点接收焦点，而不是通过故意的行为？

【解决方案3】：

您好 - 抱歉，我无法帮助您完全锁定您的代码 - 我有相反的愿望：在调试期间完全解锁它，但我可以帮助您解决第二个问题。

我建议您在发送任何密钥之前考虑检查活动窗口，如果活动窗口不是您的目标站点，请暂停执行测试，直到该窗口返回焦点。

我知道这不是您想要的解决方案，但防止其他类似问题可能不会有什么坏处。

祝你好运！

亚当

【讨论】：

+1 亚当的好主意。我一定会使用这个的一些版本。我不能给你这个复选标记 - 如你所知 - 但这是一个非常好的帮助。谢谢！（看起来我必须开始赏金以希望解决主要问题......我开始认为它不可能。）
我很想知道您是否设法使代码完全可编辑，以及如何实现。