कॉन्ट्रैक्टफिल्टर ने एंडपॉइंट डिस्चैपर अपवाद को मिसमैच किया

116

मेरे पास निम्नलिखित परिदृश्य हैं जिनके लिए मैं परीक्षण करने की कोशिश कर रहा हूं:

एक सामान्य डब्लूएसडीएल
WCF समापन बिंदु जो कि WSDL के आधार पर वस्तुओं को लागू करता है और IIS में होस्ट किया जाता है।
एक क्लाइंट ऐप जो अनुरोध बनाने के लिए WSDL के आधार पर प्रॉक्सी का उपयोग करता है।

जब मैं ग्राहक से सेवा समापन बिंदु तक वेब सेवा कॉल करता हूं, तो मुझे निम्न अपवाद मिलते हैं:

{"क्रिया के साथ संदेश ' http: // IMyService / CreateContainer ' को रिसीवर पर संसाधित नहीं किया जा सकता है, क्योंकि EndpointDispatcher पर एक अनुबंध फ़ाइटर बेमेल के कारण। यह या तो एक अनुबंध बेमेल (प्रेषक और रिसीवर के बीच बेमेल क्रिया) या एक के कारण हो सकता है। प्रेषक और रिसीवर के बीच बाइंडिंग / सुरक्षा बेमेल। जाँच करें कि प्रेषक और रिसीवर के पास एक ही अनुबंध और एक ही बाइंडिंग है (सुरक्षा आवश्यकताओं, जैसे संदेश, परिवहन, कोई भी नहीं)। "}

मैंने MS Service Trace Viewer का उपयोग करना शुरू कर दिया है, लेकिन निश्चित नहीं है कि कहाँ देखना है। क्लाइंट और एंडपॉइंट में कक्षाएं देखते समय, वे समान दिखाई देते हैं।

इस समस्या को कैसे शुरू किया जाए?

इस अपवाद के कुछ संभावित कारण क्या हैं?

wcf

— laconicdev
स्रोत

75

एक "कॉन्ट्रैक्टफ़िल्टर बेमेल एंडपॉइंट डिस्चैफ़र" का अर्थ है कि रिसीवर संदेश को संसाधित नहीं कर सकता है क्योंकि यह किसी भी अनुबंध से मेल नहीं खाता है जो रिसीवर ने समापन बिंदु के लिए कॉन्फ़िगर किया है जो संदेश प्राप्त करता है।

यह हो सकता है क्योंकि:

आपके पास ग्राहक और प्रेषक के बीच अलग-अलग अनुबंध हैं।
आप ग्राहक और प्रेषक के बीच एक अलग बंधन का उपयोग कर रहे हैं।
संदेश सुरक्षा सेटिंग्स क्लाइंट और प्रेषक के बीच संगत नहीं हैं।

पर नज़र पर है EndpointDispatcherइस विषय पर अधिक जानकारी के लिए वर्ग।

इसलिए:

सुनिश्चित करें कि आपका क्लाइंट और सर्वर अनुबंध मेल खाते हैं।

यदि आपने अपने ग्राहक को डब्लूएसडीएल से उत्पन्न किया है, तो क्या डब्लूएसडीएल अप-टू-डेट है?
यदि आपने अनुबंध में हाल ही में बदलाव किया है, तो क्या आपने क्लाइंट और सर्वर दोनों के सही संस्करण को तैनात किया है?
यदि आपने अपने क्लाइंट कॉन्ट्रैक्ट क्लासेस को हाथ से तैयार किया है, तो सुनिश्चित करें कि सर्वर द्वारा अपेक्षित नाम स्थान, तत्व नाम और एक्शन नाम मेल खाते हैं।

क्लाइंट और सर्वर के बीच बाइंडिंग समान हैं।

यदि आप अपने समापन बिंदु का प्रबंधन करने के लिए .config फ़ाइल का उपयोग कर रहे हैं, तो सुनिश्चित करें कि बाध्यकारी तत्व मेल खाते हैं।

ग्राहक और सर्वर के बीच सुरक्षा सेटिंग्स समान हैं।

यदि आप अपने समापन बिंदुओं को प्रबंधित करने के लिए .config फ़ाइल का उपयोग कर रहे हैं, तो सुनिश्चित करें कि सुरक्षा तत्व मेल खाते हैं।

— पॉल टर्नर
स्रोत

3

यह भी सुनिश्चित करें कि सर्विस विशेषता .svc फ़ाइल में सही है। नीचे मेरा जवाब देखें।

— एंटोनोक

जैसा कि मैंने एक ही मुद्दे का सामना किया है, वैसे ही ऊपर (नवागंतुक के लिए) समाधान जोड़ना चाहता था, लेकिन उपरोक्त समाधान मेरे लिए काम नहीं किया। यदि आपने ऊपर दिए गए वर्कअराउंड को पहले ही आज़मा लिया है और अभी भी वही त्रुटि हो रही है, तो अपने कॉन्फ़िगरेशन को अपडेट करने की कोशिश करें, जिसमें शामिल सरल एंडीपिंग एंडपॉइंट्स द्वारा अपने सर्वर और क्लाइंट दोनों पर पहले से ही सही है।

— devpro101

74

मेरे पास यह त्रुटि थी और यह रसीद अनुबंध के कारण विधि को लागू नहीं करने के कारण हुआ था। मूल रूप से, किसी ने WCF सेवा के अंतिम संस्करण को होस्ट सर्वर पर तैनात नहीं किया था।

— एडम
स्रोत

12

+1 - मेरे साथ एक ही बात हुई, मेरे मामले को छोड़कर यह वह था जो "कोई" था। मैं सर्वर-साइड कोड को कमिट करना और तैनात करना भूल गया था।

— जेसी वेब

2

हाँ, मैं SOAP कार्रवाई का नाम गलत था। यह tempuri.org/ICodeGenService/RenderApp चाहता था , लेकिन किसी कारण से WSDL को कोड करने वाले कोड ने tempuri.org/RenderApp सोचा ।

— user435779

मैं भी। मेरे पास .SVC.CS में विधि थी, लेकिन मेरे इंटरफ़ेस में कोई संबंधित ऑपरेशनकंट्रेक्ट नहीं था।

— पहरोजर

मुझे भी :) मैंने विकास के तहत स्थानीय सेवा का उपयोग करके एसओपीयूआई में डब्ल्यूएसडीएल को ताज़ा किया, और जब मैंने सेवा में नई पद्धति के खिलाफ एक अनुरोध बनाया, तो सोपुई ने हमारे विकास के वातावरण का उपयोग किया। इसलिए, विधि अच्छी तरह से काम कर रही थी, मैंने सिर्फ गलत URL की पुष्टि की।

— लार्सबज

2

धन्यवाद! मैंने घंटों डिबगिंग खर्च नहीं किया, इसके बजाय यह पढ़ने के बाद मुझे एहसास हुआ कि मैं एक गलत वातावरण के लिए अनुरोध भेज रहा था।

— Jan Matousek

20

यदि आप गलत URL से कनेक्ट करने का प्रयास करते हैं तो आपको यह भी मिलेगा ;)

मेरे सिस्टम में दो एंडपॉइंट और सेवाएँ समान नाम के साथ परिभाषित हैं।

यह सटीक त्रुटि तब मिली जब URL किसी बिंदु पर मेरे क्लाइंट पर स्वैप हो गए। वास्तव में इस खरोंच गलती का पता लगाने तक सिर खरोंच।

— ब्रैडी मोरिट्ज़
स्रोत

3

यह सुनिश्चित करने के लिए एक मूर्खतापूर्ण गलती है, लेकिन यहां एक बहुत ही उपयोगी जवाब है। जैसा कि यह कुछ स्पष्ट है यह आसानी से अनदेखी है।

— मुंगफलेश

गलत url देता है - 'त्रुटि का कोई समापन बिंदु नहीं था'

— AriesConnolly

19

मुझे यह समस्या थी और मैंने पाया कि मेरे प्रॉक्सी जनरेटर में, जिसे मैंने किसी अन्य सेवा से कॉपी किया था, मैं सेवा का नाम बदलना भूल गया था।

मैंने इसे बदल दिया ...

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

सेवा...

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

यह एक सरल कोड त्रुटि थी, लेकिन डिबग करना लगभग असंभव था। मुझे उम्मीद है कि यह किसी को समय बचाता है।

— लूटना
स्रोत

मेरा भी यही मामला था।

— वासिल बोरोविक

धन्यवाद, मुझे भी यही समस्या थी!

— डिटर्जेंट

10

जावा क्लाइंट के लिए .net एंडपॉइंट कॉल करना। यह सोप एक्शन हेडर को मिसमैच करने के कारण हुआ।

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>

— CHINTO
स्रोत

9

मैंने इसे अपने अनुबंध कार्यान्वयन में निम्न जोड़कर हल किया:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

उदाहरण के लिए:

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

}

— बेन
स्रोत

इससे मेरी समस्या एक अग्रेषित पोर्ट के साथ हल हो गई। धन्यवाद।

— मथियास मूलर

नहीं मुझे एक नई त्रुटि मिली, मैं IIS से नफरत करता हूं - CommunicationException: सर्वर ने एक सार्थक उत्तर प्रदान नहीं किया; यह कॉन्ट्रैक्ट मिसमैच, समयपूर्व सत्र बंद या आंतरिक सर्वर त्रुटि के कारण हो सकता है।

— मेषकौनली

8

मुझे यह मिला जब मैंने svc फ़ाइल की प्रतिलिपि बनाई और उसका नाम बदल दिया। हालाँकि फ़ाइल नाम और svc.cs फ़ाइल को सही ढंग से बदला गया था, फिर भी मार्कअप ने मूल फ़ाइल को संदर्भित किया।

इसे ठीक करने के लिए, प्रतिलिपि की गई svc फ़ाइल पर राइट क्लिक करें और देखें मार्कअप चुनें और सेवा संदर्भ बदलें।

— मैं कुछ नहीं जनता
स्रोत

5

जैसा कि अन्य उत्तरों में उल्लेख किया गया है, जैसे @chinto, यह तब होता है जब SOAP: एक्शन हेडर तत्व एंडपॉइंट से मेल नहीं खाता है।

आप सर्वर के डब्लूएसडीएल को देखकर सही यूआरआई का उपयोग कर सकते हैं। आपको एक इनपुट तत्व के साथ एक ऑपरेशन तत्व दिखाई देगा जिसमें "एक्शन" विशेषता है। यह वही है जो आपके SOAP: एक्शन को क्लाइंट के अनुरोध पर होना चाहिए।

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

— कार्सन इवांस
स्रोत

गुग्लिंग और परीक्षण और पागल होने के दिनों के बाद - इस जवाब ने मेरी मदद की। धन्यवाद।

— बबून

मेरे विशेष परिदृश्य में, मैं Apache HttpClient का उपयोग करके अपने जावा वर्ग से वेबसर्वर को कॉल कर रहा था। सोप एक्शन हेडर को सेट करने के लिए, मैंने सेट टाइप करने के लिए सेटहेडर विधि को कॉल करने के तुरंत बाद HttpPost SetHeader विधि को कॉल किया।

— vofili

3

मेरी भी यही समस्या थी। समस्या यह थी कि मैंने एक प्रारंभिक बिंदु के रूप में एक अन्य सेवा से कोड की प्रतिलिपि बनाई और सर्विस क्लास को .svc फ़ाइल में नहीं बदला

.Svc फ़ाइल खोलें यह सुनिश्चित करें कि सेवा विशेषता सही है।

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

— AntonK
स्रोत

2

त्रुटि का कहना है कि एक बेमेल है, यह मानते हुए कि आपके पास समान WSDL के आधार पर एक सामान्य अनुबंध है, तो बेमेल कॉन्फ़िगरेशन में है।

उदाहरण के लिए कि क्लाइंट nettcpip का उपयोग कर रहा है और सर्वर को मूल http का उपयोग करने के लिए सेट किया गया है।

— शिराज भाईजी
स्रोत

2

मेरी भी ऐसी ही त्रुटि थी। ऐसा इसलिए हो सकता है क्योंकि आपने अपने प्रोजेक्ट में रिफरेक्ट होने के बाद अपनी कॉन्ट्रैक्ट फाइल में कुछ कॉन्ट्रैक्ट सेटिंग बदल दी होगी। समाधान - आप VSstudio परियोजना पर webservice संदर्भ को अपडेट करें या svcutil.exe का उपयोग करके एक नया प्रॉक्सी बनाएं

— महेश कुरुप
स्रोत

1

यह त्रुटि आम तौर पर आती है अगर कोड ठीक से तैनात नहीं है।

मेरे मामले में, मेरे पास दो सेवाएँ ServiceA और ServiceB हैं। मुझे समस्या यह लगी कि ServiceB फाइलें ठीक से तैनात नहीं की गईं। जिसके कारण जब ServiceA आंतरिक रूप से ServiceB को कॉल कर रहा था तो यह त्रुटि के नीचे दे रहा था।

** त्रुटि **

कृपया सुनिश्चित करें कि फाइलें और संदर्भ ठीक से तैनात हैं।

— अतुल के।
स्रोत

1

मैंने उत्तर की तलाश में दिन बिताए और मुझे यह मिल गया, लेकिन इस धागे में नहीं। मैं 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/

इसने मुझे सही रास्ते पर ला खड़ा किया। विशेष रूप से "साबुन: ऑपरेशन" - WCF नेमस्पेस को सेवा नाम दिया गया था:

ग्राहक की उम्मीद है Http://TEST.COM/Login, लेकिन WCF भेजा Http://TEST.COM/IService1/Login। समाधान [OperationContract]इस तरह से सेटिंग जोड़ना है :

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Http में रिक्त स्थानों को अनदेखा करें)

— KSNSACC
स्रोत

2

कुंआ। आपके समाधान के लिए कुछ ग्राहक की अपेक्षा सेवा व्यवहार करना है। लेकिन यह समान रूप से अच्छी तरह से (या कई मामलों में, अधिमानतः) ग्राहक के सर्वर के अनुबंध के अनुरूप होने से हल किया जा सकता है! आखिरकार, सर्वर अनुबंध का प्रकाशक है।

— दाग

1

इसके 2 कारण हो सकते हैं:

सेवा रेफरी पुराना है, राइट क्लिक सेवा रेफरी n इसे अपडेट करें।
अनुबंध जो आपने लागू किया है वह अलग हो सकता है जो ग्राहक के पास है। दोनों सेवा n क्लाइंट कॉन्ट्रैक्ट n की तुलना करें। कॉन्ट्रैक्ट मिसमैच को ठीक करें।

— अब्दुल समी
स्रोत

1

यदि आप 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+ "\"");
}

— अहमत अरसलन
स्रोत

1

इसके अलावा यह उन लोगों के लिए उपयोगी हो सकता है जो कोडिंग करके ऐसा कर रहे हैं। आपको अपनी जोड़ी गई सेवा समाप्ति बिंदु पर 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

— अमीर दशति
स्रोत

इससे मुझे अपना समय बचाने में मदद मिली, धन्यवाद :)

— स्लीक लीची

0

मूर्खतापूर्ण, लेकिन मैं [OperationContract]अपने सेवा इंटरफ़ेस (जिस पर चिह्नित किया गया है [ServiceContract]) को जोड़ना भूल गया और फिर आपको यह त्रुटि भी मिली।

— पीटर
स्रोत

0

आपका क्लाइंट अपडेट नहीं किया गया था। वेब सेवा से अपनी सेवाओं को अपडेट करें और फिर अपनी परियोजना का पुनर्निर्माण करें

— मसूद बहरामि
स्रोत

0

मुझे भी यह समस्या थी। यह पता चला है कि यह सर्वर के अंत में अनुबंध के धारावाहिककार के कारण हुआ था। यह मेरी डेटा कॉन्ट्रैक्ट ऑब्जेक्ट को वापस नहीं कर सका क्योंकि इसके कुछ डेटामेम्बर्स आसानी से प्रॉपर्टी थे ।

सुनिश्चित करें कि आपकी वस्तुओं को क्रमबद्ध किए जाने वाले गुणों के लिए व्यवस्थित किया गया है।

— CRONO
स्रोत

0

अजीब तरह से हमने इस त्रुटि के आसपास काम किया वही आवरण पथ और ऑपरेशनकॉन्ट्रैक्ट नाम का उपयोग किया। जाहिर तौर पर यह मामला संवेदनशील था। अगर किसी को पता है कि क्यों, कृपया टिप्पणी करें। धन्यवाद!

— MikeTeeVee
स्रोत

0

तो, मेरा मामला निम्नलिखित था। मैंने क्लाइंट-सर्वर इंटरैक्शन के लिए प्रॉक्सी का उपयोग नहीं किया, मैंने ChannelFactory का उपयोग किया (इस प्रकार सेवा संदर्भ में अपग्रेड करने की सभी सलाह मेरे लिए अर्थहीन थी)।

यह सेवा IIS में होस्ट की गई थी और किसी कारण से इसके बिन फ़ोल्डर में गलत संदर्भ थे। इस परियोजना के पुनर्निर्माण में बस उस फ़ोल्डर में नए dll का नेतृत्व नहीं किया गया।

इसलिए मैंने बस वहां से सभी सामान को हटा दिया और उसी समाधान में सेवा के लिए संदर्भ जोड़ा, फिर से पुन: व्यवस्थित किया और अब सब कुछ काम करता है।

— psfinaki
स्रोत

0

मेरा मुद्दा कुछ दुर्लभ निकला, लेकिन मैं फिर भी इसका उल्लेख करूंगा।

मुझे हमारे विकास के वातावरण में तैनाती के मुद्दे का सामना करना पड़ा। उस मशीन पर, हमारे बिल्ड व्यक्ति ने दो फ़ोल्डर बनाए थे (दो एप्लिकेशन को तैनात किया था)। एक पुराना संस्करण और नया वर्तमान संस्करण। इसलिए यदि आपके पास वेब सर्वर पर आपके एप्लिकेशन के दो संस्करण नहीं हैं, तो यह आपके लिए लागू नहीं होता है।

उनके द्वारा बनाया गया नया स्थान होस्ट के बाद url के पहले भाग के रूप में एक गैर-मानक नाम था:

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

मेरी स्थानीय मशीन पर, मेरा क्लाइंट मानक फ़ोल्डर नाम की ओर इशारा कर रहा था जैसा कि मेरे स्थानीय वातावरण सहित सभी वातावरणों (विकास को छोड़कर) पर स्थापित किया गया था।

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

जब मैंने उड़ा दिया और अपनी स्थानीय प्रति के साथ विकास पर web.config को बदल दिया, तो विशेष रूप से आवश्यक होने वाले url के हिस्से को मानक भाग के साथ उड़ा दिया गया, इसलिए परिणामस्वरूप देव पर क्लाइंट ने पुराने एप्लिकेशन को इंगित किया।

पुराने आवेदन में एक पुराना अनुबंध था और अनुरोध को नहीं समझा और इस त्रुटि को फेंक दिया।

— toddmo
स्रोत

0

मुझे WCF सेवा में वही त्रुटि थी, जो समस्या उसी पोर्ट के साथ किसी अन्य अनुबंध के साथ तैनात किसी अन्य सेवा से संबंधित थी।

उपाय

मैंने web.config में विभिन्न बंदरगाहों का उपयोग किया और समस्या गायब हो गई।

सेवा १

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

सेवा २

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

इसके अलावा , मैं सेवा और उपभोक्ता के बीच समान पते के लिए अलग-अलग पोर्ट का उपयोग करके इस स्थिति में चला गया।

— DanielV
स्रोत

0

मेरे पास यह त्रुटि थी क्योंकि मेरे सर्वर के GAC में DLL का पुराना संस्करण है। इसलिए सुनिश्चित करें कि सब कुछ सही ढंग से संदर्भित है और विधानसभा / जीएसी अच्छे डीएल के साथ अद्यतित है।

— Helpha
स्रोत

0

मुझे यह समस्या मेरे टेस्ट सर्वर पर थी, क्योंकि मैं एक ही एप्लिकेशन पूल पर एक ही wcf की दो प्रतियां चला रहा था। मेरे लिए क्या हल किया गया था मेरे wcf पर प्रत्येक संस्करण के लिए अलग-अलग पूल बनाए और इसके बाद IIS को पुनरारंभ करें।

— जोहान
स्रोत

0

उन लोगों के लिए जो SOAP अनुरोध करने के लिए axios के साथ NodeJS का उपयोग कर रहे हैं, आपको इसमें शामिल होना चाहिए 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)
  })

— क्रिश्चियन सैकी
स्रोत