I have a very odd problem with Chrome and FF browsers, when I'm using them while developing asp.net applications in VS 2013 / 2015, with IIS Express
Precisely, after few debug sessions (edit / run), the browsers no longer load the page (the site). The page keeps trying to load, the spin indicator is keep loading, if I monitor in VS in Output I see the app seems to work (I see regula messages, like
'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/2/ROOT-1-131087453511178120): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\70993733\b377d6be\App_Web_tzrs4sq3.dll'
but the page never loads.
Even if I totally restart the browser and all its instances (from task manager), exit VS, kill IIS Express, nothing gets solved.
If for example this starts to happen in Chrome, and I try to load the same page in FF, it works. But after few more debug sessions (edit / run), FF starts behaving the same.
This happens erratically (sometimes I can debug a full day, tens of session, without problem), and sometime it happens just after 2-3 sessions.
Any other page (form internet) loaded in that browser still works just fine. Somehow it seems the browser cannot get back data from local IIS Express.
The only solution I found so far was to restart PC - after that, the debug session works, but also, till some moment.
I cannot tell if this happens in IE or Edge also, because it never happen to me with them, but I'm using them rarely (because I'm more accustomed with Chrome and FF's web developer tools - source, console, etc).
Did anyone encountered this behavior?
Any solution, or advice?
Correction:
Only Chrome still fails to load page even after restart and closing all instances in Task Manager.
FF (at least in latest version) seems to recover after a close / kill in Task Manager
Thank you
Related
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
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.
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.
I have a very strange problem I'm fighting with since VS 2015 (maybe even 2013).
Now I'm working with VS 2017 and it still occurs.
Here is the situation.
I have a legacy web application (Webforms, later enhanced by integrating webapi REST with javascript/html client code, some WCF endpoints, etc).
I build and start debug session from within VS (I do debug/testing mostly with Chrome and FF, rarely with IE/Edge/etc.), and I use IIS Express.
Most of the time the application debug session starts just fine - the page loads in browser and I can either debug server side in VS / client side in browser's debug tools.
But sometimes, the page actually never completes loading, and no matter how long I wait, it just stays locked on "loading..." message.
The only solutions I found are:
- either restart PC
- or (in Chrome), start browser in new identity.
- switch to a different browser (e.g. after starting with Chrome, open page in FF - or vice-versa).
When the page loads normally, the VS's Output Debug window displays various tracing / debug messages or progress of loading various dlls.
However, as soon as the problem described above starts to happen, the VS Output Debug starts to log msgs like
The thread <#nnnn> has exited with code 0 (0x0).
When this starts to happen, no matter what I do (except starting browser in new identity / change browser / restarting PC) I can no longer debug.
No matter if I totally close and restart the browser, clear cache, close and restart VS / IIS. Nothing helps.
The situation mentioned above occurs at very random intervals.
Sometimes I can work and debug for days (I suspend / hibernate the PC at the end of the day, resume next days, end everything works ok).
However other times the issue occur after just starting few debug sessions, and on occasions, even after a full shutdown / restart, at very first debug session, this happens.
I have lived with it for long time, but sometimes is very annoying.
Anyone have experienced a similar issue?
Any idea what is causing it, and is there is any fix / workaround?
Thank you
The messages in your output log reporting:
The thread <#nnnn> has exited with code 0 (0x0)
Just indicates that the thread has exited safely and is very normal to see this in correctly working code. In fact it would be abnormal to not see this as you will end up using all available threads.
From what you have explained I would suggest that you need to look at the extensions you have installed in your browsers. I typically will use a vanilla profile (blank profile with no modifications / extensions) so that my debugging is not affected by any modifications the extensions can make.
I would also monitor your system's CPU and memory usage. Are either of these being maxed out?
I have a fairly standard web application with a single HELLO WORLD aspx test page, so for the purposes of this question, that is the start page.
When I run the app from visual studio by pressing f5 I get "Cannot reach this page" or whatever the 404 equivalent is in each browser. (chrome: "this site can't be reached"). In firefox, the page runs successfully first time, firefox doesn't have any debugger attachment add ins, so the problem seems to relate to debugger attachment in IIS express
If I wait a few seconds, and then F5 the browser (IE or chrome), the expected page loads successfully, so it seems to be a delay in IIS starting when a debugger is attached.
I'm wondering if anyone else has hit this and whether they have a solution. We have a quite a few tweaks in web.config to meet high security needs but otherwise I can't think why it would go wrong.
Workaround is to wait a few seconds and press f5, but thats kind of annoying when you're trying to get on with things.
As described by O.H., and verified by user2728841, the solution for me was:
Tools > Options > Debugging and changing "Enable JavaScript debugging for ASP.NET".
However, opposite to O.H. and like user2728841, my option was deselected, and selecting it solved the problem.
Intermittently, my team's (overweight) VS2010 solution fails to load in the debugger. We get informed that "The web server did not respond in a timely manner".
Workarounds for when this happens:
Build, then debug (but not hitting F5 before building)
IIS Reset
Killing other apps, or closing extra open tabs in my other browser (debugging in IE, browsing stuff/keeping Gmail open in Opera)
Is there a registry key we could set that would make the response timeout longer, or similar?
I've found the hint of an answer here:
There are registry keys that control timeouts for VS's debugger. As these are generally not documented, it's a matter of trial and error from here.
So far I've been toying with HKCU\Software\Microsoft\VisualStudio\(version number)\Debugger\ScriptDocsTimeout
I am running VS 2008 SP1 on a pretty high-powered Win XP machine. My startup project is a web project that was written by another developer (I'm not that well versed in web development). Start Options = launch specific page, Server = default Web server, debuggers = ASP.NET.
When I push F5, my browser opens a new tab in Firefox (my default browser) - but then it takes over 3 minutes for the web page to appear! I tried "step into" instead of F5, and the first executable line of code is only hit after that same 3 minutes.
Other developers do not have this problem. There is clearly something wrong with my configuration, but I haven't the faintest idea where to start looking.
Your suggestions are most appreciated!
There were issues reported with FireFox and the VS built-in development server. It has something to do with IPv6 issue.
With me it's similar: IE/Opera do it quickly, FireFox/Safari terribly slow.
You should be able to fix it the following way:
In your FF type in the "about:config" address. Then find the setting "network.dns.disableIPv6" and set it to true. Now it should become fast.