Cómo usar Fiddler para monitorear el servicio WCF

Tengo un servicio WCF que acepta un tipo complejo y devuelve algunos datos. Quiero usar Fiddler para ver cómo se ven las solicitudes entrantes al servicio. El cliente es una aplicación de consola .net que utiliza un proxy de referencia de servicio. ¿Es esto posible con Fiddler? Soy nuevo en esta herramienta y solo la he usado en el pasado para publicar datos con el generador de solicitudes.

Necesita agregar esto en su web.config

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

1. luego inicie Fiddler en la máquina WEBSERVER.
2. Haga clic en Herramientas | Opciones de Fiddler => Conexiones => ajusta el puerto como 8888 (permite el control remoto si lo necesitas)
3. Ok, luego desde el menú de archivo, capture el tráfico.

Eso es todo, pero no olvide eliminar las líneas web.config después de cerrar el violinista, porque si no lo hace, se producirá un error.

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

Fiddler escucha las solicitudes salientes en lugar de las solicitudes entrantes, por lo que no podrá monitorear todas las solicitudes que ingresan a su servicio utilizando Fiddler.

Lo mejor que obtendrá con Fiddler es la capacidad de ver todas las solicitudes a medida que las genera su aplicación de consola (asumiendo que la aplicación genera solicitudes web en lugar de usar alguna otra canalización).

Si desea una herramienta que sea más poderosa (pero más difícil de usar) que le permita monitorear TODAS las solicitudes entrantes, debe consultar WireShark.

Editar

Me quedo corregido. ¡Gracias a Eric Law por publicar las instrucciones para configurar Fiddler para que sea un proxy inverso !

Acabo de tener este problema, lo que funcionó para mí fue usar localhost.fiddler:

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

Consolidar las advertencias mencionadas en los comentarios / respuestas para varios casos de uso.

Principalmente, consulte http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

• Inicie Fiddler antes de su aplicación

• En una aplicación de consola, es posible que no necesite especificar proxyaddress:

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

• En una aplicación web / algo alojado en IIS, debe agregar proxyaddress:

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

• Cuando .NET realiza una solicitud (a través de un cliente de servicio o HttpWebRequest, etc.), siempre omitirá el proxy de Fiddler para las URL que contienen localhost, por lo que debe usar un alias como el nombre de la máquina o crear algo en su archivo 'hosts' (por eso algo como localhost.fiddlero http://HOSTNAMEfunciona)

• Si especificas proxyaddress, debes eliminarlo de tu configuración si Fiddler no está activado, o cualquier solicitud que haga tu aplicación generará una excepción como:

  No se pudo establecer ninguna conexión porque la máquina de destino la rechazó activamente 127.0.0.1:8888

• No olvide usar transformaciones de configuración para eliminar la sección de proxy en producción

Tan simple, todo lo que necesita es cambiar la dirección en el cliente de configuración: en lugar de 'localhost', cambie el nombre de la máquina o la IP

Esto es sencillo si tiene control sobre el cliente que envía las comunicaciones. Todo lo que necesita hacer es configurar HttpProxy en la clase de servicio del lado del cliente.

Hice esto, por ejemplo, para rastrear un cliente de servicio web que se ejecuta en un teléfono inteligente. Configuré el proxy en esa conexión del lado del cliente a la IP / puerto de Fiddler, que se estaba ejecutando en una PC en la red. La aplicación de teléfono inteligente envió toda su comunicación saliente al servicio web, a través de Fiddler.

Esto funcionó perfectamente.

Si su cliente es un cliente WCF, consulte estas preguntas y respuestas para saber cómo configurar el proxy.

Incluso si no tiene la capacidad de modificar el código de la aplicación del lado del cliente, es posible que pueda configurar el proxy administrativamente, dependiendo de la pila de servicios web que utilice su cliente.

Seguimiento / diagnóstico de WCF estándar

Si por alguna razón no puede hacer que Fiddler funcione, o prefiere registrar las solicitudes de otra manera, otra opción es usar la funcionalidad de seguimiento WCF estándar. Esto producirá un archivo que tiene un buen visor.

Docs

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

Configuración

Agregue lo siguiente a su configuración, asegúrese de que c:\logsexista, reconstruya y realice solicitudes:

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

He utilizado la herramienta Wire Shark para monitorear las llamadas de servicio desde la aplicación Silver Light en el navegador al servicio. prueba el enlace da información clara

Le permite monitorear todo el contenido de la solicitud y la respuesta.

Acabo de probar la primera respuesta de Brad Rem y llegué a esta configuración en web.config en BasicHttpBinding:

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

Espero que esto ayude a alguien.

Puede utilizar la versión gratuita de HTTP Debugger.

No es un proxy y no es necesario realizar ningún cambio en web.config.

Además, puede mostrar ambos; solicitudes HTTP entrantes y salientes. Depurador HTTP gratuito