Is there a way to *completely* disable Edit and Continue?

10
votes

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:

  1. 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.

  2. 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:

Thanks in advance for any help or ideas...

Mike

3
c#visual-studio-2008debuggingeditingedit-and-continue
Note that a unit test that talks to external software is called an integration test. – Lasse V. Karlsen
@Lasse: Ok, fair enough. I'll edit the above to say "automated tests", as I am running a suite of tests varying from isolated unit tests to integration tests. Thanks. It does not matter much here though -- it is SendKeys that is the problem, regardless of what kind of test you want to consider it. – Mike Rosenblum

3 Answers

5
votes

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):

  • Open the executable assembly's properties
  • Go to the Debug tab
  • Check the Enable unmanaged code debugging checkbox

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".

4
votes

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

3
votes

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:

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

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.