I often find myself in a situation where I wish to break on several breakpoints in a run, but only for a while until I have seen enough on on those breakpoints and would like the Visual Studio to stop breaking on the breakpoints for the remainder of the current debug session.
I certainly do not want to delete all breakpoints because later I may change something in database or the code, and would like to perform a new, similar run to the one described above again.
I do not want to disable all breakpoints, since I want them to be activated again at the next debug run. At the same time I already have breakpoints, both active and disabled, in other parts of the code (which I am not currently interested in for instance) but I do not want to disable them and then try to remember later which I need for debugging a specific area/functionality of the code.
What I want is simply to be able to tell Visual Studio that "from now on as I resume execution, please ignore all breakpoints for the remainder of this debugging session. Thank you very much!"
So for the next debug run, all breakpoints should be hit again as they already were configured before as usual, but I mean at some point when I have seen enough I just want to continue execution without breaking. and without changing the status to "disabled" for all breakpoints - because doing so will make them stay disabled even at the next run, and I do not want to "Enable all" because I already had some breakpoints on my list which were disabled. And I certainly do not want to manually select/deselect breakpoints before every run just because I chose "Disable all" during a run.
Is this possible to and, in that case, how to do it?
Thanks!
I'm using VS2017 but hopefully the options are similar in VS2013:
Go to the Debug menu, then Windows > Breakpoints to open the Breakpoints window.
From here, the blue curvy arrows in the toolbar allow you to Export and Import breakpoints into an XML file.
So you could export all of your breakpoints, then delete them all. Later you can re-import them instead of having to set them all up again manually.
In VS2008 I could start the debugger (F5) and make changes then re-start the debugger without having to completely stop debugging and then restart. I cannot find the icon or the keyboard-equivalent shortcut for this action in VS2010.
Default is Ctrl+Shift+F5, however you can remap it in Tools - Options - Environment - Keyboard. Search for Debug.Restart command. The icon looks as following in the Debug toolbar:
.
This toolbar only appears when you are in debug mode. It is actually same in VS2008.
Are you referring to 'Edit And Continue' ?
To enable it:
On the Tools menu, click Options. In the Options dialog box, open the
Debugging node, and select the Edit and Continue category. To enable,
select the Enable Edit and Continue check box. To disable, clear the
check box.
Note that if you're using a 64 bit PC, you will have to explicitly set the platform target to x86 instead of Any CPU as Edit And Continue isn't available on 64 bit machines.
I allways do it with ctrl+shift+f5, I don't know if it's another way to do it
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.
Edit and Continue option is checked in Tools → Options → Debugging.
Optimization is not enabled.
Seems like there is no any managed profiler set up.
I am running in Debug mode
I am running on x64 CPU and Windows XP 32-bit, but setting platform target to x86 rather than AnyCpu doesn't help.
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.
Other Applicable Solutions:
Below is an incomplete, unordered list of possible solutions to try if you* are trying to fix Edit & Continue quickly.
Make sure you are in Debug Mode
Make sure you're not launching a mixed mode process
Try to set the CPU target to x86 rather than AnyCPU (on x64 machines)
Uncheck the Optimize Code checkbox for Debug Mode in Project Properties->Debug
Uncheck the Optimize Code checkbox in Project Properties->Build
Uncheck Enable Optimizations in Advanced Compiler Settings
(ASP.NET) Check nightcoder's answer if it is the case
(ASP.NET) Check this answer (by matrixugly) if it is the case
(ASP.NET) Ensure you have Edit and Continue enabled on the Web tab (vs2010)
(ASP.NET) Go to Properties > Web > Servers, and make sure that Enable and continue is checked under Use Visual Studio Development Server.
(ASP.NET WebAPI) Make sure you've stopped in the Controller's method using a breakpoint, before trying to edit it.
(vs2017) Go to Tools > Options > Debugging and uncheck (deselect) 'Edit and Continue'. This is actually the opposite of the 'conventional' advice (see some other points in this post). It does not allow you to actually make changes in your running program (i.e. it does not hot-swap the code changes that you make) - it simply allows you to edit your code (i.e. it prevents that annoying message and "locking" your editor).
Go to Tools > Options > Debugging > General and make sure Require source files to exactly match the original version is unchecked.
Check Enable Windows debug heap allocator (Native only) [VS Community 2017]
Are you using Microsoft Fakes? It inhibits Edit & Continue.
Kill all the *.vshost.exe instances by selecting End Process Tree in the Task Manager. VS will regenerate a correct instance.
Remove all the breakpoints with Debug->Delete All Breakpoints
Enable and Continue exists in both the Tools > Options > Debugging menu and also in the Project Settings. Be sure to check both places. edit & Continue is not supported with the extended Intellitrace setting.
Be sure Debug Info in Project Properties > Build > Advanced > Output > Debug Info is set to Full
Some plugin may be interfering. Check by disabling/uninstalling and then trying again the other solutions.
If you're not paying enough attention, the error you get while trying to fix this may change to something else that is easier to diagnose. E.g. A method containing a lambda expression cannot support edit and continue.
Make sure the System variable COR_ENABLE_PROFILING is not set to 1. Some profilers set this when installing and leave it like that after uninstalling. Open a command prompt and type set to quickly check it your system is affected, if so remove the variable or set it to 0:
In Windows 8 and above, search for System (Control Panel).
Click the Advanced system settings link.
Click Environment Variables.
Remove COR_ENABLE_PROFILING
Be aware of unsupported scenarios (as reported in the question) and that unsupported edits.
* by 'you', I mean the visitor of the page who is hammering his head on a keyboard to find The solution.
Feel free to edit this answer to add your workaround if not listed here!
If you're debugging an ASP.NET application, go to properties > web > Servers, and make sure that "enable and continue" is checked under Use Visual Studio Development Server.
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.
I had the same problem. I even re-installed VS 2008 but the problem did not go away. However, when I deleted all the break points then it started to work.
Debug->Delete All Breakpoints
I think it was happening because I had deleted an aspx page that had break points in its code, and then I created another page with the same name. This probably confused the VS 2008.
"Edit and Continue", when enabled, will only allow you to edit code when it is in break-mode: e.g. by having the execution paused by an exception or by hitting a breakpoint.
This implies you can't edit the code when the execution isn't paused! When it comes to debugging (ASP.NET) web projects, this is very unintuitive, as you would often want to make changes between requests. At this time, the code your (probably) debugging isn't running, but it isn't paused either!
To solve this, you can click "Break all" (or press Ctrl+Alt+Break). Alternatively, set a breakpoint somewhere (e.g. in your Page_Load event), then reload the page so the execution pauses when it hits the breakpoint, and now you can edit code. Even code in .cs files.
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.
For me, for a reason that I don't understand, the setting "Generate debug info" in the "Advanced Compiler Settings" was set to "pdb-only" instead of "Full".
By default, this parameter is always set to "Full" but a mysterious poltergeist has changed this parameter on last night. :)
P.S. I'm in Visual Basic .Net with Visual Studio 2010
If your concern is with an ASP.NET app, ensure you have edit and continue enabled on the web tab (vs2010). There was also a separate setting for ASP.NET debugging in earlier versions.
Regards,
Adam.
I found that even though under project properties build & debug tab are set to Debug and all the other setting are correct I still get the message, however after digging some more
under the Build menu select Configurations Manager... and make sure Debug is selected in two places there as well. go figure...how many different places do they need to set debug?????? even though you set Project - Configuration to Debug then under Build - Manager it is not changed so you have change the same setting there as well Project Configuration - seems like a microsoft issue again.......
This problem is due to Intellitrace setting
If Intellitrace is enabled make sure Intellitrace event only is checked
Otherwise this will not allow edit and continue..
If you will click on Intellitrace options you will see the warnings.
Following shooting helped me using VS2010:
go to Tools, Options, Debugging, General and make sure "Require source files to exactly match the original version" is unchecked.
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.
I had this problem in Microsoft Visual Studio 2008 and the solution is easy. when you run your project please set in "Debug" mode not "Release". The another people solution can be useful.
If I create a new project, edits while debugging do not work. If I create a new website, edits while debugging work as expected.
I ran into this today - turns out that having Debug Info set to pdb-only (or none, I'd imagine) will prevent Edit and Continue from working.
Make sure your Debug Info is set to "full" first!
Project Properties > Build > Advanced > Output > Debug Info
In my case just reseting to default debugger settings and setting IntelliTrace-> only intellytrace events helps
Some things that seemed to help using VS2010:
go to Tools, Options, Debugging, General and make sure "Require source files to exactly match the original version" is unchecked.
multiple .vshost.exe instances can be left over from e.g. detaching the VS debugger from a stopped process. This will interfere with breakpoints and compiles as well. Use Task Manager, Processes tab to kill all instances of .vshost.exe by right-clicking each instance and selecting End Process Tree. VS will create a new instance.
I removed a dataset from my project because I didn't use it. After that I could modify the program when debugging.
I did all the changes mentioned in every other answer and none worked. What did I learn? Enable and Continue exists in both the Tools > Options > Debugging menu and also in the Project settings. After I checked both, Enable and Continue worked for me.
Seems illogic, but only way was disabling edit and continue from VS 2017 options... Then AspNet edit and continue began to work...
what worked for me was unchecking "Use Managed Compatibility Mode" under
Tools -> Options -> Debugging
TBN: checking or unchecking "Require source file to exactly match the original version" seems not influences the E&C
Hope this can help.
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:
Stop running your app.
Go to Tools > Options > Debugging > Edit and Continue
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
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.
embed interop types visual studio should be set to false
I had this happen in a linked class file. The rest of the project allowed E&C, but I got the same error editing the linked file. Solution was to break linked file into it's own project and reference the project.
I faced the same problem. My problem was that I could modify a file, but not another (both are in same project). Later I found that the file I couldn't modify was also part of another project. That another project (Unit Test) wasn't loaded, and intelligent VS debugger shows the error that assembly for this given file was not loaded, and changes aren't allowed. How weird!
Hence, I had to unload the unit-test project and continue the EnC debugging.
On one of my two computers I see following behaviour:
Each time I press F10 (Step over) or F11 (Step Into) in the disassembler window, the focus is switched to the source view, resulting in next F10 / F11 done on the source level unless I switch focus back.
Can anyone recommend me what settings to inspect, or what to try to stay in the disassembler view?
Did you try to reset settings on your VS?
from the Visual Studio command prompt window type devenv /ResetSettings
Look in the Tools > Options > Environment > Keyboard section, and check what F10/F11 are currently assigned to (although I can't believe it's something that simple)
Copying the settings from the working computer might solve it. You don't mention what version you're running, but I think they're in the same location in 2005 onwards : My Documents\Visual Studio 2005\Settings\CurrentSettings.vssettings. There's always the Import and Export Settings Wizard too.
Try setting a breakpoint in the assembly view. I'm assuming the existing breakpoints are in the source view.
Could it perhaps be: Tools->Options->Debugging->Enable address-level debugging?
I just tried in VS05, and when I have that unchecked, I can't even bring up the disassembly view, but I would guess that if you somehow got into disassembly view, having that option off would kick you out of disassembly view when you did a step over/into.
Close the source file window ? I had the inverse problem that cause F11 to always debug in assembly, it was fixed by closing the assembly window. May be it works in reverse too ?
Not sure, if this would work but... try if you can?
Open RegEdit
Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a DWORD under this key called TabProcGrowth
Set TabProcGrowth to 0 (zero)
This is what I used when VS2005 debug mode stopped working (0:
Try removing any .pdb files from the directory you are executing from. Also make sure your Options->Debugging->Symbols settings aren't pointing to any pdbs for the files in question.
Of course I'm assuming you've been through all the other Options->Debugging options, including the native section.