How to exit an ASP.NET application gracefully when stopping debugging in VS 2010? - asp.net

I develop and debug an ASP.NET application with VS 2010. My ASP.NET application holds some connections to other applications on other machines. When I stop debugging, I want these connections to be released. If this doesn't happen, these other applications fail and I have to restart them.
In the end I will store my termination code in the Application_End method in Global.asax.cs, but this one is not called when stopping debugging.
Is there a way to terminate the debugging of my ASP.NET application so that not everything is killed at once, but so that one last method is called in which I could add my termination code?

I'm not sure what your problem is but probably...
You initialize your debug session by pressing F5 and thus debugging through cassini. This way when you end your debug session the application is terminated.
If you have a configured IIS application you could simply attach to the running process - it's usually "CTRL + ALT + P" - choosing w3wp.exe (mind the checkboxes on the bottom to be checked). This way your app won't be terminated on ending the debugging session.
Does it solve your problem?

I misunderstood how debugging an ASP.NET application works. I thought the moment I stop debugging (by pressing Shift+F5) the ASP.NET application is terminated and no further line of code is executed. It was my explanation to why the Application_End method is not called.
But in fact the ASP.NET application goes on when the debugger is detached and therefore the Application_End method is not called.

Related

IIS end application on every request

I've notice that on the production server, my asp.net 4.7.2 application is very slow. By debugging I've found that in global.asax the Application_start and Application_end is called on every request, causing a recompile of the application each time and slowing down the response.
I0ve test it on several servers and the behaviour is always the same.
Running the website on localhost in IIS (not iis express) this not happen.
How can I check why Application_End is called and from where?
Debugging in VS the Application_end stacktrace is empty, I cannot see from where is called.
Thanks
The problem was cause by Kaspersky Endpoint Security for Windows Server version 11.0.0.480.
For some unknown reason it act on w3wp.exe causing the application restart on each requests. The only way to solve the problem is excluding w3wp.exe from the monitored applications/processes.
There are many circumstances when the Application_end will be called, such as application pool's recycle, web.config file's change, or bin file's change. For more detailed information about Application_end be called you need to check the Event log in the sever.

How to debug a .NET web service initialization code in VS 2010?

Context: .NET web service deployed on local IIS in XP. VS 2010 used to debug the webservice code.
Problem:
I am familiar with debugging a hosted webservice by attaching VS to ASP.NET worker process. This approach works if the portion of code being debugged is not the initialization code such as constructors within webservice. When the ASP NET worker process is created, it calls the constructors in the webservice. So by the time we attach to ASP NET worker process from VS, the constructors have already been invoked and therefore not possible to debug.
How do i attach to the ASPNET process and debug the webservice even before it reaches the constructors within the webservice?
Almost a duplicate of this.
You can insert a
Debugger.Launch();
instruction in the web service constructor to be prompted for a debugger to attach. See MSDN.
This may not be the best option, but it was the only solution I was able to find when I had a similar problem. Put a Thread.Sleep(xxxx) in your constructor and try and race to beat the clock and get attached before it is finished initializing. You need to be careful not to set the sleep too high as the service could get stopped if it is not done initializing under a certain number of seconds. (it is also a pain when it decides to kill the service on you before you have finished stepping through the initialization function because it did not return quick enough.)

While Debugging IIS from VS2008 Website Is Unresponsive

I have a web app running in a local instance of IIS 7.5. My app pool has it Maximum Worker PROCESSES at 3. When I go to Vs2008 and attach my debugger to my local IIS I see three w3wp.exe processes as expected. I attach to all three. When I run a web page my breakpoint hits in my code behind, as expected.
Here's the problem: in my code behind my C# code is calling a service on another computer that in turn sends a request back to my local IIS box. This is all synchronous. The problem is that while I'm in the debugger it seems like that remote code's call to my IIS box is immediately failing. If I go on to that remote box while I'm debugging and try to pull up any URL from my local box it hangs. And, as soon as I hit F5 in VS2008 the browser frees up and fulfills the request.
So why does the VS2008 debugger cause IIS to not use any of the other worker processes to service other incomming requests?
Thanks for any ideas.
While you debugging any process - all the threads hangs.
So what you're describing is expected behavior. You're debugging a thread in IIS, the whole process hangs until you press F5 and return the control to the process.

Visual Studio don't call Application_End on Debug

I implement some code in Application_Start and Application_End (global.asax).
When i start ASP.NET Developer Server the Application_Start run normally.
When i change the web.config file, the method Application_Start is called again but Application_End is never called.
Someone know how can i force Application_End run before the second call to Application_Start
Is Application_End not being called or is it that a break point in Application_End is not being hit?
Application_End is called when the application pool is stopped.
When you are debugging you are attached to the application pool process.
What may be happening is that the debugger looses contact with the application pool before the Application_End is called, and you are therefore not hitting the break point.
My code opens a server socket in Application_Start, so Visual Studio couldn´t restart my application whitout closing it.
For safety VS don´t restart my Application.
VS calls Application_End only if he knows that noone is affected.
In my case i could be using the socket to sending or receiving data.

Flakey debug behavior in application start, global.asax

Not using Cassini, but IIS7 to run an ASP.NET app.
The debug behavior is flakey. Sometimes it works, sometimes it doesn't. I was able to step into the application start event in global.asax but sometimes I can't.
Sometimes VS2008 opens the published global.asax so I have two instances of global.asax opened in VS, the source and the published.
I reset the AppDomain and IIS and I can't put my finger on why this is happening. Any clues?
To add, while it won't go into application start, I have an OnChangeEventHandler event - it does step into the event handler.
Visual Studio doesn't connect to w3wp.exe soon enough to handle breakpoints in Application_Start for IIS7-hosted applications. To debug, use the following line to call debugger explicitly,
System.Diagnostics.Debugger.Launch();
and choose to launch a new instance of Visual Studio.
make a change in the web.config, the application pool will recycle and the global.asax code will be loaded, the debugger should still be attached

Resources