Come utilizzare Fiddler per monitorare il servizio WCF

Ho un servizio WCF che accetta un tipo complesso e restituisce alcuni dati. Voglio usare Fiddler per vedere come appaiono le richieste in arrivo al servizio. Il client è un'app console .net che utilizza un proxy di riferimento del servizio. È possibile con Fiddler. Sono nuovo di questo strumento e l'ho usato solo in passato per pubblicare dati con il generatore di richieste.

Devi aggiungerlo nel tuo file web.config

<system.net>
  <defaultProxy>
    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>

1. quindi avvia Fiddler sulla macchina WEBSERVER.
2. Fare clic su Strumenti | Opzioni Fiddler => Connessioni => regola la porta come 8888 (consenti il ​​telecomando se ne hai bisogno)
3. Ok, quindi dal menu file, cattura il traffico.

Questo è tutto, ma non dimenticare di rimuovere le righe web.config dopo aver chiuso il fiddler, perché se non lo fai commetterà un errore.

Riferimento: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy

Fiddler ascolta le richieste in uscita anziché le richieste in entrata, quindi non sarai in grado di monitorare tutte le richieste in arrivo al tuo servizio utilizzando Fiddler.

Il meglio che otterrai con Fiddler è la possibilità di vedere tutte le richieste mentre vengono generate dalla tua app console (supponendo che l'app generi richieste web piuttosto che usare qualche altra pipeline).

Se vuoi uno strumento più potente (ma più difficile da usare) che ti permetta di monitorare TUTTE le richieste in arrivo, dovresti dare un'occhiata a WireShark.

modificare

Mi correggo. Grazie a Eric Law per aver pubblicato le istruzioni per configurare Fiddler come proxy inverso !

Ho appena avuto questo problema, ciò che ha funzionato per me è stato utilizzare localhost.fiddler:

 <endpoint address="http://localhost.fiddler/test/test.svc"
            binding="basicHttpBinding" 
            bindingConfiguration="customBinding" 
            contract="test" 
            name="customBinding"/>

Consolidamento degli avvertimenti menzionati nei commenti / risposte per diversi casi d'uso.

Per lo più, vedi http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

• Avvia Fiddler prima della tua app

• In un'app console, potrebbe non essere necessario specificare proxyaddress:

  <proxy bypassonlocal="False" usesystemdefault="True" />

• In un'applicazione Web / qualcosa ospitato in IIS, è necessario aggiungere proxyaddress:

  <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />

• Quando .NET effettua una richiesta (tramite un client di servizio o HttpWebRequest, ecc.), Ignorerà sempre il proxy Fiddler per gli URL che contengono localhost, quindi è necessario utilizzare un alias come il nome della macchina o creare qualcosa nel file 'host' (motivo per cui qualcosa di simile localhost.fiddlero http://HOSTNAMEfunziona)

• Se specifichi il proxyaddress, devi rimuoverlo dalla tua configurazione se Fiddler non è attivo, o qualsiasi richiesta che la tua app fa genererà un'eccezione come:

  Impossibile stabilire una connessione perché la macchina di destinazione l'ha rifiutata attivamente 127.0.0.1:8888

• Non dimenticare di utilizzare le trasformazioni di configurazione per rimuovere la sezione proxy in produzione

Così semplice, tutto ciò di cui hai bisogno è cambiare l'indirizzo nel client di configurazione: invece di 'localhost' cambia il nome della macchina o l'IP

Questo è semplice se hai il controllo sul client che invia le comunicazioni. Tutto quello che devi fare è impostare HttpProxy sulla classe del servizio lato client.

L'ho fatto, ad esempio, per tracciare un client di servizi Web in esecuzione su uno smartphone. Ho impostato il proxy su quella connessione lato client sull'IP / porta di Fiddler, che era in esecuzione su un PC in rete. L'app per smartphone ha quindi inviato tutte le comunicazioni in uscita al servizio web, tramite Fiddler.

Ha funzionato perfettamente.

Se il tuo client è un client WCF, consulta queste domande e risposte per informazioni su come impostare il proxy.

Anche se non hai la possibilità di modificare il codice dell'app lato client, potresti essere in grado di impostare il proxy in modo amministrativo, a seconda dello stack di servizi web utilizzato dal tuo client.

Traccia / diagnostica WCF standard

Se per qualche motivo non sei in grado di far funzionare Fiddler, o preferisci registrare le richieste in un altro modo, un'altra opzione è quella di utilizzare la funzionalità di traccia WCF standard. Questo produrrà un file con un bel visualizzatore.

Documenti

Vedi https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging

Configurazione

Aggiungi quanto segue alla tua configurazione, assicurati che c:\logsesista, ricostruisci e fai richieste:

  <system.serviceModel>
    <diagnostics>
      <!-- Enable Message Logging here. -->
      <!-- log all messages received or sent at the transport or service model levels -->
      <messageLogging logEntireMessage="true"
                      maxMessagesToLog="300"
                      logMessagesAtServiceLevel="true"
                      logMalformedMessages="true"
                      logMessagesAtTransportLevel="true" />
    </diagnostics>
  </system.serviceModel>

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information,ActivityTracing"
        propagateActivity="true">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener"
        name="xml" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Ho usato lo strumento Wire Shark per monitorare le chiamate di servizio dall'app Silver Light nel browser al servizio. provare il collegamento fornisce informazioni chiare

Consente di monitorare l'intera richiesta e il contenuto della risposta.

Ho appena provato la prima risposta di Brad Rem e sono arrivato a questa impostazione nel web.config sotto BasicHttpBinding:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
        ...
      </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

Spero che questo aiuti qualcuno.

Puoi utilizzare la versione gratuita di HTTP Debugger.

Non è un proxy e non è necessario apportare modifiche in web.config.

Inoltre, può mostrare entrambi; richieste HTTP in entrata e in uscita. Debugger HTTP gratuito