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
Related
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.
I have some code in my ASP.NET app in C# that's in the Global.asax.cs code file. In the Application_Start, Session_Start and Application_Begin Request I have set some breakpoints. However none of these are ever hit. I'm working on my local machine with VS8.
Here's what I've tried:
Stopped the ASP Dev Server
Deleted all ASP.NET Temporary files
Created new Global.asax
Closing VS and opening back up
Clean and Rebuild project
Upon trying my after these, the breakpoints will not hit.
Any ideas why this might be?
I've run into this same problem. I'm assuming you are using your local IIS instead of the VS Development Server. If this is the case, you won't be able to debug/Step through this code in the Global.asax.cs file because by the time the debugger has attached, this code has already executed in IIS. However, if you use the Dev server, you have the ability to get to this code as the debugger will already be attached.
So, Change the server in your project properties to use the Visual Studio Development Server.
This can be found by right clicking your project within Visual Studio > Project Properties > Web tab > Use Visual Studio Development Server.
What helped me was to add:
System.Diagnostics.Debugger.Break(); to that Application_Start() method.
On a project I was working on, the "Start external program" option was selected in the tab:
Visual Studio > Project Properties > Web
This was causing the breakpoints to not be hit.
Changing "Start Action" to "Current Page" fixed this problem for me.
As metioned in another answer, the Global.asax code will run before the debugger gets chance to attach. To get around that you can start debugging, then go into IIS and Stop/Start the Application which should then have the debugger pick up the restart.
If you do not want to use Visual Studio Development Server and use IIS, you can do the following (tested in VS2015 Professional)
1) Application pool in a running state - make sure that used Application Pool is running by accessing a page from your Web app (it may be stopped due to a Idle timeout).
2) Attach to process - Ctrl-Alt-P or Debug -> Attach to Process -> lookup your w3wp process that corresponds to your application.
Attach to process can be greatly sped up by using ReAttach extension which creates shortcuts to recently attached processes.
3) Application pool recycle - make sure that the application pool recycles by either entering IIS and recycling it or even faster, by entering web.config, making a no-effect change (put some blank outside of tags) and saving it
4) Start debugging - Perform a request to any page from your web application to force its initialization. You should be able to place and hit breakpoints from any of the startup methods in the Global.asax
protected void Application_Start()
void Application_BeginRequest(Object sender, EventArgs e)
protected void Session_Start(object sender, EventArgs e)
I had this issue twice. The first project this happened to me, I went to Project Properties->Build->Advanced... and selected "full" from the Debug Info dropdown.
The second time, the breakpoints in my global.asax we're not being hit but it gave this warning if I hovered over the breakpoint: "The source code is different from the original version."
I finally figured out that in this case, I had made a backup copy of this project to preserve the code and was working with the copy. Even though it was in a different folder, it was still using the dll for the virtual directory of the original: http://localhost:4952/
So I changed that in Project Properties->Web->Project URL. I just changed the port to http://localhost:49523/ and it worked.
It prompted me to create the virtual directory, I said yes and haven't had any problems with breakpoints since.
I'm trying to debug an ASP.NET application. I've created a virtual directory in IIS, copied all the binaries and web.config there. When I pass request from the client program running on the same computer aspnet_wp.exe is started but then something goes wrong.
I want to attach to the process and try debug it. When I ask Visual Studio to "Attach to process" it displays a list of processes and aspnet_wp.exe, inetinfo.exe and dllhost.exe are all displayed grayed as if they are already debugged by some other program and so I can't attach to any of them.
I have tried to disable the "debug" option in web.config:
<system.web>
<compilation debug="false">
othersettings
</system.web>
but it didn't change the behavior.
What's happening and how do I make aspnet_wp, inetinfo and dllhost all start in such way I can attach a debugger to either of them?
The problem was caused by IIS Diagnostic Toolkit which I installed recently. Since it performs some magic sniffering on IIS it needs attaching as a debugger. I don't know which component of the toolkit is causing the problem.
After I removed the toolkit all the three processes start normally and I can attach Visual Studio debugger to any of them.
I have an ASP.NET 3.5 sp1 app that's in development in Cassini. The app includes a global.asax file that should run some code - it works fine in Cassini but in IIS the debugger never hits the function. Why doesn't that code run?
Maybe in Cassini, the Application is started when Cassini is launched. In II7, a service, the application is already started and when you launchh the debugger, VS attached only the debugger. You can try to launch the debugger and recycle the pool in the IIS console to see the application restarted ?
You're manually attaching the debugger to the w3wp.exe process? Most likely you're simply too late and the Application_Start already ran by the time the debugger attaches.
Are you sure that the code isn't being executed or could it be that you are simply attaching to the process too late for the debugger to be of any use for it? I'd suggest adding some logging to the method to be sure.
I'm seeing the same issue with a WCF web project running in IIS7. The very first line of code in Application_Start() is a logger write, and I never get it. Also, other objects that are supposed to be initialized on Application_Start never get created and the rest of my code fails because of it. Anyone ever figure anything out with this? It does run fine in Cassini...
I'm trying to debug something in the global.asax.cs file in an ASP.NET web app and have set a breakpoint in the Application_Start() event however that event is not getting fired when I start the web app inside VS2008. I'm targeting the 3.5 framework.
What could prevent this event from being fired? Or how could I have messed up the project such that this event is no longer wired up?
One easy trick to debug newly written code in the global.asax file is to save the web.config file. Each time the config.file is saved, the application is stopped and started.
You could find useful information in this blog entry
Workaround: Debugging Global.aspx.cs Application_Start() with ASP.Net Web Server within Visual Studio
The reason behind this is that we do
not kill the ASP.Net Web Server
process after your every debug run and
hence Application_Start() is not fired
every time. There is a good reason
why we do so... Starting ASP.Net Web
Server process is an expensive task
and in most of the scenarios recycling
this process after every debug would
adversely impact your performance...
If you do not want to debug your
Application_Start() method then
probably you do not need to have the
process restart and save performance
most of the time...
One of the proposed workarounds:
You can go to your property pages of
your web application and enable Edit &
Continue like shown below:
(from the Visual Web Developer Team Blog)
If i remember correctly, Application_Start runs before the debugger can hook up to the application.
Try doing something else to check if the Application_Start method runs, like setting an application variable:
Application("app") = "started"
Then display the application variable in the page to see if it was set.