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]

Answer 1

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.

Answer 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.