从 Visual Studio 调试 HTTP 处理程序答案

【问题标题】：Debugging a HTTP Handler from Visual Studio从 Visual Studio 调试 HTTP 处理程序
【发布时间】：2012-06-18 15:05:33
【问题描述】：

我正在尝试在 Visual Studio 中调试 HTTP 处理程序，但没有命中断点。有人知道如何在 Visual Studio 中调试 HTTP 处理程序吗？

我在 Windows 7 机器上使用 VS 2010 Premium、.NET 4.0。在我的 Web 应用程序中，我在 /HTTPHandler/TrackingHandler.cs

中有一个 HTTP 处理程序

以下内容在我的 web 配置 文件中：

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

我的 HTTP 处理程序如下所示

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);
              .......
         }
     }
}

我使用 Visual Studio Debug 中的任何随机页面启动我的 Web 应用程序，并使用 内置 Web 服务器。然后我手动编辑 URL 以指向 /tx/ 目录 和它后面的一些随机字符串。 例如我当前的 URL 看起来像 http://localhost:53699/tx/sdfs。 我认为这应该在 ProcessRequest() 的第一行拉断点> 但事实并非如此。

如有任何想法，我将不胜感激。

哦。哦。

编辑：附加信息

在项目属性的Web选项卡中，我选择了不打开页面。等待来自外部应用程序的请求。我也收到了 System.Web.HttpException，所以我去了 Debug -> Exceptions -> Common Language Runtime 并选中 System.Web 旁边的复选框。

以下是我的堆栈跟踪。它似乎没有到达我的处理程序。我在 Web 配置 中是否定义错误？

>   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]

【问题讨论】：

标签： c# visual-studio-2010 httphandler visual-studio-debugging

【解决方案1】：

将处理程序发布到它自己的 IIS 应用程序，然后将attach Visual Studio 发布到 IIS，您就可以进行调试了。

如果您不想或无法部署到 IIS（在调试 HTTP 处理程序时，我配置 Post Build 脚本以将项目发布到 IIS），您可以通过将项目的启动选项设置为 ' 来调试 Cassini不要打开页面”并将 Visual Studio 附加到 aspnet_wp.exe。

别忘了以管理员身份运行 Visual Studio，否则附加将不起作用。

【讨论】：

谢谢。我在进程列表中找不到 aspnet_wp.exe。我尝试在 VS 中使用 “不要打开页面” 选项启动它，正如我在原始问题的编辑中提到的那样。从堆栈跟踪我认为它甚至没有进入我的代码。我总是以 admin 身份运行 VS。
AttachTo 插件与 VS.NET 2015 不兼容

【解决方案2】：

当所有其他方法都失败时，您可以使用 DebugBreak()、__debugBreak() 或 _asm int 3 在您的应用程序中生成 debug interrupt。执行此操作并且您安装了 MSDev，您应该会看到一个对话框，询问您是否你想终止或调试。这允许您现在运行并稍后附加，并且无需知道要附加到什么即可工作。

【讨论】：

@tbroberg：我应该把 DebugBreak() 放在哪里？它不适用于 ProcessRequest() 的第一行。（我无法编译 DebugBreak()。我认为这仅适用于 C++，而我使用的是 C#。我使用了 Debugger.Launch(); Debugger.Break(); - 但这不起作用。）
啊，C#。看到这个related thread

【解决方案3】：

如果您从选项工具中将进程附加到断点（例如 w3wp.exe），则会遇到断点->附加到进程并选择所需的进程。

【讨论】：