Edit and Continue: "Changes are not allowed when..."

Viewed 128416

Even if I create a clean WinForms project, Edit and Continue doesn't work and gives me the error:

Changes are not allowed when the debugger has been attached to an already running process or the code being debugged was optimized at build or run time.

  1. Edit and Continue option is checked in Tools → Options → Debugging.
  2. Optimization is not enabled.
  3. Seems like there is no any managed profiler set up.
  4. I am running in Debug mode
  5. I am running on x64 CPU and Windows XP 32-bit, but setting platform target to x86 rather than AnyCpu doesn't help.
  6. Repairing Visual Studio installation doesn't help.

I also found this article on MSDN website:

Unsupported Scenarios

Edit and Continue is not available in the following debugging scenarios:

  • Debugging on Windows 98.

  • Mixed-mode (native/managed) debugging.

  • SQL debugging.

  • Debugging a Dr. Watson dump.

  • Editing code after an unhandled exception, when the "Unwind the call stack on unhandled exceptions" option is not selected.

  • Debugging an embedded runtime application.

  • Debugging an application with Attach to rather than running the application with Start from the Debug menu.

  • Debugging optimized code.

  • Debugging managed code when the target is a 64-bit application. If you want to use Edit and Continue, you must set the target to x86. (Project Properties, Compile tab, Advanced Compiler setting.).

  • Debugging an old version of your code after a new version failed to build due to build errors.

But I can answer "No" to every item in this list.

It worked before, but several days ago it stopped working, and I don't know what could be the reason.

37 Answers

I finally got to solve the problem: UNINSTALL Gallio

Gallio seems to have quite some many rough edges and it's better to not use MbUnit 3.0 but use the MbUnit 2.0 framework but use the gallio runner, that you are running without installing from the installer (which also installed a visual studio plugin).

Incidentally, I had the issue even after "disabling" he Gallio plugin. Only the uninstall solved the problem.

PS. Edited by nightcoder:
In my case disabling TypeMock Isolator (mocking framework) finally helped! Edit & Continue now works!!!

Here is the answer from TypeMock support:

After looking further into the edit and continue issue, and conversing about it with Microsoft, we reached the conclusion it cannot be resolved for Isolator. Isolator implements a CLR profiler, and according to our research, once a CLR profiler is enabled and attached, edit and continue is automatically disabled. I'm sorry to say this is no longer considered a bug, but rather a limitation of Isolator.

Couple of things to check

  • Make sure your compile is set to Debug vs. Release
  • Make sure you're not launching a mixed mode process
  • If on a 64 bit machine Make sure to set the CPU target to x86 rather than AnyCPU

EDIT

I don't believe this should matter but make sure that the hosting process is enabled for the target platform. Probably won't help.

If it repros for new projects then it might be something even more subtle. I would try the following.

  • Backup HKCU:\Software\Wow6432Node\VisualStudio\9.0 (maybe just rename it)
  • Delete the same key
  • Try the repro again

None of the above solutions worked for me(running on a 64x machine).

Finally I clicked on 'advanced compiler settings' and UNCHECKED 'enable optimizations' and I can now step through code and edit while debugging.

That happens when the debugger hasn't hit a breakpoint or you haven't hit Break All (pause). It couldn't be that simple could it?

The error says a possible cause is: "the code being debugged was optimized at build or run time". Go to Project Properties->Debug and uncheck the Optimize Code box for Debug mode.

In my case just reseting to default debugger settings and setting IntelliTrace-> only intellytrace events helps

Enable edit and Continue only work run IIS Express. Don't work in Local ISS or External Host.

I'm adding my answer because the thing that solved it for me isn't clearly mentioned yet. Actually what helped me was this article:

http://www.rubencanton.com/blog/2012/02/how-to-fix-error-changes-are-not-allowed-while-code-is-running-in-net.html

and here is a short description of the solution:

  1. Stop running your app.
  2. Go to Tools > Options > Debugging > Edit and Continue
  3. Disable “Enable Edit and Continue”

Note how counter-intuitive this is: I had to disable (uncheck) "Enable Edit and Continue".

This will then allow you to change code in your editor without getting that message "Changes are not allowed while code is running".

Note however that the code changes you make will NOT be reflected in your running program - for that you need to stop and restart your program (off the top of my head I think that template/ASPX changes do get reflected, but not VB/C# changes, i.e. "code behind" code).

I install the stackify, when i enable this on icon tray, it stop my debugging with edit, so i found

  • Close the visual studio , in my case its vs2017
  • Go to icon tray and right click on stackify icon and disable .NET Profiler
  • Open Visual studio run application again in debug mode with debugger and it allow me edit while debugging

see image

I had this annoying issue since I upgraded my VS 2019 to 16.4.3 and caused me a lot of headache.
Finally I solved the problem this way:

1. Stop Debugging
2. Select the solution from "Solution Explorer"
3. In the Properties window change the "Active config" Property From "Release|Any CPU" To "Debug|Any CPU"
4. In Debug > Options > General Check the Edit and Continue checkbox

That worked for me, and hope it works for you too.

I had a database project in the solution which stopped the webforms project from being editted.

I clicked "Unload" on the database project and everything now works sweetly.

I was facing the same problem in Visual Studio 2005. My configuration is 64 bits. It was working fine on one of the VS solution but not the other. I noticed i only enabled "Enable edit and continue" for the project where i wanted to make changes in debug mode. This finally solved for me when I selected "Enable and Continue" for my start up project as well.

There was no configuration changes except the enable and continue needed.

For me, it was happening after I had hit a breakpoint, had done some edits, then continued on stepping through the code, then finally hit F5 or "Continue" to get to the end and out of my code block.

After trying the "delete all breakpoints" option (Ctrl+Shift+PrtScn and OK on the prompt) and doing a Rebuild All, I still had an error in my Error Log with regard to my DLL for my project not loading... "Can't apply changes, x.DLL not loaded". After restarting Visual Studio, all was fine again. For me, it turned out to be just this simple.

Other things here did not work for me, like "Require source files to exactly match the original version" was checked before and after things started working again just fine, and targeting "Any CPU" on my x64 machine is just fine, too (did not need to specify x86 or x64). I had "Enable Edit and Continue" enabled in my Tools > Options > Debugging and in my Project Properties > "Web" tab settings.

Had this problem in Rider. I had opened the .csproj file directly instead of the .sln file. The consequence is that the runtime configuration was not set to debug even though I clicked the debug button. You'll notice it says <No Configurations> in the toolbar beside the debug button.

VS2019 - ASP.NET Forms In my case was Tools - Options - Windows Forms Designer - "Optimized Code Generation" <- to false

Edit and Continue has not worked for these 2 particular projects since VS2013 so I have kept it around for those. A fresh attempt to get it working on VS2022 finally yielded a cause:

On Error

If you edit code within an On Error you get the "edits were made which cannot be compiled" error. Setting the Error list Show Options to Build + Intellisense you finally see the error "Updating a On Error statement around an active statement requires restarting the application" which is what is blocking continuing execution.

Sad, as I have intentionally kept this legacy error handling method for these two particular projects for a very specific reason and needing to go to structured error handling is a major productivity setback.

But now I need to use some more modern libraries which are no longer compatible with VS2013 so I am forced to move on.

Related