Debug di un gestore HTTP da Visual Studio

Question

Sto tentando di eseguire il debug di un gestore HTTP in Visual Studio e il punto di interruzione non viene colpito. Qualcuno ha un'idea su come eseguire il debug degli handler HTTP in Visual Studio?

Sto usando VS 2010 Premium, NET 4.0 su una macchina di 7di Windows. Nel mio Web Application ho un gestore HTTP in /HTTPHandler/TrackingHandler.cs

Di seguito è riportato nel mio config web di file:

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

mio HTTP Handler assomiglia sotto

Avvio la mia applicazione Web utilizzando qualsiasi pagina a caso in Visual Studio Debug utilizzando il server Web incorporato . Quindi modificherò l'URL per indicare la directory /tx/ e una stringa casuale dopo di essa. Ad es. il mio URL attuale è simile a http: // localhost: 53699/tx/sdfs. Ho pensato che questo dovrebbe richiamare il breakpoint sulla prima riga di ProcessRequest() ma non è così.

Sarei grato per qualsiasi idea.

O. O.

Edit: Informazioni aggiuntive

Negli Proprietà progetto, nella scheda Web, Ho selezionato Non aprire una pagina. Attendi una richiesta da un'applicazione esterna. Sono stato anche ottenere un System.Web.HttpException, così sono andato a Debug -> Eccezioni -> Common Language Runtime e controllato la casella a fianco System.Web.

Quanto segue è la traccia dello stack. Non sembra arrivare al mio gestore. L'ho definito erroneamente nella mia configurazione 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] 

Answer 1

Pubblica il gestore per la propria applicazione IIS e quindi attach Visual Studio per IIS e si è pronti per eseguire il debug.

Se non si desidera o non è possibile eseguire la distribuzione su IIS (durante il debug dei gestori HTTP, configurare lo script Post Build per pubblicare il progetto su IIS), è possibile eseguire il debug di Cassini impostando l'opzione di avvio del progetto su 'Non aprire una pagina' e allegando Visual Studio a aspnet_wp.exe.

E non dimenticare di eseguire Visual Studio come amministratore o il collegamento non funzionerà.

Answer 2

Quando tutto il resto fallisce, è possibile generare un debug interrupt nell'applicazione con DebugBreak(), __debugBreak(), o _asm int 3. Quando questo viene eseguito e si è installato MSDev, si dovrebbe ottenere una finestra di dialogo che chiede se si vuoi terminare o eseguire il debug. Ciò ti consente di eseguire ora e allegare in un secondo momento, e funziona senza che tu debba sapere a cosa allegare.

Answer 3

I punti di interruzione vengono colpiti se si allega il processo (ad esempio w3wp.exe) dagli strumenti opzione-> Collega per elaborare e selezionare il processo desiderato.