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.
I have a weird problem with Visual Studio Premium 2013. VS has taken to closing the Output window after my build starts. If the window is unpinned, it briefly opens at the start of the build, and then auto-hides. If it's pinned, it briefly gets selected, and then moves to another pinned window (it usually opens the Error List window and switches to that). The one thing it always makes sure of is that it switches away from the Output window. This is a behaviour that has started recently and I have no idea why - it didn't used to, and I don't remember changing anything related to this behaviour. Here's my settings, which should cause the Output window to stay open:
I've even tried deleting the solution's .suo file, but this problem persists.
Can anyone tell me how to get the Output window to stay open during a build again?
Well, I think this has something to do with the fact that the solution I'm building does a bunch of automated stuff, including the building of some .tt files. It's not a configuration issue in my Visual Studio because the Output window doesn't disappear when I'm building a new simple project I create from scratch, so I guess there's probably nothing I can do to stop the Output window disappearing for this project.
It just occurred to me, after years of closing these two windows after a debugging session, that there may be a way to turn them off. I generally have the output window open while debugging and only check the error list periodically for warnings, and can always get to them if I want them anyway. Hoping someone else may know of a way to stop the default behavior?
Visual Studio remembers the window layout for coding and debugging separately, so removing the output window while you are debugging will not affect the "coding" state - you need to close the output window before you debug or it will reappear when debugging finishes.
In Tools>Options, Projects and Solutions, there are options "Always show error list if build finishes with errors" and "Show output window when build starts" which cause the error/output windows to be shown automatically just before you start debugging. These could be the culprits for adding an error/output window that then reappears when you exit debugging mode.
I have the output window "dockable" and pinned open. When I want to see it I use ctrl+alt+O, and to get rid of it I click into it and shift-escape. The output window "magically" disappears whenever I dont want it, but if I pay close attention I can see that I'm hitting the hotkey automatically myself :-)
Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.
The red icon in vs.net changes color, and the debug mode just doesn't work.
what is the reason for this?
You may be running your project in Release mode. If so, then switch to Debug mode
From Visual studio debugging issue with files of the same name by Philip Carney
Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.
Stop debugging (press red square icon) in Visual Studio
Clean Solution
Build Solution
Tools > Attach to Process (or start with debugging)
Start the program that you're attaching to, and run it such that your code will get hit
If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit
If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint
for manage code only - theres a good answer for this problem on the following site:
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
for native + managed code - in the startup solution properties-> Debug tab
make sure that "enable unmanaged code debugging" check box is checked
After trying several suggested fixes for this I did the following to get it working.
Right Clicked my Project in the Solution Explorer and selected "Properties".
Went to the "Web" section and made sure "Start Action" was set to "Current Page".
Spent 3 1/2 hours on that... I'm going to go get a drink now.
I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form
Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.
This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.
This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.
What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.
I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.
I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.
To fix this I had to re-create the virtual directory. I'm using Asp.Net 4.7 Framework and IIS Express. Went to Web project > property page > Web tab > clicked the "Create Virtual Directory" button next to Project Url textbox.
I forgot I had clicked this button in my "Main" branch, but then had switched to my "Sprint" branch. It kept running the "Main" code until I clicked "Create Virtual Directory" on my "Sprint" branch.
For me it was giving this because I haven't started the relevant project at start of application , it worked after I added project run on start
My "Start debugging" button and element menu are greyed out... but only on one of my projects (an ASP.NET website). I have no idea what I have done to disable it.
I already checked everything in the Property page of both the solution and project. I even compared it to another project, but nothing seems to do the trick... maybe I missed an option ?
It sounds like your startup projects are all set to "start without debugging", since that would cause the button and element to grey out.
This can be fixed from Solution -> Set StartUp Projects.
Is it a startup project? You can only debug projects that can actually be started.
Right click on the project and click properties. Then click on Start Options (or something similar) to see the settings. If it's an executable project, you probably want to choose the option that will start the project output.
If you're able to start the project, you can usually attach the debugger using Ctrl+Alt+P (Or choose Attach to Process from the Debug-menu) and then choose the process from the list that comes up.
Do you have the COM+ Event System service running?