17

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?

SteveC
  • 15,808
  • 23
  • 102
  • 173
user259286
  • 977
  • 3
  • 18
  • 38
  • why don't you try to put some System.Diagnostics.Debug.WriteLine(...); in each of those events and check the output window while running the solution from Visual Studio? Do you see anything? – Davide Piras Oct 05 '11 at 11:48
  • 2
    See [this answer](http://stackoverflow.com/questions/1960651/it-is-possible-to-debug-global-asax/4809464#4809464) - does it help in your case? – Shadow The GPT Wizard Oct 05 '11 at 11:48
  • Could you paste the actual declarations of these methods? Maybe you've declared them incorrectly. – Andrew Barber Oct 05 '11 at 12:00
  • Thanks for your quick replies. However none of those worked, even the stuff from the link. By the way, I am in Debug mode and I have breakpoints in page code-behind that do get hit. – user259286 Oct 05 '11 at 12:17
  • Try using IIs instead and see if they hit – Erix Oct 05 '11 at 12:32
  • A bit late to the party, but if you edit the app.config file while the project is running, the breakpoint will be hit. – stuartd Apr 15 '15 at 14:51
  • Check this answer, worked for me: http://stackoverflow.com/a/8834890/1371217 – Zoomzoom Feb 04 '16 at 17:32

6 Answers6

31

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.

Joseph Woodward
  • 9,191
  • 5
  • 44
  • 63
Jeff Reddy
  • 5,551
  • 9
  • 55
  • 88
  • 4
    In VS 2013 Visual Studio Development Server is missing , also @Ofiris answer doesnt help – Osel Miko Dřevorubec Jul 21 '14 at 14:54
  • 1
    In VS 2019 you follow the steps above but on the Web tab, look at the Servers section and choose IIS Express. I was using Local IIS and the breakpoints weren't working but switching to IIS Express fixed the problem. – Eric Mutta Mar 03 '20 at 09:52
7

What helped me was to add:

System.Diagnostics.Debugger.Break(); to that Application_Start() method.

Ofiris
  • 6,047
  • 6
  • 35
  • 58
3

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.

Ben Smith
  • 19,589
  • 6
  • 65
  • 93
2

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.

ChrisO
  • 5,068
  • 1
  • 34
  • 47
2

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)
Alexei - check Codidact
  • 22,016
  • 16
  • 145
  • 164
  • Not perfect but useful: entering web.config, making a no-effect change (put some blank outside of tags) and saving it. Deserved +1 :) – QMaster Nov 24 '17 at 18:00
1

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.

Jeremiah Reed
  • 83
  • 1
  • 2
  • 10