有没有办法“完全”禁用“编辑并继续”？
我想知道是否有一种方法可以在 Visual Studio 2008 中调试代码时完全锁定我的代码。当作为 64 位应用程序运行时，代码文档会自动锁定，这是我非常喜欢的；然而，我的大部分编码工作都是为 Excel 制作加载项，它是 32 位的。结果是，即使我的目标是“AnyCPU”，VS 主机也知道它正在 32 位进程中运行，因此，当代码在 Visual 中托管时，源代码不会被锁定工作室。
我可以通过转到“工具”>“编辑并继续”来关闭“编辑并继续”。选项>调试>编辑并继续，然后取消选中“启用编辑并继续”复选框。然而，这并没有完全锁定代码。这确实会阻止在当前运行中执行代码中的任何编辑，但不会阻止鼠标单击或击键实际更改代码。
同样，当使用 64 位应用程序时，这种情况不会发生——代码被完全锁定。我非常喜欢完全锁定代码，至少有几个原因：
我在调试时可能会意外地按下某个键等，这是我绝对不想做的。这种情况很少见，但这是一个问题。
我的许多自动化测试都是通过 SendKeys 驱动用户界面。然而，当使用调试器单步执行此类测试时，我有时会忘记某些方面涉及 SendKeys，这意味着击键最终会发送到 Visual Studio IDE 而不是 Excel。
在上面的问题 #2 中，单元测试失败了，这很好——我的坏处——但是将所有击键发送到代码模块并破坏我的代码是完全不可接受的。
这里有人有什么想法吗？在 Visual Studio 中运行并针对 32 位 CPU 进行编译时，可以完全锁定代码吗？
有关此问题的一些相关帖子，但没有一个直接解决此问题：
- 如何：启用和禁用编辑并继续
- 在 Visual Studio 2008 中调试时“不允许更改 64 位应用程序”
- 如何在 Visual Studio 的调试模式下启用文件编辑？
- “编辑并继续”在 Visual Studio 中如何工作？
- 我们可以在运行应用程序时编辑代码
- 在调试时编辑 C#
预先感谢您的任何帮助或想法...
Mike
I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
- How to: Enable and Disable Edit and Continue
- “Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
- How do I enable file editing in Visual Studio’s debug mode?
- How does “Edit and continue” work in Visual Studio?
- Can we edit our code while running the application
- Editing C# while debugging
Thanks in advance for any help or ideas...
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是我在 Visual Studio 2005 下使用的一个技巧（没有机会在 Visual Studio 2008 下测试，但它应该可以工作）：
即使遇到断点，代码文档也应保持锁定状态，并且任何更改代码文档的尝试都应触发一个弹出窗口，显示“启用非托管调试时不允许更改” 。
Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".
嘿那里 - 抱歉，我无法帮助您完全锁定您的代码 - 我有相反的愿望：在调试期间完全解锁它，但我可以帮助您解决第二个问题。
我建议您考虑在发送任何键之前检查活动窗口，如果活动窗口不是您的目标站点，请暂停测试的执行，直到焦点返回到该窗口。
我知道这不是您想要的解决方案，但防止其他类似问题可能不会有什么坏处。
祝你好运！
亚当
Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam
这是我能想到的最好的。它有效，但有些步骤您可能不想执行。
本质上，该技术是在运行应用程序时将项目文件设置为只读，然后在应用程序结束后将它们设置回可写。
然而，在 VS2k8 中，默认情况下，将文件设置为只读仍然允许您编辑该文件。您需要首先关闭“工具”>“允许编辑只读文件...”设置。选项>环境>文件。
其次，您需要将以下项作为 DWORD 添加到注册表中，并将其值设置为 1：
这仍然无法完全工作。然后您需要做的就是将该项目的源代码管理设置为 Visual Source Safe。 （<-- 这是我假设您不喜欢的步骤。）
然后重新启动 VS2k8。
此时，如果您将其中一个文件设置为只读，您将看到 Visual Studio 根本不允许您编辑该文件。当您尝试时，它会播放计算机的异常音乐。
现在，要在运行应用程序时使文件只读，请设置构建后流程来执行此操作。这很容易。
更难的是，一旦您的应用程序完成运行，将它们设置回可写状态。最简单的解决方案可能是批处理文件快捷方式。
Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.