Debugging a HTTP Handler from Visual Studio

Question

I am trying to debug a HTTP Handler in Visual Studio and the break point is not getting hit. Does anyone have an idea on how to go about debugging HTTP Handlers in Visual Studio?

I am using VS 2010 Premium, .NET 4.0 on a Windows 7 machine. In my Web Application I have a HTTP Handler in /HTTPHandler/TrackingHandler.cs

The following is in my web config file:

<system.webServer>
        <handlers>
            <add name="TrackingHandler" path="/tx/*" verb="*" type="ProjectNamespace.TrackingHandler" resourceType="Unspecified" preCondition="integratedMode" />
        </handlers>
  </system.webServer>

My HTTP Handler looks like below

namespace ProjectNamespace
{
    public class TrackingHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
             //Breakpoint on the very first line below
             string tracker = Path.GetFileName(context.Request.PhysicalPath);
              .......
         }
     }
}

I start my Web Application using any random page in Visual Studio Debug using the builtin Web Server. I then maually edit the URL to point to the /tx/ directory and some random string after it. For e.g. my current URL looks like http://localhost:53699/tx/sdfs. I thought this should pull up the breakpoint on the first line of ProcessRequest() but it does not.

I’d be grateful for any ideas.

O. O.

Edit: Additional Information

In the Project Properties, in the Web Tab, I selected Don’t open a page. Wait for a request from a external application. I was also getting a System.Web.HttpException, so I went to Debug -> Exceptions -> Common Language Runtime and checked the box alongside System.Web.

The following is my stack trace. It does not seem to be getting to my handler. Have I defined it wrongly in my Web config??

>   System.Web.dll!System.Web.StaticFileHandler.GetFileInfo(string virtualPathWithPathInfo, string physicalPath, System.Web.HttpResponse response) + 0x1f7 bytes    
    System.Web.dll!System.Web.StaticFileHandler.ProcessRequestInternal(System.Web.HttpContext context = {System.Web.HttpContext}, string overrideVirtualPath) + 0xc7 bytes  
    System.Web.dll!System.Web.DefaultHttpHandler.BeginProcessRequest(System.Web.HttpContext context, System.AsyncCallback callback = {Method = {System.Reflection.RuntimeMethodInfo}}, object state = null) + 0x15c bytes   
    System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() + 0x2d7 bytes    
    System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step = {System.Web.HttpApplication.CallHandlerExecutionStep}, ref bool completedSynchronously = true) + 0xb9 bytes  
    System.Web.dll!System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(System.Exception error) + 0x13e bytes  
    System.Web.dll!System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext context, System.AsyncCallback cb, object extraData) + 0xf8 bytes  
    System.Web.dll!System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest wr = {Microsoft.VisualStudio.WebHost.Request}) + 0x1a2 bytes  
    System.Web.dll!System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest wr) + 0x7d bytes  
    System.Web.dll!System.Web.HttpRuntime.ProcessRequest(System.Web.HttpWorkerRequest wr) + 0x47 bytes  
    WebDev.WebHost40.dll!Microsoft.VisualStudio.WebHost.Request.Process() + 0x17b bytes 
    WebDev.WebHost40.dll!Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Microsoft.VisualStudio.WebHost.Connection conn = {System.Runtime.Remoting.Proxies.__TransparentProxy}) + 0x6c bytes 
    [Appdomain Transition]  
    WebDev.WebHost40.dll!Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(object acceptedSocket) + 0x83 bytes   
    mscorlib.dll!System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(object state) + 0x2d bytes 
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool ignoreSyncCtx) + 0xb0 bytes    
    mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x5a bytes 
    mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x147 bytes  
    mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() + 0x2d bytes    
    [Native to Managed Transition]

score 3 · Answer 1 · answered Jun 18 '12 at 15:12

3

Publish the handler to its own IIS application and then attach Visual Studio to IIS and you're ready to debug.

If you don't want to or can't deploy to IIS (when debugging HTTP handlers I configure the Post Build script to publish the project to IIS), you can debug Cassini by setting the startup option of your project to 'Don't open a page' and attaching Visual Studio to aspnet_wp.exe.

And don't forget to run Visual Studio as Administrator, or attaching won't work.

answered Jun 18 '12 at 15:12

CodeCaster

147,647
23
218
272

Thank you. I could not find **aspnet_wp.exe** in the list of processes. I attempted to start up it in VS with the _“Don’t open a page”_ option as mentioned in the edit to my original question. From the stack trace I think its not even getting into my code. I am always running VS as **admin**. – O.O. Jun 19 '12 at 19:39
The AttachTo addin isn't compatible with VS.NET 2015 – Alex Klaus Sep 23 '16 at 04:55

score 2 · Answer 2 · answered Jun 18 '12 at 16:44

2

When all else fails, you can generate a debug interrupt in your application with DebugBreak(), __debugBreak(), or _asm int 3. When this is executed and you have MSDev installed, you should get a dialog box asking if you want to terminate or debug. This allows you to run now and attach later, and works without you having to know what to attach to.

answered Jun 18 '12 at 16:44

tbroberg

635
3
11

@ tbroberg: Where do I put the **DebugBreak()**? It does not work on the first line of the **ProcessRequest()**. (I could not get **DebugBreak()** to compile. I assume this is just for C++, while I am using C#. I used instead **Debugger.Launch(); Debugger.Break();** - but this did not work.) – O.O. Jun 19 '12 at 15:35
Ah, C#. See this [related thread](http://stackoverflow.com/questions/104235/how-can-i-use-debugbreak-in-c) – tbroberg Jun 21 '12 at 18:58

score 1 · Answer 3 · answered Feb 11 '14 at 10:04

1

Breakpoints will get hit if you attach process to it (e.g w3wp.exe) from option tools->Attach to process and select the desired process.

answered Feb 11 '14 at 10:04

Suraj Shinde

31
3

Debugging a HTTP Handler from Visual Studio

3 Answers3