Как использовать 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