5

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

組み込みの Web Serverを使用して、Visual Studio Debugの任意のランダム ページを使用して Web アプリケーションを開始します。次に、URL を手動で編集して、/tx/ ディレクトリとその後に続くランダムな文字列を指すようにします。たとえば、現在の URL はhttp://localhost:53699/tx/sdfsのようになっています。これはProcessRequest()の最初の行でブレークポイントをプルアップするはずだと思っていました が、そうではありません。

どんなアイデアにも感謝します。

OO

編集：追加情報

[プロジェクト プロパティ]の [ 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]
4

3 に答える 3

3

ハンドラーを独自の IIS アプリケーションに発行し、Visual Studio を IIS にアタッチすると、デバッグの準備が整います。

IIS にデプロイしたくない、またはデプロイできない場合 (HTTP ハンドラーをデバッグするときに、プロジェクトを IIS に発行するように Post Build スクリプトを構成します)、プロジェクトのスタートアップ オプションを「しない」に設定することで、Cassini をデバッグできます。ページを開き、Visual Studio を にアタッチしaspnet_wp.exeます。

また、Visual Studio を管理者として実行することを忘れないでください。そうしないと、アタッチが機能しません。

于 2012-06-18T15:12:41.487 に答える
2

他のすべてが失敗した場合は、 DebugBreak()、__debugBreak()、または _asm int 3 を使用して、アプリケーションでデバッグ割り込みを生成できます。これが実行され、MSDev がインストールされている場合、終了するかどうかを確認するダイアログ ボックスが表示されます。またはデバッグします。これにより、今すぐ実行して後でアタッチすることができ、何にアタッチするかを知らなくても機能します。

于 2012-06-18T16:44:18.523 に答える
1

オプションのツール -> プロセスにアタッチし、目的のプロセスを選択して、プロセス (例: w3wp.exe) にプロセスをアタッチすると、ブレークポイントがヒットします。

于 2014-02-11T10:04:31.177 に答える