Verwendung von Fiddler zur Überwachung des WCF-Dienstes

Ich habe einen WCF-Dienst, der einen komplexen Typ akzeptiert und einige Daten zurückgibt. Ich möchte Fiddler verwenden, um zu sehen, wie die eingehenden Anforderungen an den Dienst aussehen. Der Client ist eine .net-Konsolen-App, die einen Dienstreferenz-Proxy verwendet. Ist das mit Fiddler möglich? Ich bin neu in diesem Tool und habe es in der Vergangenheit nur verwendet, um Daten mit dem Request Builder zu veröffentlichen.

Sie müssen dies in Ihrer web.config hinzufügen

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

1. Starten Sie dann Fiddler auf der WEBSERVER-Maschine.
2. Klicken Sie auf Extras | Fiddler-Optionen => Verbindungen => Stellen Sie den Port auf 8888 ein. (Erlauben Sie Remote, wenn Sie das brauchen.)
3. Ok, dann erfassen Sie über das Dateimenü den Datenverkehr.

Das ist alles, aber vergessen Sie nicht, die Zeilen web.config nach dem Schließen des Geigers zu entfernen, denn wenn Sie dies nicht tun, wird ein Fehler ausgegeben.

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

Fiddler hört auf ausgehende Anfragen und nicht auf eingehende Anfragen, sodass Sie nicht alle Anfragen, die bei Ihrem Dienst eingehen, mithilfe von Fiddler überwachen können.

Das Beste, was Sie mit Fiddler erreichen können, ist die Möglichkeit, alle Anforderungen zu sehen, die von Ihrer Konsolen-App generiert werden (vorausgesetzt, die App generiert Webanforderungen, anstatt eine andere Pipeline zu verwenden).

Wenn Sie ein leistungsfähigeres (aber schwieriger zu verwendendes) Tool wünschen, mit dem Sie ALLE eingehenden Anforderungen überwachen können, sollten Sie sich WireShark ansehen.

Bearbeiten

Ich stehe korrigiert. Vielen Dank an Eric Law für die Veröffentlichung der Anweisungen zur Konfiguration von Fiddler als Reverse-Proxy !

Hatte gerade dieses Problem, was für mich funktionierte, war localhost.fiddler zu verwenden:

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

Konsolidierung der in Kommentaren / Antworten genannten Vorbehalte für mehrere Anwendungsfälle.

Siehe meistens http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

• Starten Sie Fiddler vor Ihrer App

• In einer Konsolen-App müssen Sie möglicherweise nicht Folgendes angeben proxyaddress:

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

• In einer Webanwendung / etwas, das in IIS gehostet wird, müssen Sie Folgendes hinzufügen proxyaddress:

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

• Wenn .NET eine Anfrage stellt (über einen Service-Client oder HttpWebRequestusw.), wird der Fiddler-Proxy für URLs, die URLs enthalten localhost, immer umgangen. Sie müssen daher einen Alias ​​wie den Computernamen verwenden oder etwas in Ihrer Hosts-Datei erstellen (weshalb so etwas wie localhost.fiddleroder http://HOSTNAMEfunktioniert)

• Wenn Sie das angeben proxyaddress, müssen Sie es aus Ihrer Konfiguration entfernen, wenn Fiddler nicht aktiviert ist. Andernfalls werden bei Anfragen Ihrer App eine Ausnahme ausgelöst:

  Es konnte keine Verbindung hergestellt werden, da der Zielcomputer dies aktiv abgelehnt hat. 127.0.0.1:8888

• Vergessen Sie nicht, Konfigurationsumwandlungen zu verwenden, um den Proxy-Abschnitt in der Produktion zu entfernen

Sie müssen lediglich die Adresse im Konfigurationsclient ändern: Statt 'localhost' den Computernamen oder die IP-Adresse zu ändern

Dies ist unkompliziert, wenn Sie die Kontrolle über den Client haben, der die Kommunikation sendet. Sie müssen lediglich HttpProxy für die clientseitige Serviceklasse festlegen.

Ich habe dies beispielsweise getan, um einen Webdienst-Client zu verfolgen, der auf einem Smartphone ausgeführt wird. Ich habe den Proxy für diese clientseitige Verbindung auf die IP / den Port von Fiddler eingestellt, der auf einem PC im Netzwerk ausgeführt wurde. Die Smartphone-App hat dann die gesamte ausgehende Kommunikation über Fiddler an den Webdienst gesendet.

Das hat perfekt funktioniert.

Wenn Ihr Client ein WCF-Client ist, finden Sie in diesen Fragen und Antworten Informationen zum Festlegen des Proxys.

Selbst wenn Sie nicht in der Lage sind, den Code der clientseitigen App zu ändern, können Sie den Proxy möglicherweise administrativ festlegen, abhängig von dem von Ihrem Client verwendeten Webservices-Stack.

Standard WCF Tracing / Diagnose

Wenn Sie Fiddler aus irgendeinem Grund nicht zum Laufen bringen können oder die Anforderungen lieber auf andere Weise protokollieren möchten, können Sie auch die Standard-WCF-Ablaufverfolgungsfunktion verwenden. Dadurch wird eine Datei mit einem schönen Viewer erstellt.

Docs

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

Aufbau

Fügen Sie Ihrer Konfiguration Folgendes hinzu, stellen Sie sicher, dass sie c:\logsvorhanden ist, erstellen Sie sie neu und stellen Sie Anforderungen:

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

Ich habe das Wire Shark Tool zur Überwachung von Serviceanrufen von der Silver Light App im Browser zum Service verwendet. versuchen Sie den Link gibt klare Informationen

Sie können damit den gesamten Anforderungs- und Antwortinhalt überwachen.

Ich habe gerade die erste Antwort von Brad Rem ausprobiert und bin zu dieser Einstellung in der web.config unter BasicHttpBinding gekommen:

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

Hoffe das hilft jemandem.

Sie können die kostenlose Version von HTTP Debugger verwenden.

Es ist kein Proxy und Sie müssen keine Änderungen in web.config vornehmen.

Es kann auch beides zeigen; eingehende und ausgehende HTTP-Anfragen. HTTP Debugger kostenlos