IIS Express Immediately shutting-down running site after stopping web application

I'm using visual studio 2012 in the first days when I want to stop application in IDE, application was still running on IIS Express, I could browse and work with running application, but now I can't. IIS Immediately shutting-down application if I press stop button. Since I remember I didn't make any changes in setting. How should I do that running same as first days.

I recently faced a similar situation when suddenly my IIS Express stopped right after I stopped debugging. This happened after I turned on "Enable Edit and Continue". So if you disable this you will see that IIS Express stays running even after debugging is stopped.

Right click your project > click Properties > select the 'Web' tab on the left > uncheck the Enable Edit and Continue checkbox.

In VS2010 and VS2012, the edit and continue option is disabled by default when creating a new web application project. In VS2013 it is turned on by default.

You can find this option on the Web tab in the web project’s properties window.

With “Enable Edit and Continue” on, the VS debugger starts your web application in IIS Express. When you stop debugging, IIS Express is closed too. With this behavior, you will see the IIS Express system tray shows up during debugging and gone after debugging. This behavior is the same as in VS2012 when the Enable Edit and Continue option is turned on.

If you don’t need "Edit and Continue" functionality during development and would like IIS Express to stay after a debugging session, you can simply turn the Enable Edit and Continue option off.

If you want to use "Edit and Continue" or you are developing an Asp.net 5 site (ASP.NET 5 projects don't have an Edit and Continue checkbox in project properties) you have to use the "Detech all" command to stop debugging.

The debugger will detach from the iis process without closing it.

Clearly "Edit and Continue" feature will not work until you start debugging again.

Instead of hitting the (X) STOP button, you can use the Detach all menu item in the Debug menu. The major difference is that the stop button will terminate any process that is currently being debugged, while Detach All will disconnect the debugger from the processes, but will not terminate them.

The normal IIS worker process would also be terminated, but since it used to be running as a service, it will also automatically start up again and thus you could continue to use it without having to restart the process through |> Debug or |> Start without debugging.

Screenshot for Reference

It seems like since the release of Visual Studio 2015 Update 2 the accepted solution no longer works.

The easiest solution I've found so far is to start the project by selecting "Start Without Debugging" from the Debug menu.

This is probably best categorized as another workaround, but it works for me.

I generally start the project for the first time with the "View in Browser" context menu (or CTRL-Shift-W).

From then on, anything that requires debugging, I usually attach to the new existing iisexpress process. While mousing thru context menues would make this a non-starter, it is nearly as quick as F5 with the following keystrokes:

• Shift-F6 to build the current project or Ctrl-Shift-B to build the entire solution (this is only required if you have made changes but I thought I should mention it since F5 already does this).

• Ctrl-Alt-P opens the attach to process dialog

• typing "iis" will then bring you down to the iisexpress process

• hit enter and you're attached

If you have more than one iisexpress running, the last one started will generally appear at the top of the list. Another option is to shift-select and attach to all of them.

This has a number of advantages IMO. First and foremost, it doesn't terminate the process. Second, the browser window isn't closed when you stop debugging. It cracks me up when I see a developer repeat 7 steps to get to reproducing a bug, when all he needs to do is hit F5 in an existing browser window to just repost once the debugger is connected. Last, I have to do this already when attaching to nunit, so I get a more consistent experience.