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

Question

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 applicat

Answer 1

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.

Answer 2

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

Answer 3

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