Mancata corrispondenza di ContractFilter nell'eccezione EndpointDispatcher

Ho il seguente scenario che sto cercando di testare:

1. Un WSDL comune
2. Endpoint WCF che implementa oggetti basati su WSDL ed è ospitato in IIS.
3. Un'app client che utilizza un proxy basato su WSDL per creare richieste.

Quando effettuo una chiamata al servizio Web dal client all'endpoint del servizio, ottengo la seguente eccezione:

{"Il messaggio con azione" http: // IMyService / CreateContainer "non può essere elaborato nel destinatario, a causa di una mancata corrispondenza di ContractFilter in EndpointDispatcher. Ciò può essere dovuto a una mancata corrispondenza del contratto (azioni non corrispondenti tra mittente e destinatario) o a mancata corrispondenza vincolante / di sicurezza tra il mittente e il destinatario. Verifica che mittente e destinatario abbiano lo stesso contratto e la stessa associazione (inclusi i requisiti di sicurezza, ad es. messaggio, trasporto, nessuno). "}

Ho iniziato a utilizzare MS Service Trace Viewer, ma non so dove cercare. Osservando le classi nel client e nell'endpoint, appaiono identiche.

Come si inizia a eseguire il debug di questo problema?

Quali sono alcune possibili cause di questa eccezione?

Una "mancata corrispondenza di ContractFilter in EndpointDispatcher" significa che il destinatario non è stato in grado di elaborare il messaggio perché non corrispondeva a nessuno dei contratti che il destinatario ha configurato per l'endpoint che ha ricevuto il messaggio.

Ciò può essere dovuto a:

• Hai contratti diversi tra cliente e mittente.
• Stai utilizzando un'associazione diversa tra client e mittente.
• Le impostazioni di sicurezza dei messaggi non sono coerenti tra client e mittente.

Dai un'occhiata alla EndpointDispatcherclasse per ulteriori informazioni sull'argomento.

Così:

Assicurati che i tuoi contratti client e server corrispondano.

• Se hai generato il tuo client da un WSDL, il WSDL è aggiornato?
• Se hai apportato una modifica recente al contratto, hai distribuito la versione corretta sia del client che del server?
• Se hai creato manualmente le classi del contratto client, assicurati che gli spazi dei nomi, i nomi degli elementi e i nomi delle azioni corrispondano a quelli previsti dal server.

Verificare che i collegamenti siano gli stessi tra client e server.

• Se stai utilizzando un file .config per gestire i tuoi endpoint, assicurati che gli elementi di associazione corrispondano.

Verificare che le impostazioni di sicurezza siano le stesse tra client e server.

• Se stai usando un file .config per gestire i tuoi endpoint, assicurati che gli elementi di sicurezza corrispondano.

Ho riscontrato questo errore ed è stato causato dal contratto di ricezione che non implementava il metodo chiamato. Fondamentalmente, qualcuno non aveva distribuito l'ultima versione del servizio WCF sul server host.

Lo otterrai anche se provi a connetterti all'URL sbagliato ;)

Ho due endpoint e servizi definiti nel mio sistema, con nomi simili.

Ho ricevuto questo errore esatto quando gli URL sono stati scambiati sul mio client a un certo punto. Mi sono davvero grattato la testa finché non ho finalmente capito questo stupido errore.

Ho avuto questo problema e ho scoperto che nel mio generatore di proxy, che ho copiato da un altro servizio, ho dimenticato di cambiare il nome del servizio.

Ho cambiato questo ...

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

per...

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

È stato un semplice errore di codice, ma quasi impossibile da eseguire il debug. Spero che questo faccia risparmiare tempo a qualcuno.

Per un client Java che chiama un endpoint .net. Ciò è stato causato da una mancata corrispondenza dell'intestazione Soap Action.

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

L'intestazione HTTP sopra o il seguente tag XML deve corrispondere all'azione / metodo che stai tentando di invocare.

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

Ho risolto questo problema aggiungendo quanto segue all'implementazione del mio contratto:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Per esempio:

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

}

L'ho ottenuto dopo aver copiato il file svc e rinominato. Sebbene il nome del file e il file svc.cs siano stati rinominati correttamente, il markup faceva ancora riferimento al file originale.

Per risolvere questo problema, fai clic con il pulsante destro del mouse sul file svc copiato e scegli Visualizza markup e modifica il riferimento al servizio.

Come accennato in altre risposte, come @chinto, ciò accade quando l'elemento SOAP: Action header non corrisponde all'endpoint.

È possibile trovare l'URI corretto da utilizzare guardando il WSDL del server. Vedrai un elemento operazione con un input figlio che ha un attributo "Action". Questo è ciò che il tuo SOAP: l'azione deve essere eseguita sulla richiesta del client.

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

Ho avuto lo stesso problema. Il problema era che ho copiato il codice da un altro servizio come punto di partenza e non ho modificato la classe del servizio nel file .svc

Apri il file .svc e assicurati che l'attributo Service sia corretto.

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

L'errore dice che c'è una mancata corrispondenza, supponendo che tu abbia un contratto comune basato sullo stesso WSDL, quindi la mancata corrispondenza è nella configurazione.

Ad esempio, il client utilizza nettcpip e il server è impostato per utilizzare http di base.

Ho avuto un errore simile. Ciò potrebbe essere dovuto al fatto che avresti modificato alcune impostazioni del contratto sul tuo file di configurazione dopo che è stato aggiornato nel tuo progetto. soluzione: aggiorna il riferimento del servizio web sul tuo progetto VSstudio o crea un nuovo proxy utilizzando svcutil.exe

Questo errore si verifica generalmente se il codice non viene distribuito correttamente.

Nel mio caso, ho due servizi ServiceA e ServiceB. Ho riscontrato il problema che i file ServiceB non sono stati distribuiti correttamente. Per questo motivo, quando ServiceA chiamava ServiceB internamente, stava dando l'errore di seguito.

Assicurati che i file e i riferimenti siano distribuiti correttamente.

Ho passato giorni a cercare la risposta e l'ho trovata, ma non in questo thread. Sono molto nuovo in WCF e C #, quindi per alcuni la risposta potrebbe essere ovvia.

Nella mia situazione avevo uno strumento client che era stato originariamente sviluppato per il servizio ASMX e per me restituiva lo stesso messaggio di errore.

Dopo aver provato tutti i tipi di consigli, ho trovato questo sito:

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

Mi ha messo sulla strada giusta. Nello specifico "soap: operation" - WCF aggiungeva ServiceName allo spazio dei nomi:

client previsto Http://TEST.COM/Login, ma WCF inviato Http://TEST.COM/IService1/Login. La soluzione è aggiungere un'impostazione in [OperationContract]questo modo:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignora gli spazi vuoti in Http)

Ciò potrebbe essere dovuto a 2 motivi:

1. rif servizio è obsoleto, fare clic con il pulsante destro del mouse rif servizio n aggiornarlo.

2. contratto che hai implementato potrebbe essere diverso da quello che ha il cliente. Confronta entrambi i servizi n contratto cliente n correggi la mancata corrispondenza dei contratti.

Se stai chiamando il metodo WCF, dovresti includere l'interfaccia in Header.

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+ "\"");
}

Inoltre potrebbe essere utile per coloro che lo stanno facendo codificando. È necessario aggiungere WebHttpBehavior () all'endpoint del servizio aggiunto. Qualcosa di simile a:

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

Dai un'occhiata a: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Sciocco, ma ho dimenticato di aggiungere [OperationContract]alla mia interfaccia di servizio (quella contrassegnata con [ServiceContract]) e quindi ottieni anche questo errore.

Il tuo client non è stato aggiornato Quindi aggiorna i tuoi servizi dal servizio Web e poi ricostruisci il tuo progetto

Anch'io ho avuto questo problema. Si è scoperto che era causato dal serializzatore del contratto sul lato server. Non poteva restituire il mio oggetto contratto dati perché alcuni dei suoi datamembers erano proprietà di sola lettura .

Assicurati che i tuoi oggetti abbiano setter per le proprietà destinate ad essere serializzate.

Stranamente abbiamo aggirato questo errore utilizzando lo stesso case del percorso e il nome OperationContract utilizzati. Apparentemente faceva distinzione tra maiuscole e minuscole. Se qualcuno sa perché, per favore commenta. Grazie!

Quindi, il mio caso era il seguente. Non ho usato il proxy per l'interazione client-server, ho usato ChannelFactory (quindi tutti i consigli per l'aggiornamento a riferimento del servizio erano privi di significato per me).

Il servizio era ospitato in IIS e per qualche motivo aveva riferimenti errati nella cartella bin. La ricompilazione del progetto semplicemente non ha portato a nuove DLL in quella cartella.

Quindi ho appena cancellato tutte le cose da lì e aggiunto il riferimento al servizio nella stessa soluzione, quindi ho ricompilato e ora tutto funziona.

Il mio problema si è rivelato raro, ma lo menzionerò comunque.

Ho riscontrato il problema durante la distribuzione nel nostro ambiente di sviluppo. Su quella macchina, il nostro addetto alla compilazione aveva creato due cartelle (distribuito due applicazioni). Una vecchia versione e la nuova versione attuale.Quindi, se non hai due versioni della tua applicazione sul server web, questo non si applica a te.

La nuova posizione che ha creato aveva un nome non standard come prima parte dell'URL dopo l'host:

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

Sulla mia macchina locale, il mio client puntava al nome della cartella standard come era stato impostato su tutti gli ambienti (eccetto lo sviluppo), incluso il mio ambiente locale.

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

Quando sono rimasto senza parole e ho sostituito web.config durante lo sviluppo con la mia copia locale, la parte dell'URL che doveva essere speciale è stata spazzata via con la parte standard, quindi il client su dev ha puntato alla vecchia applicazione.

La vecchia applicazione aveva un vecchio contratto e non capiva la richiesta e generava questo errore.

Ho avuto lo stesso errore su un servizio WCF distribuito, il problema era correlato a un altro servizio distribuito con un altro contratto con la stessa porta.

Soluzione

Ho usato diverse porte nel web.config e il problema è scomparso.

Servizio 1

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

Servizio 2

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

Inoltre , mi sono imbattuto in questa situazione utilizzando una porta diversa per lo stesso indirizzo tra il servizio e il consumatore.

Ho riscontrato questo errore perché ho una vecchia versione della DLL nella GAC ​​del mio server. Quindi assicurati che tutto sia referenziato correttamente e che l'assembly / GAC sia aggiornato con la buona dll.

Ho avuto questo problema sul mio server di prova, perché stavo eseguendo due copie dello stesso wcf sullo stesso pool di app. Quello che ha risolto per me è stato creare pool separati per ogni versione sul mio wcf e riavviare IIS dopo questo.

Per coloro che utilizzano NodeJS con axios per effettuare le richieste SOAP è necessario includere un file SOAPAction header. Controlla l'esempio di seguito:

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