C# – way to *completely* disable Edit and Continue

cdebuggingedit-and-continueeditingvisual-studio-2008

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

Best Answer

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.