[ACCEPTED]-How do you debug ASP.net HTTPHandler-httphandler

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

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

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

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

<%@ WebHandler Language="C#" CodeBehind="MyNewHandler.ashx.cs"
    Class="mynamespace.MyOldHandler" %>

I had this problem and it turns out that 11 the ashx file didn't compile. I guess they 10 get compiled at runtime because I didn't 9 get a compile error until then. Additionally 8 I wasn't seeing the Yellow Screen of Death 7 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 6 I did see the newly introduced exception, fixed 5 the compile error, and now the breakpoint 4 is being hit like it should, although it 3 doesn't light up when the debugger is initially 2 launched, rather when the handler is invoked 1 (by an AJAX call in my case).

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

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

I found the method used to debug Windows 10 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 9 put the code above in your ProcessRequest 8 method, you build for Debug and deploy on 7 your local machine. Keeping the project 6 open in Visual Studio, when your website 5 invokes the handler, a dialog will pop up 4 allowing to choose that instance. Once you 3 select the instance, switch to VS and you 2 will notice execution is on the System.Diagnostics.Debugger.Launch(); line, waiting 1 for you to continue.

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

System.Diagnostics.Debugger.Break();

The debugger 1 then stopped at breakpoints I had set.

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

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

I had the same problem when debugging using 5 IIS.

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

My 2 web.config also had an httpHandlers element:

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

(where 1 my built assembly was MyWebService.dll)

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

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

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

for example:

http://localhost/YourSite/YourHandler.ashx