Discrepancia de ContractFilter en la excepción de EndpointDispatcher

Tengo el siguiente escenario que estoy tratando de probar:

1. Un WSDL común
2. Extremo de WCF que implementa objetos basados ​​en WSDL y está hospedado en IIS.
3. Una aplicación cliente que usa un proxy basado en WSDL para crear solicitudes.

Cuando hago una llamada de servicio web desde el cliente al punto final del servicio, obtengo la siguiente excepción:

{"El mensaje con la acción ' http: // IMyService / CreateContainer ' no se puede procesar en el receptor, debido a una discrepancia de ContractFilter en EndpointDispatcher. Esto puede deberse a una discrepancia de contrato (Acciones no coincidentes entre el remitente y el destinatario) o un incompatibilidad de vinculación / seguridad entre el remitente y el receptor. Verifique que el remitente y el receptor tengan el mismo contrato y la misma vinculación (incluidos los requisitos de seguridad, por ejemplo, Mensaje, Transporte, Ninguno). "}

Comencé a usar MS Service Trace Viewer, pero no estoy seguro de dónde buscar. Mientras mira las clases en el cliente y el punto final, parecen idénticas.

¿Cómo se empieza a depurar este problema?

¿Cuáles son algunas de las posibles causas de esta excepción?

Una "discrepancia de ContractFilter en el EndpointDispatcher" significa que el receptor no pudo procesar el mensaje porque no coincidía con ninguno de los contratos que el receptor ha configurado para el punto final que recibió el mensaje.

Esto puede deberse a que:

• Tienes diferentes contratos entre cliente y remitente.
• Estás utilizando un enlace diferente entre el cliente y el remitente.
• La configuración de seguridad de los mensajes no es coherente entre el cliente y el remitente.

Eche un vistazo a la EndpointDispatcherclase para obtener más información sobre el tema.

Entonces:

Asegúrese de que sus contratos de cliente y servidor coincidan.

• Si ha generado su cliente a partir de un WSDL, ¿el WSDL está actualizado?
• Si ha realizado un cambio reciente en el contrato, ¿ha implementado la versión correcta tanto del cliente como del servidor?
• Si ha creado a mano sus clases de contrato de cliente, asegúrese de que los espacios de nombres, los nombres de los elementos y los nombres de las acciones coincidan con los esperados por el servidor.

Compruebe que los enlaces sean los mismos entre el cliente y el servidor.

• Si está utilizando un archivo .config para administrar sus puntos finales, asegúrese de que los elementos de enlace coincidan.

Compruebe que la configuración de seguridad sea la misma entre el cliente y el servidor.

• Si está utilizando un archivo .config para administrar sus puntos finales, asegúrese de que los elementos de seguridad coincidan.

Tuve este error y fue causado por el contrato del receptor que no implementó el método que se llama. Básicamente, alguien no había implementado la última versión del servicio WCF en el servidor host.

También obtendrá esto si intenta conectarse a la URL incorrecta ;)

Tengo dos puntos finales y servicios definidos en mi sistema, con nombres similares.

Obtuve este error exacto cuando las URL se intercambiaron en mi cliente en algún momento. Realmente se rascó la cabeza hasta que finalmente descubrió este tonto error.

Tuve este problema y descubrí que en mi generador de proxy, que copié de otro servicio, olvidé cambiar el nombre del servicio.

Cambié esto ...

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

a...

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

Fue un simple error de código, pero casi imposible de depurar. Espero que esto le ahorre tiempo a alguien.

Para un cliente Java que llama a un punto final .net. Esto se debió a que el encabezado de Acción de jabón no coincide.

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

El encabezado HTTP anterior o la siguiente etiqueta XML deben coincidir con la acción / método que está intentando invocar.

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

Resolví esto agregando lo siguiente a la implementación de mi contrato:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Por ejemplo:

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

}

Obtuve esto después de copiar el archivo svc y cambiarle el nombre. Aunque el nombre del archivo y el archivo svc.cs se renombraron correctamente, el marcado todavía hacía referencia al archivo original.

Para solucionar este problema, haga clic con el botón derecho en el archivo svc copiado, elija Ver marcado y cambie la referencia del servicio.

Como se menciona en otras respuestas, como @chinto, esto sucede cuando el elemento de encabezado SOAP: Action no coincide con el Endpoint.

Puede encontrar el URI correcto para usar mirando el WSDL del servidor. Verá un elemento de operación con un elemento secundario de entrada que tiene un atributo "Acción". Eso es lo que su SOAP: la acción debe estar en la solicitud del 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>

Tuve el mismo problema. El problema fue que copié el código de otro servicio como punto de partida y no cambié la clase de servicio en el archivo .svc

Abra el archivo .svc y asegúrese de que el atributo de servicio sea correcto.

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

El error dice que hay una falta de coincidencia, asumiendo que tiene un contrato común basado en el mismo WSDL, entonces la falta de coincidencia está en la configuración.

Por ejemplo, que el cliente está usando nettcpip y el servidor está configurado para usar http básico.

Tuve un error similar. Esto podría deberse a que habría cambiado alguna configuración de contrato en su archivo de configuración después de que fue referenciado en su proyecto. solución: actualice la referencia del servicio web en su proyecto VSstudio o cree un nuevo proxy usando svcutil.exe

Este error generalmente se produce si el código no se implementa correctamente.

En mi caso, tengo dos servicios ServiceA y ServiceB. Encontré el problema de que los archivos ServiceB no se implementaron correctamente. Por eso, cuando ServiceA llamaba a ServiceB internamente, daba el siguiente error.

Asegúrese de que los archivos y las referencias se hayan implementado correctamente.

Pasé días buscando la respuesta y la encontré, pero no en este hilo. Soy muy nuevo en WCF y C #, por lo que para algunos la respuesta puede ser obvia.

En mi situación, tenía una herramienta cliente que se desarrolló originalmente para el servicio ASMX, y para mí estaba devolviendo el mismo mensaje de error.

Después de probar todo tipo de recomendaciones, encontré este sitio:

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

Me puso en el camino correcto. Específicamente "soap: operation" - WCF estaba agregando ServiceName al espacio de nombres:

cliente esperado Http://TEST.COM/Login, pero WCF enviado Http://TEST.COM/IService1/Login. La solución es agregar una configuración [OperationContract]como esta:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignore los espacios en blanco en Http)

Esto podría deberse a 2 razones:

1. La referencia del servicio está desactualizada, haga clic con el botón derecho en la referencia del servicio y actualícela.

2. El contrato que ha implementado puede ser diferente al del cliente. Compare el contrato de servicio n el cliente n solucione el desajuste de los contratos.

Si está llamando al método WCF, debe incluir la interfaz en el encabezado.

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

También podría ser útil para aquellos que hacen esto mediante la codificación. Debe agregar WebHttpBehavior () a su punto final de servicio agregado. Algo como:

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

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

Tonto, pero olvidé agregar [OperationContract]a mi interfaz de servicio (la que está marcada con [ServiceContract]) y luego también aparece este error.

Su cliente no fue actualizado, así que actualice sus servicios desde el servicio web y luego reconstruya su proyecto

Yo tuve este problema también. Resultó que fue causado por el serializador del contrato al final del servidor. No pudo devolver mi objeto de contrato de datos porque algunos de sus miembros de datos eran propiedades de solo lectura .

Asegúrese de que sus objetos tengan establecedores para las propiedades destinadas a ser serializadas.

Por extraño que parezca, solucionamos este error utilizando las mismas mayúsculas y minúsculas que se utilizaron en el nombre Path y OperationContract. Aparentemente, distingue entre mayúsculas y minúsculas. Si alguien sabe por qué, comente. ¡Gracias!

Entonces, mi caso fue el siguiente. No usé proxy para la interacción cliente-servidor, usé ChannelFactory (por lo tanto, todos los consejos para actualizar a la referencia de servicio no tenían sentido para mí).

El servicio estaba alojado en IIS y, por alguna razón, tenía referencias incorrectas en la carpeta bin allí. La recompilación del proyecto simplemente no condujo a nuevos archivos DLL en esa carpeta.

Así que eliminé todas las cosas de allí y agregué una referencia al servicio en la misma solución, luego volví a compilar y ahora todo funciona.

Mi problema resultó ser algo raro, pero lo mencionaré de todos modos.

Encontré el problema al implementar en nuestro entorno de desarrollo. En esa máquina, nuestra persona de compilación había creado dos carpetas (implementado dos aplicaciones). Una versión antigua y la nueva versión actual. Entonces, si no tiene dos versiones de su aplicación en el servidor web, esto no se aplica a usted.

La nueva ubicación que creó tenía un nombre no estándar como la primera parte de la URL después del host:

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

En mi máquina local, mi cliente apuntaba al nombre de la carpeta estándar tal como se configuró en todos los entornos (excepto el de desarrollo), incluido mi entorno local.

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

Cuando volví a volar y reemplacé el web.config en desarrollo con mi copia local, la parte de la URL que necesitaba ser especial quedó impresionado con la parte estándar, por lo que, como resultado, el cliente en dev señaló la aplicación anterior.

La aplicación anterior tenía un contrato antiguo y no entendió la solicitud y arrojó este error.

Tuve el mismo error en un servicio WCF implementado, el problema estaba relacionado con otro servicio implementado con otro contrato con el mismo puerto.

Solución

Usé diferentes puertos en web.config y el problema desapareció.

Servicio 1

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

Servicio 2

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

Además , me encontré con esta situación al usar un puerto diferente para la misma dirección entre el servicio y el consumidor.

Tuve este error porque tengo una versión anterior de la DLL en el GAC de mi servidor. Así que asegúrese de que todo esté referenciado correctamente y que el ensamblado / GAC esté actualizado con la buena dll.

Tuve este problema en mi servidor de prueba, porque estaba ejecutando dos copias del mismo wcf en el mismo grupo de aplicaciones. Lo que me resolvió fue crear grupos separados para cada versión en mi wcf y reiniciar el IIS después de esto.

Para aquellos que están usando NodeJS con axios para realizar las solicitudes SOAP, deben incluir un SOAPAction header. Mira el ejemplo a continuación:

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