Is it possible to debug Global.asax?

I can not debug the global.asax file!

I have some codes in the Application_Start() method, but when I set a breakpoint in the method, it is ignored!

This is normal?

+48
global-asax
Dec 25 '09 at 6:46
source share
11 answers

Maybe you should try:

  • stop the development server on the taskbar
  • switch configuration from debug version
+7
Dec 25 '09 at 6:56
source share

An easy way to crack Application_Start() is to use the System.Diagnostics.Debugger class. You can cause the application to crash by inserting System.Diagnostics.Debugger.Break() , where you want the debugger to break.

 void Application_Start(object sender, EventArgs e) { System.Diagnostics.Debugger.Break(); // ... } 
+86
Jan 26 2018-11-11T00:
source share
  • Attach the debugger to the IIS process.
  • Open the global.asax file and set a breakpoint.
  • Add a space to the web.config file and save the file (this will cause the current web application to reset);
  • Refresh / go to the web page on the site.
  • look in amazement when the debugger stops at a breakpoint. :)
+64
Jan 12 '12 at 12:12
source share

Application_Start() is called once per AppDomain. If you do not click on a breakpoint, this means that the AppDomain has already been created, so do the following:

  • Your quick launch bar has an icon for the VS web server (this is the one that says "Local Host Some Port"). Right-click and select Stop or Close. This should kill AppDomain.
    • If you use IIS, you need to manually reload your site.
    • Alternatively, changing the web configuration or Global.asax file is usually enough to restart AppDomain.
  • Restart your debugging, now you have to click on your breakpoints.
+9
Dec 25 '09 at 6:52
source share

Make sure your web application is in debug mode ( <compilation debug="true"> in web.config).

If you are using an IIS developer running VS, just restart it or rebuild the application.

If you use regular IIS, you have two options:

  • The website is configured to work with the development folder (where the VS web project is deployed), you just need to restart the application pool installed for this website and start debugging before the first request reaches the server (you can always restart application pool during debugging).
  • For a website that runs in a different folder or even on a remote server, you must connect to the process. To do this, you need a remote debugger installed on the remote computer or your own (depending on the location of the web server), and use the Debug - Attach to process menu, enter the computer name and then select the process to debug. Typically, the w3wp.exe file runs in managed mode.
+7
Dec 25 '09 at 7:06
source share

Yes, it is normal.

Application_Start() processed by IIS.

But all other methods, for example Session_Start , and all others, except Application_Start() , can be debugged in the normal mode.

+5
Dec 25 '09 at 6:50
source share

Another alternative to the accepted System.Diagnostics.Debugger.Break(); will be

 void Application_Start(object sender, EventArgs e) { System.Diagnostics.Debugger.Launch(); //... } 

which should not interrupt the code and should run the debugger, even if the service was started with different rights.

+3
Dec 05 '13 at 13:37
source share

Remove global.asax and add a new one. My solution was global.asax and a global.asax.cs .

All methods ( Session_Start , Application_Start , ...) were in the bot files, but only those from global.asax were considered. So, breakpoints and cs code do nothing.
Only after recreating the file global.asax.cs had the corresponding methods, and they were executed.

+2
Dec 12 '11 at 11:47
source share

Do not expect the Application_Start () function to be called immediately by pressing f5. Application_Start () is called only during the first request to the application. Strange, but true.

0
Feb 10 '14 at 6:52
source share

If all answers do not work, try:

 <compilation debug="true" ... /> 

in web.config .;)

0
Dec 29 '16 at 7:19
source share

For me, my debug breakpoint has already been completed in IIS by the time the debugger is attached. So the solution was to modify global.asax with a little space and save the file. After the upgrade, my breakpoint is now reached.

The solution is here: https://wakeupandcode.com/hitting-breakpoints-in-global-asax/

0
Apr 10 '19 at 16:24
source share



All Articles