複合型を受け入れ、いくつかのデータを返すWCFサービスがあります。 Fiddlerを使用して、サービスへの着信要求がどのように見えるかを確認します。クライアントは、サービス参照プロキシを使用する.netコンソールアプリです。これはFiddlerで可能ですか?このツールは初めてで、過去にリクエストビルダーでデータを投稿するためにのみ使用しました。
これをweb.configに追加する必要があります
<system.net>
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
それだけですが、フィドラーを閉じた後にweb.config行を削除することを忘れないでください。そうしないとエラーが発生します。
リファレンス: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy
Fiddlerはインバウンドリクエストではなくアウトバウンドリクエストをリッスンするため、Fiddlerを使用してサービスに着信するすべてのリクエストを監視することはできません。
Fiddlerで得られる最善の方法は、コンソールアプリによって生成されたすべてのリクエストを表示できることです(アプリが他のパイプラインを使用するのではなく、Webリクエストを生成すると仮定します)。
すべての着信要求を監視できる、より強力な(ただし使いにくい)ツールが必要な場合は、WireSharkをチェックアウトする必要があります。
編集
私は立ち直る。 Fiddlerをリバースプロキシとして設定する !への指示を投稿してくれたEric Lawに感謝します。
この問題が発生したとき、localhost.fiddlerを使用することでうまくいきました。
<endpoint address="http://localhost.fiddler/test/test.svc"
binding="basicHttpBinding"
bindingConfiguration="customBinding"
contract="test"
name="customBinding"/>
いくつかのユースケースのコメント/回答に記載されている警告を統合します。
ほとんどの場合、 http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp を参照してください
コンソールアプリでは、proxyaddress
を指定する必要がない場合があります。
<proxy bypassonlocal="False" usesystemdefault="True" />
Webアプリケーション/ IISでホストされているものでは、proxyaddress
を追加する必要があります。
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
HttpWebRequest
などを介して)要求を行うと、localhost
を含むURLのFiddlerプロキシを常にバイパスするため、マシン名などのエイリアスを使用するか、何かを構成する必要があります。 'hosts'ファイル内(これがlocalhost.fiddler
またはhttp://HOSTNAME
のようなものが機能する理由です)proxyaddress
を指定した場合、Fiddlerがオンになっていない場合は構成から削除する必要があります。そうしないと、アプリからのリクエストで次のような例外がスローされます。
ターゲットマシンがアクティブに拒否したため、接続できませんでした127.0.0.1:8888
とても簡単で、必要なのは設定クライアントのアドレスを変更することだけです:「localhost」の代わりにマシン名またはIPに変更します
標準のWCFトレース/診断
何らかの理由でFiddlerを動作させることができない場合、またはリクエストを別の方法で記録する場合、別のオプションは標準のWCFトレース機能を使用することです。これにより、Nice Viewerを持つファイルが作成されます。
ドキュメント
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>
通信を送信しているクライアントを制御できる場合、これは簡単です。必要なのは、クライアント側のサービスクラスでHttpProxyを設定することだけです。
たとえば、スマートフォンで実行されているWebサービスクライアントをトレースするためにこれを行いました。ネットワーク上のPCで実行されていたFiddlerのIP /ポートへのクライアント側接続にプロキシを設定しました。その後、スマートフォンアプリは、Fiddlerを介してすべての発信通信をWebサービスに送信しました。
これは完全に機能しました。
クライアントがWCFクライアントの場合、プロキシの設定方法については this Q&A をご覧ください。
クライアント側アプリのコードを変更する機能がない場合でも、クライアントが使用するWebサービススタックによっては、管理上プロキシを設定できる場合があります。
ブラウザのシルバーライトアプリからサービスへのサービスコールを監視するためにWire sharkツールを使用しました。 link を試してください
これにより、要求と応答の内容全体を監視できます。
私はBrad Remから最初の答えを試したところ、web.configのBasicHttpBindingでこの設定に到達しました。
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
...
</basicHttpBinding>
</bindings>
...
<system.serviceModel>
これが誰かを助けることを願っています。