2

これが取り引きです: SOAP クライアントを介して Web サービスを呼び出すクラス ライブラリがあります。コンソール アプリケーション内から呼び出すと、正常に動作します。http 呼び出しによって呼び出される WCF サービス内から呼び出されると、「EndpointNotFoundException -メッセージを受け入れることができるhttp://blablabla.asmxでリッスンしているエンドポイントがありませんでした。これは多くの場合、アドレスまたは SOAP アクションが正しくないことが原因です。 ...」

app.config と web.config の両方に、クライアント エンドポイントのまったく同じ構成が含まれています。

どうしたの？ちなみに、WCF は Visual Studio からローカルで実行されています。呼び出しようとしている SOAP Web サービスは、インターネット上にあります。

これは、サービス モデルの構成がどのように見えるかです。基本認証を使用し、ユーザーとパスワードはクラス ライブラリのコードで設定されています。

<system.serviceModel>
<bindings>
  <basicHttpBinding>
    <binding name="VocalServerSoap">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://pseudourl.asmx"
    binding="basicHttpBinding" bindingConfiguration="VocalServerSoap"
    contract="VocalWebService.VocalServerSoap" name="VocalServerSoap" />
</client>

建築

4

2 に答える 2

3

うーん....欲求不満！許可の問題として突き止めたと思った後（以前の投稿に従って）、タイムアウトの同じ動作に戻りました。

最終的にはすべてプロキシが原因です....（msdn から）次のことがわかります：

NT サービスとして、または ASP.NET の一部として実行されているアプリケーションは、呼び出し元のユーザーの Internet Explorer プロキシ サーバー設定 (利用可能な場合) を使用します。これらの設定は、すべてのサービス アプリケーションで使用できるわけではありません。

そのため、WCF サービス内から呼び出された SOAP サービスへの私の要求には、プロキシがまったく構成されていませんでした...したがって、エンドポイントの例外はありません。

これを克服するには、soap クライアント バインディングでプロキシを手動で宣言する必要がありました。

<binding name="VocalServerSoap" proxyAddress="http://<your proxy address>:<proxy port>"
      useDefaultWebProxy="false">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" />
      </security>
    </binding>

では、なぜ私はそれが許可だと思ったのですか? 時々それが機能していたのはなぜですか？さて、フィドラーは私に本当の混乱を引き起こしました....フィドラーをアクティブにすると、フィドラーがシステムプロキシを使用していたため、すべての発信要求がプロキシに正しくルーティングされたため、すべてが機能しました。

これが私の人生のほぼ一日を無駄にしたなんて信じられない:(

于 2013-10-09T18:47:48.783 に答える