I find the Edit & Continue feature is a great advantage if you develop an ASP.NET project. The only "problem" I run into is that if I want to use Edit & Continue, I need to start the debugger and run the code in the ASP.NET Development Server. When I want to stop debugging for a moment, the server stops and the web app is not available anymore -> Logic.
I would like to be able to start the server with the Edit & Continue feature, but not attach the debugger to the process yet. After some actions (login, filling a form etc), I want to attach the debugger to the process and be able to break at breakpoints and use the Edit & Continue feature.
It does work to start the server without debugging mode and as soon as I attach to the development server process, it does break, but by that time, the Edit & Continue does not work anymore. It tells me:
Changes are not allowed in the following cases:
- When the degbugger has been attached to an already running process.
- The code being debugged was optimized at build or run time.
- The assembly being debugged is loaded as domain-neutral.
- The assembly being debugged was loaded through reflection.
- When Intellitrace events and call information is enabled."
Is there a way to attach later and have a working Edit & Continue?
Why do I want this:
Imagine that I have a lot of breakpoints in my code and don't want to disable them one by one, but I would like to attach to the server process only after I have made some actions (login, filling out a form etc), in order to prevent that I need to continue on each break. Once I am just before my action I need to debug, I want to attach and then be able to edit the code without the need of restarting the web server and doing all the actions all over again.
I hope I was clear enough...
Related
We are developing an (internal) web service based on asp.net 4.8, with a fairly extensive REACT SPA front end.
For debugging purposes during development, we run an IIS server on the local (development) machine, and we do something separate to run a proxy web server for debugging the .js front end SPA (not relevant to the question at hand).
When we start up a Debug session in Visual Studio (2019), VS starts with "Contacting web server to start debugging" and then locks for a time. It clearly does something to start the web server (w3wp.exe), and waits for some reply, before doing what it is told to do in the "Start Action" section of the Web tab on the project properties page.
This is problematic behaviour because it does not attach to w3wp.exe until after it finishes it's "contacting web server to start debugging" operation. This is a huge problem, as our w3wp.exe starts doing all kinds of things that we have no visibility into.
So, can anyone explain to me:
What does VS actually do to "contact the web server"?
Can this be controlled? If so, how?
Can I get the debugger to attach to w3wp.exe right away?
Why does w3wp.exe start up and load its collection of binaries, only unload them and reload them, sometime multiple times?
In short, what the actual heck is going on under the covers at startup?
This (Identity Server 3 Contacting the web server hangs when launching debug mode) question and answer seem irrelevant to my situation
I note the field Override application root URL in the Servers section of the Web tab of the project properties and had hoped this might have something to do with it, but I cannot see any relation.
Partial answers that I will either edit as I find more info, or modify if others correct me, or delete if someone answers completely. The answers to (1) and (2) above are this:
VS obtains the URL of the target web site (I will call this targetServer) from the Project URL entry in the Servers section, Web tab, of the Properties page for the web project. This actually comes from the <webProjectName>.csproj.user file in the project directory. Depending on the selection of the drop down specifying the server type to use, it comes from:
IIS server (<UseIIS>true): the <IISUrl> element
External Host (<UseCustomServer>true): the <CustomServerUrl>
IIS Express: unknown
WARNING: When opening a project with <UseIIS>true, Visual Studio has the very nasty habit of interfering in the setup of your IIS server: it insists on changing the "Physical Location" attribute of the IIS server (that is, the server or virtual app, however you have it set up) to point to the project directory of the web project. Using the "External Host" option avoids this - see https://stackoverflow.com/a/48753054/1082063. (All other discussions of this issue that I have seen incorrectly say this cannot be controlled.)
VS then issues a request to the url <targetServer>/debugAttach.aspx, and the request shows as neither a "GET" nor a "POST", but a "DEBUG", whatever that is. Not sure what VS expects back from this before doing the specified Start Action
Presumably after VS gets some reply from its DEBUG request, it will attach to the process that resulted from this request. Not sure how it knows which process to attach to - perhaps the debugAttach.aspx returns process information?
VS finally executes whatever Start Action is specified in the section of that name on the Web tab of the project Properties.
I strongly suspect that the answer to (3) above is that one cannot get VisualStudio to attach any earlier than it does because it must use the information returned from the debugAttach.aspx request to know which process to attach to. However, putting the line System.Diagnostics.Debugger.Launch(); at the start of Application_Start will allow you to attach the debugger earlier when necessary. (In practice, once you get Application_Start correct, you seldom need to debug it.) See this: https://weblog.west-wind.com/posts/2011/Dec/15/Debugging-ApplicationStart-and-Module-Initialization-with-IIS-and-Visual-Studio for a very good article on the subject.
(4) was a result of quirks in our Visual Studio setup. The initial "hack" used to get around the WARNING in answer (2) just above, was to have a web site with a dummy "virtual path" and have the IISUrl element in Visual Studio point to this virtual path. Then VS could change the Physical path of this virtual path, and we didn't really care, because our Start Action was to start a proxy server for debugging .js in any case. The issue was that this resulted in two calls to Application_start, running on two separate threads: one for the main server and one for the virtual server. Because one of these was happening before the attach happened, we never knew it was happening and it was never caught in a break point. When our application_start became long (timewise - this is not a web server for public consumption...), the two executions of application_start became a nightmare.
The issue you're seeing in IIS is that VS is not launching w3wp.exe, but rather Attaching to Process. In order for VS to attach though the EXE has to be running first, and the time between starting up and attaching (if not already running) ends up being too late to catch the ASP.NET app initialization logic in Application_Start and Module initialization.
As mentioned in my old post there are several ways you can get this to work:
Restarting the application when the debugger is already attached
(by making a change in web.config to trigger an AppDomain reload)
Adding an explicit Debugger.Break() call in Application_Start
Use IIS Express to debug startup code
I have a project that has, amongst other things, one web application (mvc) and one WPF application. For the part that matters, the WPF app connect to a WCF service hosted on the website.
What I want to achieve is that when I press Ctrl+F5 (start WITHOUT debugging), the build process kicks in (if needed, in other words, the default VS behavior), the WPF app launched, and if the webdev server is not launched, that it get launched too, but without opening any page on my browser (I'll manage that myself).
I managed to get that working as I want (configuration below), but every time I do a Ctrl+F5, I get a popup from VS that says
Choosing to wait for a request from another process without enabling
ASP.NET debugging results in nothing to debug.
I value the information, and that seems to match pretty much what I'm trying to accomplish anyway, but now, instead of having to close a useless tab in my browser, I have to close a modal dialog. Not a big improvement from my point of view.
So, how do I prevent this popup to show up ?
Additional information:
I don't want to start in debug mode (F5). If I need debug for the website, I'll do my usual (attaching to the webdev server).
I want the webdev server to be running all the time from the first CTRL+F5.
I don't want to publish it on IIS (even the express version)
The solution startup option is set on "Multi startup project" with the WPF app on "Start" and the website on "Start without debugging" (setting it on Start doesn't change anything, except that I also get the popup when debugging with F5 directly).
The website has its start action configured on "Don't open a page. Wait for a request from an external application". The ASP.NET checkbox in the Debuggers is checked.
Internet had not been a big help so far, so all my hopes lies on you SOers !
Edit
It seems that it was flagged as a bug, but I don't see any reference in what version it's supposed to be fixed...
Also, I discovered my question is a duplicate of this one.
I actually found another way : in the start actions, you can set it to "start external program" and reference a self quitting program. I used "C:\Windows\System32\PING.EXE". Not perfect, but also less annoying than the previous solutions.
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.
This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.
We have a Windows Server 2003 that is running IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.
When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.
Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.
Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.
Setup
Start -> Run -> inetmgr
Right Click on Application Pools
Click New -> Application Pool
Name the new pool
Right Click on the application you want to isolate
Click Properties
Click on the Home Directory tab
In the application pool drop-down list select your new pool
Click OK
If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.
Debugging
To figure out which instance of w3wp.exe you need to attach the debugger to:
Start -> Run -> cmd
Type iisapp
You may be prompted to register CScript, if so click yes and run it again
The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.
Links
MSDN
Developer.com
"When someone attaches the debugger
and steps through the code, we find
that all users are affected. In
essence the web server stops handling
all requests from all users."
This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.
I've never found a way around it. Is there some reason you can't debug on each developer's workstation?
Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.
Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.
I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.
It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.
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.