Related
Previously this could be done by unchecking "Enable Edit and Continue" under (Project) Properties | Web | Debuggers. This checkbox is not there in Visual Studio 2015 Update 2. The same checkbox including four sub-options can be found in Options | Debugging | General, but unchecking this no longer resolves the issue.
Same problem here.
My workaround for now is to add "Detach all" shortcut on the toolbar instead of the "stop" button.
The feature you're looking for is Start without debugging (menu: Debug -> Start Without Debugging or shortcut Ctrl+F5).
If you need to debug this process at any time you can use Attach to Process (menu: Debug -> Attach to Process... or shortcut CTRL+ALT+P). If you stop debugging on the attached process VS won't kill it.
PS. For me the bug you're referring to is a great enhancement (killing the debug process with stop debug command). Sometimes when issexpress hang (on SignalR for instance) and VS couldn't run a new debug session. It forced me to kill the process manually.
Not a fantastic answer, but a workaround.
Select your Web App in Solution Explorer, then press F4 to see the properties pane. In there, ensure 'Always Start When Debugging' is set to true.
If you have another IIS Express Web App in the same solution, do the same for that.
If you don't have another IIS Express Web App then create a minimal .Net web app without any code using the File New templates and set 'Always Start When Debugging' to true for that too.
Here is the trick, right click on the Web App project in Solution Explorer that you don't want to leave running (the one in step 2 or 3) and select 'Set as StartUp Project'.
Run your solution as usual, you'll get both of your Web Apps running. When you exit, it only detaches and halts the startup project which leaves your main app running.
Obviously a bug if they can leave the other Web App running. But at least this workaround will make debugging a little easier.
This bug have been Fixed in Update 3
Maybe this is not the answer to the OP question, but I use the "view in browser" option to achieve this.
In my VS2008, suddenly, I can use just letters, no enter, space, delete, backspace, or any other keys.
Any advice how to fix this?
Keyboard is working perfectly in other applications.
Thanks.
I was having this problem several times a day. Make sure the Language setting is set to "Same as Microsoft Windows" under Tools -> Options -> Environment.
ReSharper Options - Environment - General - Clear Caches solved problem.
Close the document that you are working on and reopen it. It works for me when my keyboard seems to be not functioning and i can't type into the current form.
For me the only thing that worked is this solution in this link => https://superuser.com/a/1626086/1055404
Just go to tools -> options -> Environment -> Keyboard and click on reset button on the top right corner
Try to remember line number (better ;) ), close the file you want to modify, then re open it.
It happening sometimes to me and that "hack" works perfectly.
It is realy strange behaviour, in my case even the restart of windows was not helpful. the trick was for me to open the project using "File" menu in VS and then open the .csproj not
.sln file.
Disabling Productivity Power Tools and restarting the IDE worked for me.
Should not that it was very shortly after installing Resharper that the problem occurred, having never experienced it before.
It happens to me when I'm close to run out of RAM. Closing processes (not VS) makes keyboard usable again.
I work under a Virtual Machine, On my case I had to close and open the VS again.
Have you been comparing changes before a push/commit? Check if you have any modal windows open. Had the same problem and when I tried to close VS17, it warned me, that I had a modal window that prevented some user inputs. I pressed "ok" to the window, restarted VS and I could again do inputs. I had the exact same error as you - could insert letters, but couldnt fx delete, "end", "home" etc.
I had the same issue with Visual Studio 2017. I was not able to remove code after typing. I just close the Visual Studio and run as administrator. Its working fine for me.
Set another keyword mapping scheme in the
Tools - Options - Environment - Keyboard
Look at your keyboard shortcuts and make sure there isn't anything set to any of the keys you're trying to use. This happened with me when I installed an extension and messed with some keyboard shortcuts and inadvertently set settings sync to 'c' no matter where it was input.
Close vertical or horizontal group.
Background: I have a Visual Studio 2008 solution containing three different web application projects. If I right click on the solution, choose "Set Startup Projects.." and then choose "Multiple Startup Projects", I am able to fire them all up at once when I hit F5 (Start Debugging).
Desired Behavior: What used to happen (until it unexpectedly stopped working) was that it would automatically open up three browser instances (IE by default) and run each of the web apps in each of the three browser windows.
Current (Undesired) Behavior: All of a sudden, instead of opening three browser windows, it now opens a single browser instance and sequentially starts them all up with the exact same window/tab, which means that I am left with only one app actually running. (Whatever the last app it was that got started.)
Any idea what could cause this? I've checked my project and browser settings (including the "Reuse windows when launching shortcuts" option) and can't seem to figure it out. Any ideas?
Update: I changed Visual Studio's default browser to Firefox, and it works as expected by opening up multiple browser windows. I guess I'll just use Firefox when debugging for now, which is probably a good thing anyway.
I don't know why it had stopped working but rather have a suggestion: Check 'Don't open a page. Wait for a request from an external application.' option under 'Start Options' page of your Web project property pages. It specifies that Visual Studio won't open the browser window automatically. It should start your project in a Web server and wait for another application to make a request.
This seems to be a bug/feature in newer instances of MSVS and/or IE.
It happens in Visual Studio 2013 and 2015 as well, and might not be a bug as such, but can certainly be an undesired behaviour.
To reproduce:
Select 2 web projects in multiple startup projects.
Set one to Startup and the other to Start without debugging.
Only one browser tab is used, but you will see the tab used briefly by each project before the next one is loaded.
The problem is that the last loaded project is not necessarily the project you want to have in the browser.
An other workaround is to simply set both projects to Start.
It turns out using Firefox did the trick for me. Since there are no other answers, I will just accept this one.
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.
In my Visual Studio instance, even if I just wrote a single line of return in a C# console application, it will take me a minute after pressing F5 to execute the actual code (I mean the time it takes to stop on the single return statement after pressing F5 -- I set a breakpoint on the return statement in the main function). What is wrong? Is there a check list?
I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.
You may need to delete all your breakpoints---note that you need to click the "Delete all breakpoints" button (or use Ctrl + Shift + F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?).
If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
I have seen this before. Try deleting all your breakpoints and then set the ones you want. Hit F5. Is it faster now?
I just noticed that you mentioned setting up the .NET source debugging feature. Try to disable that. Your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in menu Tools → Options → Debugging → Symbols.
Also try disabling "Enable property evaluation and other implicit function calls" in menu Tools → Options → Debugging → General.
Or remove your .suo file which can be found next to your solution (.sln) file.
This solved an issue I had with debug sessions taking a long time to start and stop.
I had this problem. After trying all the listed advice and removing all Visual Studio extensions, we finally figured out that somehow IntelliTrace was enabled. Disabling that fixed everything.
How to: Enable and Disable IntelliTrace
Do you have a lot of breakpoints set? Those can really slow down startup time. Everytime a new module is loaded into the process address space, they all need to be checked to see if they are valid.
Go to menu Tools → Options → Debugger → Symbols and check if you have public symbols set or UNC network paths set. Also check menu Tools* → Options → Debugger → General to see if you have source server set.
All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
My colleague had a very slowly responding Visual Studio, and it literally took minutes to perform a step while debugging.
The root cause turned out to be an anti virus program (Threatfire) that went crazy while Visual Studio was running. Killing its process immediately fixed everything.
In my case changing the debug symbol "Automatically load symbol for" option from "All modules" to "Only specified modules" solved the problem. You can change this option from menu Tools → Options → Debugging → Symbols.
A different cause plus... How to find the problem
To me it was the option ShowOtherThreadIpMarkers. A value of 1 makes Visual Studio (2010) unbearably slow (3-5 seconds for each debug step. With a value of 0, it is fast again.
What is it that option? I have no idea. I could not find it through the Visual Studio user interface.
I unchecked all possible debugging options in there and nothing worked.
So I went to Import/Export Settings and loaded my old settings I've previously saved going backward in time until Visual Studio was fast again, then compared the vssettings files..., etc., etc.
I'd like to remark that if you load the settings while you are in debug mode stopped on a breakpoint, they become effective immediately. You don't have to stop the debugger and restart.
From ScottGu's blog linked by Travis: "One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue."
Running under the debugger for me was roughly 10x slower than running without debugging.
After trying every solution suggested here, I went through every debugger setting and enabled/disabled to see if it made a difference.
For me, it turned out that disabling Suppress JIT optimization on module load in the debug settings massively improved things.
Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
Are you using a symbolsServer to download symbols for Windows DLL files?
If so, disable that as it can take some time, but I wouldn't expect that to cause long delays in a basic console application.
Menu Tools → Options → Debugging → Symbols.
I know this is an old topic, but for what it's worth...
I've found that if I've had a separate Internet Explorer window open for a long time it can take up to a minute to start debugging. Close all Internet Explorer windows and debugging starts immediately.
In my case Google Toolbar was slowing down my debugging.
gplus_notifications_gadget.html just kept going on and on overloading the debugger. I wanted to keep the Google Toolbar because I use it on a regular basis, so I just disabled the G+ notification button (the small button besides the profile button). It is happy now.
I had the same issue in Visual Studio 2010, with stepping in the code excruciatingly slow (between 3 to 10 seconds). However, none of the above settings modification did the trick.
I eventually found the ultimate solution, which would work in all of the above post issues: reset all your settings, as described here (essentially menu Tools → Import and Export Settings, Reset all settings, with saving existing settings to a file (for reverting)).
You may first want to save a particular part of your settings. For instance, I first saved my color theme (Solarized-like) and then restored it after the global reset.
For me, the setting that killed performance (Windows 8 even hanged except for mouse movement) was to uncheck "Break all processes when one process breaks" in menu Options → Debugging → General.
Just one more cause of a slow Visual Studio debugging experience...
Long time ago I enabled FusionLog to see what was causing an assembly binding problem.
Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.
This is the FusionLog key on Window's Registry (regedit.exe):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Change the ForceLog, LogImmersive and LogResourseBindings values from 1 (enabled) to 0 (disabled).
I had this problem too, but it had nothing to do with breakpoints in my case. It was code shortcuts that I added in the tasks window:
http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines
I'm sure there are other ways you could see a problem like this, but there is a bug somewhere that caused this problem for me...deleting all my options would have fixed this, but that is something that I did not want to do. So, I debugged it and wrote about it in my blog...your problem sounds like mine.
Something that has worked for me is to make sure there are no conditional break points. Other than that, I have had success fixing slow debugging by simply restarting Visual Studio and only opening one instance of Visual Studio at a time.
I had a similar issue and none of the other guidance seemed to help. I had rebooted to no avail. I had removed all breakpoints, deleted the .suo file, checked that symbols weren't being loaded from external sources, and checked that no paths existed in the application that was unavailable.
Then, I thought to clean the solution. I noticed in the output window that C# IntelliSense reported an issue when cleaning:
There was a problem reading metadata
from
'{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}'
('The system cannot find the file
specified.'). IntelliSense may not
work properly until the solution is
reloaded.
In this case, once you actually discover the error message, it tells you exactly how to resolve it. (Good job on the error text, poor job on discoverability!) I unloaded the solution's projects, then reloaded them. I was then able to successfully run clean solution. It worked, and the debugger did as well.
Closing the "Autos" window improved debugging for me in Visual Studio 2008 for a big native C++ solution.
Hiding it won't work. It needs to be closed.
I experienced the same slowdown and disconnecting from the network fixed the problem for me as some other comments and answers have stated (but of course that is not an ideal fix).
For my case this one simple change fixed my solution: In the project properties on the debug tab I disabled "Enable the Visual Studio hosting process" (I am running Visual Studio 2010).
Get more memory and a faster HD. More details are here.