If I F5 to debug, and browse to my test site using Chrome, and execution halts before sending a response (e.g. we get an exception and I click Stop Debugging instead of continue to the end), that Chrome window and any child windows it spawns will no longer work with the project. It will say "Loading" with the spinner in the tab, the window will be empty, and it will stay like this apparently forever. Alternately, in a new tab, I type the URL and hit enter and it does not display any loading behaviour as though it isn’t even trying to load it. This persists across tabs within the same window hierarchy.
My workaround is to create incognito windows in Chrome when testing local sites. If it gets into this error state, then I have to close the window and open a new incognito session from the original browser parent. If I accidentally cause this problem in the main window, I have to fully close Chrome to proceed. Using different Chrome profiles also works as I assume it’s a different top level process.
Otherwise, it does seem to calm itself after quite a while – 5+ real life minutes or something similar it will revert and start working again and the page will load if it was still trying. But is there a better solution? This is VS 2022, debugging ASPX/C#, using a hosts file for local.site.com domains and separate http/https ports.
Edit: Image to show settings page
2
Answers
Well, if you hit a break-point in code behind, then code has haulted, and no more web pages can be dished out. (this is standard behavour when using the built-in web server that launches by hitting F5. if you close the web page, then the web server shuts down, debugging stop, and you back into Visual Studio.
You could try hitting ctrl-F5. That runs the VS site as non debug mode, and break-points etc. thus don’t usually get hit. But, f5 STARTS a copy of IIS express web server. You close that web page, then debugging stop, IIS is then shut down. This is correct behavior’s.
If you want to start testing the web site with say NOT having a debugger tied to the web site, then you probably are better off to install + run IIS full edition, and not the Express Edition that is "tied" to VS and the debugger.
So, the instant you close the browsesr, or even hit the "stop" button in VS, then IIS is shut down – it is stopped each time.
However, you could/can give ctrl-F5 a try – that will launch your site as non debug mode (and you not that no stop button is highlight).
IIS "express" is a great setup for f5, step code, debug code. However, the instant you want to start testing the site, and not having launched it from "inside" of VS? Then you probably should setup a VM with the full edition of IIS, or even I suppose install full edition of IIS on your computer (I not done that, since I have a few VM’s, and I don’t want to "mess up" my developer box with having a full pop full edition of IIS installed on my computer.
So, if you want "others" to test the site, then setup a VM with server 2019, or whatever, and then install IIS full edition. This THEN gives you the full GUI and setup features of a web server – which is a good learning experience.
So when using f5 to debug? yes, a halt in code will halt the ability of the web server to dish out other pages. In effect, IIS process one page at a time, and when the page life cycle is done, the the next page/request can be processed.
So, if you want "more" then this setup, then you probably need/want to get a full blown full edition of IIS up and running. And I suggest that should be placed on some other computer then your dev box, or at the very least in a VM on your dev box.
You "can" sort of get IIS Express edition to be launched and running outside of a VS debug session, but it is painfully, since you don’t have the GUI and all of the web configuration tools that the full edition of IIS has.
Your issue is rare, we need to troubleshoot step by step. First, please confirm that Tools==>Options==>Debugging==>General==>Enable Edit and Continue is enabled. Then you need to use detach all instead of stop debugging.