18

I have set a breakpoint in an HttpHandler in visual studio. The HttpHandler is an .ashx file I am trying to debug by running my application in the VS development web server. My breakpoint is not getting hit.

How can I step through it?

Edit: My breakpoint is not getting hit

Myster
  • 17,704
  • 13
  • 64
  • 93
Ronnie Overby
  • 45,287
  • 73
  • 267
  • 346

11 Answers11

10

Late reply, but it may serve if you have not found your answer with earlier ones.

If you have created your Handler by copying an existing ashx handler your problem may well be that the markup file of your handler is still pointing to the original handler.

VS by default opens the .ashx.cs file when double-clicking on the .ashx file as the markup file is almost never needed.

By right-clicking on the ashx VS will show option to View Markup, make sure that the Class property is not referring to the old handler.

<%@ WebHandler Language="C#" CodeBehind="MyNewHandler.ashx.cs"
    Class="mynamespace.MyOldHandler" %>
Giuseppe Romagnuolo
  • 3,362
  • 2
  • 30
  • 38
  • Thank you @Giuseppe, this fixed it for me, and it's something that's easy to overlook especially when copying an existing handler from a different project and forgetting to update the **Class** property of the 'Markup' file to point to the new **namespace**. – Anthony Walsh Nov 03 '13 at 18:32
  • thank you so much for this answer, only this helped me! –  May 04 '16 at 13:16
  • Are we talking about `WebHandlers` or `HttpHandlers` they are 2 different things. HttpHandler is registered via web.config and not with a page. – AaA Jan 27 '22 at 07:25
6

I had this problem and it turns out that the ashx file didn't compile. I guess they get compiled at runtime because I didn't get a compile error until then. Additionally I wasn't seeing the Yellow Screen of Death indicating an HttpCompileException because:

  • I originally intended to fix a bug in the asxh file.
  • I made changes to the file to fix the bug, in which I unknowingly introduced a compile error.
  • I tested the bug fix, got the all purpose friendly exception I had configured in custom errors.
  • I assumed it was the same bug I had gone into fix because I couldn't see the true exception a la Yellow Screen of Death and didn't bother checking ELMAH
  • I set a breakpoint, and couldn't figure out why it wasn't being hit.

Eventually I did see the newly introduced exception, fixed the compile error, and now the breakpoint is being hit like it should, although it doesn't light up when the debugger is initially launched, rather when the handler is invoked (by an AJAX call in my case).

Rex Miller
  • 2,706
  • 1
  • 19
  • 26
  • thanks that fixed my problem. A compile error that is not reported when building the project. – pauldendulk Oct 23 '12 at 19:52
  • As far as I know ASHX is not a [`HttpHandler`](https://learn.microsoft.com/en-us/dotnet/api/system.web.ihttphandler?view=netframework-4.8), it is a `WebHandler`. – AaA Jan 27 '22 at 07:34
4

Open the handler file in Visual Studio and place the breakpoint as you said. Then load the web application in your browser (starting your application in debug-mode of course). If the breakpoint remains gray and doesn't turn filled black, then your handler is probably not registered appropriately in your webapp. That's mostly the issue. If according to you everything is fine, try doing a clean + rebuild of your entire solution. And set your project as startup project(if you're using multiple projects). Often that helps already.

Asciiom
  • 9,867
  • 7
  • 38
  • 57
Juri
  • 32,424
  • 20
  • 102
  • 136
  • How do you register the handler? I didn't think you had to register *.ashx files. – Ronnie Overby Jul 28 '09 at 13:27
  • see this to learn how to register handlers http://msdn.microsoft.com/en-us/library/46c5ddfy(VS.80).aspx – MOZILLA Jul 28 '09 at 13:34
  • That's what I intended. Probably it isn't registered correctly and therefore you breakpoint is never hit. – Juri Jul 28 '09 at 13:37
  • Didn't work for me. The breakpoint is still marked red so it will be hit, but it's as if my ajax that calls the handler isn't working right – Ortund Nov 27 '12 at 12:47
  • Are you debugging using IISExpress or the local IIS Server? – Tim Aug 06 '14 at 12:05
2

Try do debug using the built in web server instead of the local IIS (or vice-versa if you're using the local IIS). There are minor differences between the two web servers.

Jan Aagaard
  • 10,940
  • 8
  • 45
  • 80
  • This is always my issue when I have trouble debugging web projects. For some reason Visual Studio 2013 seems to default to IIS Express...which I never want! – Kik Jun 05 '15 at 20:20
1

If you're failing to debug an http handler by accessing it from a web page within your app, try accessing the handler's URL directly within your web browser.

for example:

http://localhost/YourSite/YourHandler.ashx
Dave
  • 11
  • 2
1

I found the method used to debug Windows services also works for the HTTP Handler:

    public void ProcessRequest(System.Web.HttpContext objContext)
    {
// This will automatically launch a dialog that will allow to attach the process to a new or existing instance of Visual Studio
#if DEBUG
     System.Diagnostics.Debugger.Launch();
#endif
[...]

You put the code above in your ProcessRequest method, you build for Debug and deploy on your local machine. Keeping the project open in Visual Studio, when your website invokes the handler, a dialog will pop up allowing to choose that instance. Once you select the instance, switch to VS and you will notice execution is on the System.Diagnostics.Debugger.Launch(); line, waiting for you to continue.

sorinc
  • 11
  • 2
1

None of the above worked for me with Visual Studio 2015 however sorinc's response clued me in to add the following to somewhere near the start of the handler file:

System.Diagnostics.Debugger.Break();

The debugger then stopped at breakpoints I had set.

1

I tried a couple of the above suggestions without any luck. Then I opened my web.config and the solution was obvious. I had the debug attribute of the <compilation> node set to false in the <system.web> node. Once I set this to true, recompiled, and started the application with debugging, my breakpoint got hit.

<system.web>
   <compilation debug="true" />
</system.web>
iCode
  • 1,254
  • 1
  • 13
  • 16
0

I had the same problem when debugging using IIS.

Fix: * Add a handler mapping in IIS: Specify the type as your fully qualified handler class name (e.g. MyCompany.MyApp.MyHandler).

My web.config also had an httpHandlers element:

<add verb="*" path="*.p1s" type="MyCompany.MyApp.MyHandler, MyWebService" />

(where my built assembly was MyWebService.dll)

Andy Joiner
  • 5,932
  • 3
  • 45
  • 72
0

The above solutions didn't work for me. I already had my handler registered correctly.

My handler is in a web site project (not a web application). It is accessed by another web site (a test project) in the same Visual Studio solution. To get debug symbols to load, I set the solution to start multiple projects on startup. First my handler, then my test project.

Keith Walton
  • 5,211
  • 6
  • 39
  • 53
-2

In Visual Studio, Check out the Debug menu. In there you will find Step Into, Step Over etc, and depending on your keyboard binding you can typically hit F10.

David Christiansen
  • 5,869
  • 2
  • 36
  • 42