EndpointDispatcher例外でのContractFilterの不一致

私がテストしようとしている次のシナリオがあります：

1. 一般的なWSDL
2. WSDLに基づいてオブジェクトを実装し、IISでホストされるWCFエンドポイント。
3. WSDLに基づくプロキシを使用してリクエストを作成するクライアントアプリ。

クライアントからサービスエンドポイントへのWebサービス呼び出しを行うと、次の例外が発生します。

{「EndpointDispatcherでのContractFilterの不一致が原因で、アクション ' http：// IMyService / CreateContainer ' のメッセージを受信側で処理できません。これは、コントラクトの不一致（送信者と受信者のアクションの不一致）または送信者と受信者の間のバインディング/セキュリティの不一致。送信者と受信者が同じコントラクトと同じバインディングを持っていることを確認してください（メッセージ、トランスポート、なしなどのセキュリティ要件を含む）。 "}

MS Service Trace Viewerを使い始めましたが、どこを見ればよいかわかりません。クライアントとエンドポイントのクラスを見ると、同じように見えます。

どのようにしてこの問題をデバッグし始めますか？

この例外の考えられる原因は何ですか？

「EndpointDispatcherでのContractFilterの不一致」は、メッセージを受信したエンドポイントに対して受信者が設定したどのコントラクトとも一致しなかったため、受信者がメッセージを処理できなかったことを意味します。

次の理由が考えられます。

• クライアントと送信者の契約が異なります。
• クライアントと送信者の間で異なるバインディングを使用しています。
• メッセージのセキュリティ設定は、クライアントと送信者の間で一貫していません。

EndpointDispatcher主題の詳細については、クラスをご覧ください。

そう：

クライアントとサーバーのコントラクトが一致していることを確認してください。

• WSDLからクライアントを生成した場合、WSDLは最新ですか？
• 契約に最近変更を加えた場合、クライアントとサーバーの両方の適切なバージョンを展開しましたか？
• クライアントコントラクトクラスを手作りした場合は、名前空間、要素名、アクション名がサーバーで想定されているものと一致することを確認してください。

バインディングがクライアントとサーバー間で同じであることを確認してください。

• .configファイルを使用してエンドポイントを管理している場合は、バインディング要素が一致していることを確認してください。

クライアントとサーバーの間でセキュリティ設定が同じであることを確認します。

• .configファイルを使用してエンドポイントを管理している場合は、セキュリティ要素が一致していることを確認してください。

このエラーが発生しました。これは、呼び出されているメソッドを実装していない受信者コントラクトによって引き起こされました。基本的に、誰かがWCFサービスの最新バージョンをホストサーバーに展開していませんでした。

間違ったURLに接続しようとすると、これも表示されます ;）

私のシステムには、似た名前の2つのエンドポイントとサービスが定義されています。

ある時点でクライアントでURLが交換されたときに、この正確なエラーが発生しました。最終的にこの愚かな間違いを理解するまで、本当に頭を掻きました。

この問題が発生し、別のサービスからコピーしたプロキシジェネレーターで、サービスの名前を変更するのを忘れていました。

これを変更しました...

Return New Service1DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service1Data.svc"))

に...

Return New Service2DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service2Data.svc"))

単純なコードエラーでしたが、デバッグするのはほとんど不可能でした。これが誰かの時間の節約になることを願っています。

.netエンドポイントを呼び出すJavaクライアントの場合。これは、Soap Actionヘッダーの不一致が原因でした。

Content-Type: application/soap+xml;charset=UTF-8;action="http://example.org/ExampleWS/exampleMethod"

上記のHTTPヘッダーまたは次のXMLタグは、呼び出そうとしているアクション/メソッドと一致する必要があります。

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/" xmlns:gen="http://schemas.datacontract.org/2004/07/GenesysOnline.WCFServices">
   <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsa:To>https://example.org/v1/Service.svc</wsa:To>
      <wsa:Action>http://example.org/ExampleWS/exampleMethod</wsa:Action>
   </soap:Header>
   <soap:Body>
    ...
   </soap:Body>
</soap:Envelope>

これを解決するには、契約の実装に以下を追加します。

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

例えば：

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class MyUploadService : IMyUploadService
{

}

私はsvcファイルをコピーして名前を変更した後にこれを取得しました。ファイル名とsvc.csファイルの名前は正しく変更されましたが、マークアップは引き続き元のファイルを参照していました。

これを修正するには、コピーしたsvcファイルを右クリックし、[マークアップの表示]を選択して、サービス参照を変更します。

@chintoなどの他の回答で述べたように、これはSOAP：Actionヘッダー要素がエンドポイントと一致しない場合に発生します。

サーバーのWSDLを確認することで、使用する正しいURIを見つけることができます。「アクション」属性を持つ入力子を持つ操作要素が表示されます。それが、SOAP：Actionがクライアント要求に必要なものです。

<wsdl:operation name="MethodName">
<wsdl:input wsaw:Action="http://tempuri.org/IInterface/MethodName" message="tns:IInterface_MethodName_InputMessage"/>
<wsdl:output wsaw:Action="http://tempuri.org/IInterface/MethodNameResponse" message="tns:IInterface_MethodName_OutputMessage"/>
</wsdl:operation>

同じ問題がありました。問題は、開始点として別のサービスからコードをコピーし、.svcファイルのサービスクラスを変更しなかったことでした。

.svcファイルを開き、Service属性が正しいことを確認します。

 <%@ ServiceHost Language="C#" Debug="true" Service="SME.WCF.ApplicationServices.ReportRenderer" CodeBehind="ReportRenderer.svc.cs" %>

エラーは、同じWSDLに基づく共通コントラクトがあると想定して、不一致があることを示しており、不一致は構成にあります。

たとえば、クライアントがnettcpipを使用しており、サーバーが基本的なhttpを使用するように設定されているとします。

同様のエラーが発生しました。これは、プロジェクトに反映された後、構成ファイルの契約設定を変更したことが原因である可能性があります。解決策-VSstudioプロジェクトのWebサービス参照を更新するか、svcutil.exeを使用して新しいプロキシを作成します

このエラーは通常、コードが適切にデプロイされていない場合に発生します。

私の場合、ServiceAとServiceBという2つのサービスがあります。ServiceBファイルが適切に展開されないという問題が見つかりました。そのため、ServiceAが内部でServiceBを呼び出していたため、以下のエラーが発生していました。

ファイルと参照が適切にデプロイされていることを確認してください。

私は答えを探すために何日も費やしましたが、それを見つけましたが、このスレッドでは見つかりませんでした。私はWCFとC＃に非常に慣れていないので、一部の人にとっては答えが明白かもしれません。

私の状況では、元々ASMXサービス用に開発されたクライアントツールがあり、同じエラーメッセージを返していました。

あらゆる種類の推奨事項を試した後、私はこのサイトを見つけました：

http://myshittycode.com/2013/10/01/the-message-with-action-cannot-be-processed-at-the-receiver-due-to-a-contractfilter-mismatch-at-the-endpointdispatcher/

それは私を正しい道に導きました。具体的には、「soap：operation」-WCFは名前空間にServiceNameを追加していました。

クライアントは予期Http://TEST.COM/Loginしましたが、WCFが送信しましたHttp://TEST.COM/IService1/Login。解決策は次のように設定を追加すること[OperationContract]です：

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] （HTTPの空白は無視してください）

これには2つの理由が考えられます。

1. サービス参照が古くなっています。右クリックしてサービス参照を更新してください。

2. 実装した契約は、クライアントの契約とは異なる場合があります。両方のサービスnクライアント契約を比較して、契約の不一致を修正してください。

WCFメソッドを呼び出す場合は、ヘッダーにインターフェイスを含める必要があります。

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(Url);
if (Url.Contains(".svc"))
{
    isWCFService = true;
    req.Headers.Add("SOAPAction", "http://tempuri.org/WCF_INterface/GetAPIKeys");
}
else 
{
    req.Headers.Add("SOAPAction", "\"http://tempuri.org/" + asmxMethodName+ "\"");
}

また、コーディングでこれを行っている人にも役立つかもしれません。追加したサービスエンドポイントにWebHttpBehavior（）を追加する必要があります。何かのようなもの：

restHost.AddServiceEndpoint(typeof(IRestInterface), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior()); 

見てください：https : //docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

ばかげ[OperationContract]ていますが、サービスインターフェイス（でマークされているもの[ServiceContract]）に追加するのを忘れたため、このエラーも発生しました。

クライアントは更新されていません。Webサービスからサービスを更新してから、プロジェクトを再構築してください

私にもこの問題がありました。サーバー側の契約シリアライザが原因であることが判明しました。データメンバーの一部が読み取り専用プロパティだったため、データコントラクトオブジェクトを返すことができませんでした。

オブジェクトに、シリアル化するためのプロパティのセッターがあることを確認してください。

奇妙なことに、PathとOperationContractの名前と同じケーシングを使用して、このエラーを回避しました。どうやら大文字と小文字が区別されたようです。誰かが理由を知っている場合は、コメントしてください。ありがとうございました！

だから、私の場合は次のとおりでした。クライアントとサーバーの対話にプロキシを使用せず、ChannelFactoryを使用しました（したがって、サービス参照にアップグレードするためのすべてのアドバイスは私には無意味でした）。

サービスはIISでホストされていて、何らかの理由で、そこのbinフォルダーに誤った参照がありました。プロジェクトを再コンパイルしても、そのフォルダーに新しいDLLが作成されることはありませんでした。

だから私はそこからすべてのものを削除し、同じソリューションでサービスへの参照を追加し、再コンパイルしてすべてが機能するようになりました。

私の問題は珍しいものであることが判明しましたが、とにかくそれについて触れます。

開発環境にデプロイする際に問題が発生しました。そのマシンでは、ビルド担当者が2つのフォルダーを作成しました（2つのアプリケーションをデプロイしました）。古いバージョンと新しい現在のバージョン。したがって、Webサーバーにアプリケーションの2つのバージョンがない場合、これは当てはまりません。

彼が作成した新しい場所には、ホストの後のURLの最初の部分として非標準の名前がありました。

net.tcp://dev.umbrellacorp.com/DifferentFolderName/MyProvider

ローカルマシンでは、クライアントは、ローカル環境を含むすべての環境（開発を除く）でセットアップされた標準のフォルダー名を指しています。

net.tcp://dev.umbrellacorp.com/AppServices/MyProvider

開発時にweb.configを吹き飛ばしてローカルコピーで置き換えたところ、特別である必要があるURLの部分が標準部分で吹き飛ばされたため、開発者のクライアントが古いアプリケーションを指していました。

古いアプリケーションには古い契約があり、リクエストを理解できず、このエラーがスローされました。

デプロイされたWCFサービスで同じエラーが発生しました。問題は、同じポートを持つ別のコントラクトでデプロイされた別のサービスに関連していました。

解決

web.configで別のポートを使用したところ、問題は解決しました。

サービス1

contract="Service.WCF.Contracts.IBusiness1" 
baseAddress="net.tcp://local:5244/ServiceBusiness" 

サービス2

contract="Service.WCF.Contracts.IBusiness2"
baseAddress="net.tcp://local:5243/ServiceBusiness"

また、サービスとコンシューマーの間で同じアドレスに異なるポートを使用することで、この状況に遭遇しました。

サーバーのGACに古いバージョンのDLLがあるため、このエラーが発生しました。したがって、すべてが正しく参照され、アセンブリ/ GACが適切なDLLで最新であることを確認してください。

同じアプリケーションプールで同じwcfのコピーを2つ実行していたため、テストサーバーでこの問題が発生しました。私のために解決したのは、私のバージョンのwcfでバージョンごとに個別のプールを作成し、この後にIISを再起動することでした。

NodeJSを使用している人のためにaxiosは、 SOAPリクエストを作るためにあなたが含まれている必要がありますSOAPAction header。以下の例を確認してください。

axios.post('https://wscredhomosocinalparceria.facilinformatica.com.br/WCF/Soap/Emprestimo.svc?wsdl',
           xmls,
  {headers:
  {
    'Content-Type': 'text/xml',
    SOAPAction: 'http://schemas.facilinformatica.com.br/Facil.Credito.WsCred/IEmprestimo/CalcularPrevisaoDeParcelas'}
  }).then(res => {
    console.log(res)
  }).catch(err => {
    console.log(err.response.data)
  })