Como usar o Fiddler para monitorar o serviço WCF

Tenho um serviço WCF que aceita um tipo complexo e retorna alguns dados. Desejo usar o Fiddler para ver como são as solicitações de entrada para o serviço. O cliente é um aplicativo de console .net que usa um proxy de referência de serviço. Isso é possível com o Fiddler. Sou novo nesta ferramenta e só a usei no passado para postar dados com o construtor de solicitações.

Você precisa adicionar isso ao seu web.config

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

1. em seguida, inicie o Fiddler na máquina WEBSERVER.
2. Clique em Ferramentas | Opções do Fiddler => Conexões => ajuste a porta como 8888. (permita o controle remoto se precisar)
3. Ok, então no menu Arquivo, capture o tráfego.

Isso é tudo, mas não se esqueça de remover as linhas do web.config após fechar o fiddler, porque do contrário, ocorrerá um erro.

Referência: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy

O Fiddler escuta solicitações de saída em vez de solicitações de entrada, portanto, você não poderá monitorar todas as solicitações que chegam ao seu serviço usando o Fiddler.

O melhor que você obterá com o Fiddler é a capacidade de ver todas as solicitações conforme são geradas pelo seu aplicativo de console (supondo que o aplicativo gere solicitações da Web em vez de usar algum outro pipeline).

Se você quiser uma ferramenta mais poderosa (mas mais difícil de usar) que permita monitorar TODAS as solicitações recebidas, você deve verificar o WireShark.

Editar

Eu estou corrigido. Obrigado a Eric Law por postar as instruções para configurar o Fiddler para ser um proxy reverso !

Acabei de ter esse problema, o que funcionou para mim foi usar localhost.fiddler:

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

Consolidar as advertências mencionadas nos comentários / respostas para vários casos de uso.

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

• Inicie o Fiddler antes do seu aplicativo

• Em um aplicativo de console, talvez você não precise especificar proxyaddress:

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

• Em um aplicativo da web / algo hospedado no IIS, você precisa adicionar proxyaddress:

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

• Quando o .NET faz uma solicitação (por meio de um cliente de serviço ou HttpWebRequest, etc), ele sempre ignorará o proxy Fiddler para URLs que contenham localhost, então você deve usar um alias como o nome da máquina ou criar algo em seu arquivo 'hosts' (é por isso que algo parecido localhost.fiddlerou http://HOSTNAMEfunciona)

• Se você especificar o proxyaddress, deverá removê-lo de sua configuração se o Fiddler não estiver ativado ou qualquer solicitação que seu aplicativo fizer gerará uma exceção como:

  Nenhuma conexão pôde ser feita porque a máquina de destino a recusou ativamente 127.0.0.1:8888

• Não se esqueça de usar transformações de configuração para remover a seção de proxy na produção

Tão simples, tudo que você precisa é alterar o endereço no cliente de configuração: em vez de 'localhost', mude para o nome da máquina ou IP

Isso é simples se você tiver controle sobre o cliente que está enviando as comunicações. Tudo o que você precisa fazer é definir o HttpProxy na classe de serviço do lado do cliente.

Fiz isso, por exemplo, para rastrear um cliente de serviço da web em execução em um smartphone. Eu configurei o proxy nessa conexão do lado do cliente para o IP / porta do Fiddler, que estava sendo executado em um PC na rede. O aplicativo de smartphone então enviou toda a sua comunicação de saída para o serviço da web, por meio do Fiddler.

Funcionou perfeitamente.

Se o seu cliente for WCF, consulte estas perguntas e respostas para saber como definir o proxy.

Mesmo se você não tiver a capacidade de modificar o código do aplicativo do lado do cliente, pode ser capaz de definir o proxy administrativamente, dependendo da pilha de serviços da Web que seu cliente usa.

Rastreamento / diagnóstico de WCF padrão

Se por algum motivo você não conseguir fazer o Fiddler funcionar ou preferir registrar as solicitações de outra maneira, outra opção é usar a funcionalidade de rastreamento do WCF padrão. Isso produzirá um arquivo com um bom visualizador.

Docs

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

Configuração

Adicione o seguinte à sua configuração, certifique-se de que c:\logsexiste, reconstrua e faça solicitações:

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

Usei a ferramenta de tubarão de arame para monitorar chamadas de serviço do aplicativo silver light no navegador para o serviço. tente o link fornece informações claras

Ele permite que você monitore todo o conteúdo da solicitação e resposta.

Acabei de tentar a primeira resposta de Brad Rem e cheguei a esta configuração no web.config em BasicHttpBinding:

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

Espero que isso ajude alguém.

Você pode usar a versão gratuita do HTTP Debugger.

Não é um proxy e você não precisa fazer nenhuma alteração no web.config.

Além disso, pode mostrar ambos; solicitações HTTP de entrada e saída. Depurador HTTP grátis