I have my web app hosted on my local machine, and I try to debug it. I always use Attach to process to do this. BUT. Sometimes when I reach breakpoint and press F10 debugger just continue to run app as I press F5, so I can't go to next step. And sometimes I reattach to process and it runs ok, but not too long, some time pass it again do such strange things.
Can you explain why does it happens?
Regards, Dmitry.
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.
It stops responding after a few seconds of being idle. I have to restart it every time this happens.
I have tried putting startMode="AlwaysRunning" into my applicationHost config, but nothing changed.
The output of the console is just a bunch of
The thread X has exited with code 0 (0x0).
I don't think this is related to idleTimeOut either, because the website completely stops responding; it just hangs.
applicationHost if anyone is interested (too large to post here):
http://pastebin.com/quVMXPHP
Let me know if you need further information.
Are you sure it's from being idle? By default, every time you stop debugging, IIS Express unloads the website, and quits entirely if there's no other websites running. You can disable this by unchecking Enable Edit and Continue in the project properties under the "Web" tab.
If it happens more randomly, then IIS Express may actually be crashing. Check in the notification area of the taskbar for IIS Express, make sure it's there, and (by right-clicking) ensure your web project is still loaded (in the list). If it's actually crashing, you most likely have a memory leak, infinite loop, or something similar going on somewhere in your application that's overloading the process. There's no much we can do to help you with that, without being able to examine your entire codebase. You'll just have to trace and profile until you find it.
I am running/debugging an asp.net mvc3 application from within Visual Studio 2010.
Anything static in nature is not called when I re-run the app from within Visual Studio.
(or even something simple like Application_Start())
Each time I want to run the webapp 'properly' I need to kill WebDev.WebServer40.EXE in the task manager before anything static is called again.
q1) Is this normal, and if Yes, why?
q2) If no, then I would expect the ASP.NET Development Server to be restarted each time I restart a debugging session. How can I turn this on?
UPDATE:
Recompiling sometimes causes Application_Start to be called, not always.
I've resorted to calling a batch file in the prebuild, eg
kill_WebServer40.bat
which contains
taskkill /F /IM WebDev.WebServer40.EXE
exit 0
If you embed those two commands directly into the pre-build textarea your compilation will fail if the WebServer isnt running already. This linked helped fix that.
Surprised this wasn't discussed more/previously - when developing an app, as if you have any static data/caches and you want to run the application 'clean' you would run into this issue.
Yes it's normal. It will restart if you touch the web.config or recompile. The development server continues to run the application in the background after you stop debugging.
You can stop the development server in the task tray by right clicking on the icon and choosing stop.
There isn't a way to force a application restart every time you hit debug. This would only be needed for the edge case where you are debugging application start up. Just hit rebuild before debugging and it will have the desired affect.
Using VS2008 on my local dev machine, when I run my asp.net Web Application project, it starts up a session of Asp.Net Development Server when I use F5 to run the app in debug mode. It all works fine and I can run my app for testing and such. Then, when I stop the running debugging instance of my app (by closing the IE window with the X close button, or by clicking the square Stop Debugging button in the VS IDE), the app stops and I return to the VS IDE, but it also closes down the Development Server session, and then, after I make a few edits to my code and want to run it again, it takes forever to launch up the Development Server again and serve up the first page of my very simple app.
Is it normal for the session of Asp.Net Development Server to completely shut down like this each time?
I only have 1 project in my solution, and it uses ADO.NET Typed DataSets and OLEDB adapters, and basic asp: controls in the aspx web form. Overall, it is a very small app.
I hate waiting 20-30 seconds each time I want to run my app just to see one tiny little code change.
I was also facing same problem, but in my case "Edit And Continue" setting was a culprit. Thanks for posting this.
If you don't need to debug every time, you can actually just open the URL outside of pressing F5 (press F5 once, copy the url, stop debugging, open it in a new browser). This way you can make any changes you want, recompile, and see it immediately. But as I said, it means you're not debugging. You don't always need to debug though.
A secondary option, is to run against IIS, and only attach to the process as needed.
I am trying to debug some code in my ASP.NET web app.
I set a breakpoint in one of the page events of the page's codebehind, and this once came up with a special icon in place of the red breakpoint saying symbols have not been loaded and the breakpoint will not be hit.
This error has not repeated itself but why can't I hit the breakpoint?
Also, when I press stop, I get a popup in VS stating:
Stop Debugging In Progres...
Debugging is being stopped but is not yet complete. You can force debugging to stop completely, but any processes attached may terminate.
This window will automatically close when debugging has completely stopped.
Completely stop
I also don't get the website appear in my browser either when starting to debug. :(
To make things worse, I have a line of code like this in my page's codebehind:
RssFeedSites = opml.Parse(filestream);
I am putting the problematic breakpoint on this line. But I have a programatic breakpoint in the Parse() method of opml, but this does not get hit, either.
Thanks
Could you check if the dll is perhaps in the GAC? If it is it is probably an older version and the GAC has priority over local dll's. So if the dll is in the GAC visual studio is using that (older) version instead of the newly built one.
the debugging host could not find the correct pdb's to match your executable or the debugging host is failing.
Check your build, are your PDB's all up to date and in the correct directory to be found ?
Check the debugging host process if its having problem. If your using visual studio hosting process, then has the vshost.exe process somehow terminated prematurely ? If your remote debugging, check the remote debugger. Check your web server as well. If the debugging host process fails to respond, visual studio will be stuck when trying to debug.
I don't recall the specific reason for the message when I have seen it, but I always ignore it, because the symbols get loaded when the page is executed and it always hits the breakpoint assuming it's in the process flow of the page.
If you can't hit ANY debug points and you are running from local IIS, you will need to attach to the working process(w3wp.exe). Tools->Attach to Process.