Как использовать Fiddler для мониторинга службы WCF

У меня есть служба WCF, которая принимает сложный тип и возвращает некоторые данные. Я хочу использовать Fiddler, чтобы посмотреть, как выглядят входящие запросы к сервису. Клиент - это консольное приложение .net, которое использует служебный прокси Service. Возможно ли это с Fiddler. Я новичок в этом инструменте и только использовал его в прошлом для публикации данных с помощью построителя запросов.

ОТВЕТЫ

Ответ 1

Вам нужно добавить это в свой web.config

<system.net>
  <defaultProxy>
    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>
  • затем запустите Fiddler на машине WEBSERVER.
  • Нажмите "Инструменты" | Опции Fiddler = > Подключения = > отрегулируйте порт как 8888. (разрешите удаленное, если вам это нужно)
  • Хорошо, тогда из меню файла запишите трафик.

Это все, но не забудьте удалить строки web.config после закрытия скрипача, потому что если вы этого не сделаете, это приведет к ошибке.

Ссылка: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy

Ответ 2

Fiddler прислушивается к исходящим запросам, а не входящим запросам, поэтому вы не сможете отслеживать все запросы, поступающие на вашу службу, используя Fiddler.

Лучшее, что вы собираетесь получить с Fiddler, - это возможность видеть все запросы по мере их создания в своем консольном приложении (при условии, что приложение генерирует веб-запросы, а не использует какой-либо другой конвейер).

Если вы хотите, чтобы инструмент был более мощным (но более сложным в использовании), который позволит вам отслеживать ВСЕ входящие запросы, вы должны проверить WireShark.

Edit

Я стою исправлено. Благодаря Eric Law для размещения инструкций настройка Fiddler как обратного прокси!

Ответ 3

Просто у меня была эта проблема, для меня работало localhost.fiddler:

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

Ответ 4

Консолидация оговорок, упомянутых в комментариях/ответах для нескольких случаев использования.

В основном, см. http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

  • Запустите Fiddler перед вашим приложением.

  • В консольном приложении вам может не потребоваться указать proxyaddress:

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

  • В веб-приложении/что-то, размещенном в IIS, вам нужно добавить proxyaddress:

    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
  • Когда .NET делает запрос (через клиент службы или HttpWebRequest и т.д.), он всегда будет обходить прокси-сервер Fiddler для URL-адресов, содержащих localhost, поэтому вы должны использовать псевдоним, например, имя машины или что-то сделать в ваш файл hosts (вот почему работает что-то вроде localhost.fiddler или http://HOSTNAME)

  • Если вы укажете proxyaddress, вы должны удалить его из своей конфигурации, если Fiddler не включен или какие-либо запросы вашего приложения будут выдавать исключение, например:

    Никакое соединение не может быть выполнено, потому что целевая машина активно отказалась от него. 127.0.0.1:8888

  • Не забудьте использовать конфигурационные преобразования, чтобы удалить раздел прокси-сервера в процессе производства

Ответ 5

Так просто, все, что вам нужно, это изменить адрес в конфигурационном клиенте: вместо "localhost" изменить имя компьютера или IP

Ответ 6

Это просто, если у вас есть контроль над клиентом, который отправляет сообщения. Все, что вам нужно сделать, - установить HttpProxy в клиентском классе обслуживания.

Я сделал это, например, для отслеживания клиента веб-службы, работающего на смартфоне. Я установил прокси-сервер на это клиентское соединение с IP/портом Fiddler, который запускался на ПК в сети. Затем приложение смартфона отправило всю свою исходящую связь в веб-службу через Fiddler.

Это сработало отлично.

Если ваш клиент является клиентом WCF, см. этот Q & A, как установить прокси.

Даже если у вас нет возможности изменять код клиентского приложения, вы можете установить прокси административно, в зависимости от стека веб-сервисов, который использует ваш клиент.

Ответ 7

Стандартная трассировка/диагностика WCF

Если по какой-либо причине вы не можете заставить Fiddler работать или предпочитаете регистрировать запросы другим способом, другой вариант - использовать стандартную функциональность трассировки WCF. Это создаст файл с хорошим средством просмотра.

Документы

Смотрите https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging

конфигурацииДобавьте следующее в вашу конфигурацию, убедитесь, что c:\logs существует, перестройте и сделайте запросы:

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

Ответ 8

Я использовал инструмент проводной акулы для мониторинга вызовов службы из приложения Silver Light в браузере для обслуживания. попробуйте ссылка дает четкую информацию

Он позволяет отслеживать весь контент запроса и ответа.

Ответ 9

Я только что попробовал первый ответ от Брэда Рема и пришел к этому параметру в web.config под BasicHttpBinding:

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

Надеюсь, это кому-нибудь поможет.

Ответ 10

Вы можете использовать бесплатную версию HTTP Debugger.

Это не прокси, и вам не нужно вносить какие-либо изменения в web.config.

Кроме того, он может показать оба; входящие и исходящие HTTP-запросы. HTTP Debugger Free