Incompatibilidade de ContractFilter na exceção EndpointDispatcher

Tenho o seguinte cenário que estou tentando testar:

1. Um WSDL comum
2. Endpoint WCF que implementa objetos com base no WSDL e está hospedado no IIS.
3. Um aplicativo cliente que usa um proxy baseado no WSDL para criar solicitações.

Quando faço uma chamada de serviço da web do cliente para o terminal de serviço, recebo a seguinte exceção:

{"A mensagem com a ação ' http: // IMyService / CreateContainer ' não pode ser processada no destinatário, devido a uma incompatibilidade de ContractFilter no EndpointDispatcher. Isso pode ser devido a uma incompatibilidade de contrato (ações incompatíveis entre remetente e destinatário) ou um incompatibilidade de ligação / segurança entre o remetente e o destinatário. Verifique se o remetente e o destinatário têm o mesmo contrato e a mesma vinculação (incluindo requisitos de segurança, por exemplo, Mensagem, Transporte, Nenhum). "}

Comecei a usar o MS Service Trace Viewer, mas não tenho certeza de onde procurar. Ao observar as classes no cliente e no terminal, elas parecem idênticas.

Como começar a depurar esse problema?

Quais são algumas das possíveis causas para essa exceção?

Uma "incompatibilidade de ContractFilter no EndpointDispatcher" significa que o receptor não pôde processar a mensagem porque ela não correspondia a nenhum dos contratos que o receptor configurou para o terminal que recebeu a mensagem.

Isso pode ser porque:

• Você tem contratos diferentes entre o cliente e o remetente.
• Você está usando uma ligação diferente entre cliente e remetente.
• As configurações de segurança da mensagem não são consistentes entre o cliente e o remetente.

Dê uma olhada na EndpointDispatcheraula para mais informações sobre o assunto.

Assim:

Certifique-se de que seus contratos de cliente e servidor coincidam.

• Se você gerou seu cliente a partir de um WSDL, o WSDL está atualizado?
• Se você fez uma alteração recente no contrato, implantou a versão correta do cliente e do servidor?
• Se você tiver criado suas classes de contrato de cliente manualmente, certifique-se de que os namespaces, nomes de elementos e nomes de ação correspondam aos esperados pelo servidor.

Verifique se as ligações são iguais entre o cliente e o servidor.

• Se você estiver usando um arquivo .config para gerenciar seus terminais, certifique-se de que os elementos de ligação sejam correspondentes.

Verifique se as configurações de segurança são iguais entre o cliente e o servidor.

• Se você estiver usando um arquivo .config para gerenciar seus endpoints, certifique-se de que os elementos de segurança correspondem.

Eu tive esse erro e ele foi causado pelo contrato do receptor não implementando o método que está sendo chamado. Basicamente, alguém não implantou a versão mais recente do serviço WCF no servidor host.

Você também obterá isso se tentar se conectar ao URL errado ;)

Tenho dois pontos de extremidade e serviços definidos em meu sistema, com nomes semelhantes.

Recebi este erro exato quando as URLs foram trocadas em meu cliente em algum ponto. Coçou a cabeça de verdade até finalmente descobrir esse erro idiota.

Tive este problema e descobri que no meu gerador de proxy, que copiei de outro serviço, esqueci de mudar o nome do serviço.

Eu mudei isso ...

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

para...

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

Foi um erro de código simples, mas quase impossível de depurar. Espero que isso economize o tempo de alguém.

Para um cliente Java chamando um terminal .net. Isso foi causado pela incompatibilidade do cabeçalho Soap Action.

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

O cabeçalho HTTP acima ou a tag XML a seguir precisa corresponder à ação / método que você está tentando chamar.

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

Resolvi isso adicionando o seguinte à implementação do meu contrato:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Por exemplo:

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

}

Eu consegui isso depois de copiar o arquivo svc e renomeá-lo. Embora o nome do arquivo e o arquivo svc.cs tenham sido renomeados corretamente, a marcação ainda fazia referência ao arquivo original.

Para corrigir isso, clique com o botão direito do mouse no arquivo svc copiado e escolha Exibir marcação e altere a referência de serviço.

Conforme mencionado em outras respostas, como @chinto, isso acontece quando o elemento de cabeçalho SOAP: Action não corresponde ao Endpoint.

Você pode encontrar o URI correto a ser usado observando o WSDL do servidor. Você verá um elemento de operação com um filho de entrada que possui um atributo "Action". Isso é o que o seu SOAP: Ação precisa estar na solicitação do cliente.

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

Eu tive o mesmo problema. O problema é que copiei o código de outro serviço como ponto de partida e não alterei a classe de serviço no arquivo .svc

Abra o arquivo .svc e verifique se o atributo Service está correto.

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

O erro diz que há uma incompatibilidade, supondo que você tenha um contrato comum com base no mesmo WSDL, a incompatibilidade está na configuração.

Por exemplo, se o cliente está usando nettcpip e o servidor está configurado para usar http básico.

Eu tive um erro semelhante. Isso pode ser porque você teria alterado alguma configuração de contrato em seu arquivo de configuração depois que ele foi referenciado em seu projeto. solução - Atualize a referência do serviço da web em seu projeto VSstudio ou crie um novo proxy usando svcutil.exe

Esse erro geralmente ocorre se o código não for implantado corretamente.

No meu caso, tenho dois serviços ServiceA e ServiceB. Achei o problema de que os arquivos ServiceB não foram implantados corretamente. Por isso, quando o ServiceA estava chamando o ServiceB internamente, ele apresentava o erro abaixo.

Certifique-se de que os arquivos e referências sejam implantados corretamente.

Passei dias procurando a resposta e a encontrei, mas não neste tópico. Sou muito novo no WCF e no C #, então, para alguns, a resposta pode ser óbvia.

Na minha situação, eu tinha uma ferramenta cliente que foi originalmente desenvolvida para o serviço ASMX e, para mim, ela estava retornando a mesma mensagem de erro.

Depois de tentar todos os tipos de recomendações, encontrei este site:

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

Isso me colocou no caminho certo. Especificamente "soap: operation" - o WCF estava acrescentando ServiceName ao namespace:

cliente esperado Http://TEST.COM/Login, mas WCF enviado Http://TEST.COM/IService1/Login. A solução é adicionar configurações [OperationContract]como esta:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignore os espaços em branco em Http)

Isso pode ser por 2 motivos:

1. a referência de serviço está desatualizada, clique com o botão direito do mouse em referência de serviço n atualize-a

2. contrato que você implementou pode ser diferente do cliente. Compare os dois serviços n contrato do cliente n conserte a incompatibilidade dos contratos.

Se você estiver chamando o método WCF, deverá incluir a interface no cabeçalho.

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

Também pode ser útil para aqueles que estão fazendo isso por meio da codificação. Você precisa adicionar WebHttpBehavior () ao ponto de extremidade de serviço adicionado. Algo como:

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

Dê uma olhada em: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Bobagem, mas esqueci de adicionar [OperationContract]à minha interface de serviço (aquela marcada com [ServiceContract]) e você também obterá este erro.

Seu cliente não foi atualizado. Portanto, atualize seus serviços a partir do serviço da Web e reconstrua seu projeto

Eu tive esse problema também. Descobriu-se que era causado pelo serializador de contrato no lado do servidor. Ele não pôde retornar meu objeto de contrato de dados porque alguns de seus membros de dados eram propriedades somente leitura .

Certifique-se de que seus objetos tenham configuradores para propriedades destinadas a serem serializadas.

Estranhamente, contornamos esse erro usando a mesma caixa do nome Path e OperationContract usados. Aparentemente, era sensível a maiúsculas e minúsculas. Se alguém souber por quê, por favor comente. Obrigado!

Então, meu caso foi o seguinte. Eu não usei proxy para a interação cliente-servidor, usei ChannelFactory (portanto, todos os conselhos para atualizar a referência de serviço não fizeram sentido para mim).

O serviço estava hospedado no IIS e, por algum motivo, tinha referências erradas na pasta bin lá. A recompilação do projeto simplesmente não levou a novas dlls nessa pasta.

Então, apaguei todo o material de lá e adicionei referência ao serviço na mesma solução, depois recompilei e agora tudo funciona.

Meu problema acabou sendo algo raro, mas vou mencioná-lo de qualquer maneira.

Eu encontrei o problema de implantação em nosso ambiente de desenvolvimento. Nessa máquina, nosso responsável pela construção criou duas pastas (implantou dois aplicativos). Uma versão antiga e a nova versão atual. Portanto, se você não tiver duas versões de seu aplicativo no servidor da web, isso não se aplica a você.

O novo local que ele criou tinha um nome diferente do padrão como a primeira parte do url após o host:

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

Em minha máquina local, meu cliente estava apontando para o nome da pasta padrão conforme configurado em todos os ambientes (exceto desenvolvimento), incluindo meu ambiente local.

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

Quando eu perdi o controle e substituí o web.config no desenvolvimento pela minha cópia local, a parte da url que precisava ser especial foi perdida com a parte padrão, então, como resultado, o cliente no dev apontou para o aplicativo antigo.

O aplicativo antigo tinha um contrato antigo, não entendia a solicitação e gerava esse erro.

Tive o mesmo erro em um serviço WCF implantado, o problema estava relacionado a outro serviço implantado com outro contrato com a mesma porta.

Solução

Usei portas diferentes no web.config e o problema desapareceu.

Serviço 1

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

Serviço 2

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

Além disso , me deparei com essa situação usando uma porta diferente para o mesmo endereço entre o serviço e o consumidor.

Tive este erro porque tenho uma versão antiga da DLL no GAC do meu servidor. Portanto, verifique se tudo está referenciado corretamente e se o assembly / GAC está atualizado com a dll em boas condições.

Tive esse problema com meu servidor de teste, porque estava executando duas cópias do mesmo wcf no mesmo pool de aplicativos. O que resolveu para mim foi criar pools separados para cada versão no meu wcf e reiniciar o IIS depois disso.

Para aqueles que estão usando NodeJS com axios para fazer as solicitações SOAP, você deve incluir a SOAPAction header. Veja o exemplo abaixo:

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