SOLVED: Error message: contract mismatch or binding/security mismatch running view model

Mar 31, 2014 at 12:22 AM
Edited Apr 2, 2014 at 11:35 PM
SOLVED
Summary

While developing a CODE Framework WPF MVVM/MVC application, I ran into an error running a ViewModel against a service. The error was
The message with Action 'http://tempuri.org/IEchoService/GetPhonesCmor' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher.
Since the service call ran from the development host, I was mightly confused, but the solution was simple enough.

The WPF App.Config was still pointing to my deployed Windows service host I'd recently been testing. Set it to point to localhost (and my development host) and all is well.

Original post with amendments below


ETA important omissions from original post.
  1. CODE Framework version 4.0.4 (March 4th), WPF MVVM/MVC Application project using CODE WCF and WPF classes.
  2. SQL Server 2012 backend with a linked server to a POSTGRESQL database.
  3. Using EntityFramework version 6.
  4. Using LINQ queries.
  5. The service call works. It's when I make the service call in the ViewModel, that I get the error.
  6. Other ViewModels work fine including ones using calls that link SQL and POSTGRESQL data.
The problem: I get an error with two view models (I've included one as an example) that I don't get with any others. The error is:
The message with Action 'http://tempuri.org/IEchoService/GetPhonesCmor' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
Out of desperation, I've created new Information, Request and Response, Implementation, Controller, ViewModel, and Model classes, with the same result.

Original message:

The error is on the following line in my ViewModel.LoadData(). The service call itself is fine when I invoke it from the development host.
ServiceClient.Call<IEchoService>(
                        service => { response = service.GetPhonesCmor(new GetPhonesCmorRequest { EntityCmorId = entityCmorId, EntityCmor = entityCmor }); });
The error is as follows:

The message with Action 'http://tempuri.org/IEchoService/GetPhonesCmor' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Here is the entire LoadData method:
        private void LoadData(int entityCmorId, string entityCmor)
        {
            AsyncWorker.Execute(() =>
                {
                    var response = new GetEmailsCmorResponse();
                    ServiceClient.Call<IEchoService>(
                        service => { response = service.GetEmailsCmor(new GetEmailsCmorRequest { EntityCmorId = entityCmorId, EntityCmor = entityCmor }); });
                    return response;
                },
                response =>
                {
                    EmailCollection.Clear();
                    if (response.Success == false)
                    {
                        Controller.Message(response.FailureInformation);
                        return;
                    }
                    foreach (var item in response.Emails)
                    {
                        var email = new EmailDataViewModel();
                        email.EmailAddress = item.EmailAddress;
                        email.EmailCmorId = item.EmailCmorId;
                        email.PersonCmorId = item.EntityCmorId;
                        EmailCollection.Add(email);
                    }
                    NotifyChanged();
                },
                this);
        }
Any tips would be welcome. Thanks!
Mar 31, 2014 at 7:35 AM
Hi,
At first this please check all your configs and be sure that you are using same binding on service and client.
The problem occurs when you have different binding properties on both client and service configs. e.g.
You may defined a wsHttpBinding on service but trying to use BasicHttp binding on client
or both using wsHttpBinding however only on client you have enabled security mode (transport or message) not on the service etc.

please check the below web.config and app.config from a working application. They are using wsHttpBinding and security mode is none

web.config

..
  <system.serviceModel>
<bindings>
      <wsHttpBinding>
        <binding name="SOAServiceWSHttpBindingConfig" closeTimeout="00:01:00" bypassProxyOnLocal="true" useDefaultWebProxy="false" openTimeout="00:02:00" receiveTimeout="00:10:00" sendTimeout="00:05:00" messageEncoding="Text" allowCookies="true" maxReceivedMessageSize="999999999" textEncoding="utf-8" transactionFlow="false">
        <security mode="None"/>
        </binding>
      </wsHttpBinding>
          </bindings>
           <services>
                 <service name="SOA.Service.AuthenticationService" behaviorConfiguration="AuthenticationServiceBehaviour">
        <endpoint binding="wsHttpBinding" bindingConfiguration="SOAServiceWSHttpBindingConfig" contract="SOA.Service.IAuthenticationService"/>
        <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
      </services>
    <behaviors>
          <serviceBehaviors>
        <clear/>
            <behavior name="AuthenticationServiceBehaviour">
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" policyVersion="Policy15"/>
          <serviceTimeouts transactionTimeout="00:05:00"/>
          <sendMessageChannelCache allowUnsafeCaching="true"/>
          <bufferedReceive maxPendingMessagesPerChannel="10000"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
          <useRequestHeadersForMetadataAddress/>
          <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="1000" maxConcurrentInstances="1000"/>
        </behavior>
              </serviceBehaviors>
    </behaviors>
      </system.serviceModel>
    ...

app.config.
<system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IAuthenticationService">
                  <security mode="None" />
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://X.Y.Z.W/SOA_New/AuthenticationService.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IAuthenticationService"
                contract="AuthenticationServiceReference.IAuthenticationService"
                name="WSHttpBinding_IAuthenticationService" />
        </client>
    </system.serviceModel>
Happy coding.
Mar 31, 2014 at 3:09 PM
Thank you for your reply. I failed to include two important facts. The application is a CODE Framework WPF/MVVM app, and most of the view models are successful retrieving data. For example, this view model is being loaded as a partial view model.


Mar 31, 2014 at 3:21 PM
Edited Mar 31, 2014 at 3:31 PM
I should add that the parent (?) view models is also running an asynch process. The phones are loaded in the response method of that process. Now that I've had some sleep, I'll start looking into differences between successful and successful partial views and whether phones and emails work alright on their own. Anyway, for context, here is the parent code:
private void LoadData(int memberCmorId)
{
    AsyncWorker.Execute(() =>
    {
        GetMemberResponse response = null;
        ServiceClient.Call<IEchoService>(s => {
                response =
                    s.GetMember(
                        new GetMemberRequest
                            {
                                MemberCmorId = memberCmorId
                            });
            });
        return response;

    },
    response =>
    {
        if (!response.Success)
        {
            Controller.Message(response.FailureInformation);
            return;
        }
        if (response.Success == false)
        {
            Controller.Message(response.FailureInformation);
            return;
        }
        Mapper.Map(response.MemberInfo, this);
        NotifyChanged();
        NotesViewModel = new MemberNotesViewModel(
            response.MemberInfo.MemberCmorLinkId);
        AddressesViewModel = new AddressesCmorViewModel(
            response.MemberInfo.AddressCmorId);
        PhonesViewModel = new PhonesCmorViewModel(
            response.MemberInfo.PersonCmorId, "person");
        EmailsViewModel = new EmailsCmorViewModel(
    },
    this);
}
Apr 1, 2014 at 9:52 AM
Hi,

OK your client is CODE framework app. what about IEchoService service, is it WCF or another type of service? I think the method (GetMember) failing before returning data at service/channel level. So on your service host project (if you are using CODE framework hosted project) add the following diagnostic config setting into your app.config file (or if you are using IIS hosted enviroment add into web.config)
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
..
  
  <system.diagnostics>
    <trace autoflush="true"/>
    <sources>
      <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
        <listeners>
          <add name="sdt" type="System.Diagnostics.XmlWriterTraceListener" initializeData="D:\SdrConfigExample.svclog"/>
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
</configuration>
after making request on D: drive root you should see {GUID}.svclog (or SdrConfigExample.svclog) file(s) so open it with your SvcTraceViewer.exe and inspect the error(s) if any.

Hope this will help you.
Apr 1, 2014 at 6:11 PM
I updated the original post with critical information I missed posting originally. Yes, I'm using WCF, specifically the CODE Framework classes. (Not that I think this is a CODE issue.) I've also set it up so I can run the partial view without the parent view. The parent, Member, runs perfectly fine with the problem partial views, BTW.

I implemented the diagnostics as you suggest and I do have errors. Unfortunately, I'm clueless how to use the information. I'll post it, to document it, at least. I hesitate to dive too far into this rabbit hole simply because all my other views are working, and a previous ViewModel for phones has worked just fine. So I think I'll tackle it from a higher level for now.

I do appreciate your help and the information about the diagnostic tool. Thanks!
Coordinator
Apr 2, 2014 at 8:21 AM
When you get a contract mismatch error, there is something fishy going on in the contract or the communication. I assume you are just reusing the contract DLL in the client, so the interfaces must match. Are you sure you are hosting with the right protocols and all that? I have also seen it where the contract itself may have something odd that WCF can't process correctly. Like adding a [DataContract] attribute on an enum declaration or something like that. Does the service work in the development host when you just double-click it?


Markus
Apr 2, 2014 at 10:49 AM
I am totally agree with Mr. Markus, you should be missing out some points on your WCF side and you can only see/discover that mistakes/errors by using trace files even debugging is useless, otherwise you may not able to find where the problem is.

Happy Coding.
Developer
Apr 2, 2014 at 2:26 PM
As Markus noted, normally the "due to a ContractFilter mismatch" is the key phrase which would normally mean the UI making the service call has a different Service Contract than the Service accepting the call.

However in this case we have verified that the service contract dll is the same for both the UI and the Service. The contract has the proper [DataContract] attributes. Additionally running the method on the Development Host is successful. So something else is going on here.

Will keep the post updated as things progress.

Jeff
Apr 2, 2014 at 2:32 PM
Hi, Markus,

Thanks for taking an interest. This is driving me mad. I have no doubt it's something odd I've introduced, like a misplaced [DataContract], but heck if I can find it.

Yes, I cross my heart and swear the service runs from the development host interface. (Jeff gave it a look Monday, and this was the first thing he double-checked.)

Regarding hosting protocols, wouldn't all the ViewModels fail if the protocols were wrong? As far as I can tell the entire WPF project would be using the same, yes?

I've cleaned the solution and rebuilt and confirmed the contract DLL is the same one in the WPF project that's in the contracts project. Again, this was another thing Jeff also checked.

I've changed the service to return mocked-up data instead of hitting the real database, and get the same error. Again, the service works fine, however.

The problem view model works when I change it to call a different service that works in another view model. (I haven't yet changed a working viewmodel to call the problematic service.)

I've rebuild the problem child from the information class up thru the view class. The view, BTW, doesn't have any controls on it. Just a header. I did that so I'd hopefully not introduce any errant [datacontract] attributes. No change. The new one has the the same error.

If I could somehow see what contract the sender is sending and what the receiver is expecting, at runtime, it might be helpful. But that's beyond me. I don't know how to go about that. I've stepped into your source code in case that gave me a clue of where to look but it pretty doesn't help. Me, at least. But Jeff will tell you just how much of a newbie I am.

Anyway, after my morning tutoring/therapy session with Jeff I'd planned to create a brand new project for just this entity to see if I clear out anything muddying the water.

While I don't disagree with emrahyildirim, I am at my knowledge limit has to how to go about doing what they suggest. The logging was interesting, but didn't give me any ideas of how to proceed down that road.
Coordinator
Apr 2, 2014 at 8:39 PM
Based on the error message, I am pretty confident that it happens during the WCF channel call. In other words: It probably won't change anything when you change the implementation on the server (to hardcoded data or anything like that), since it probably never gets there. It almost looks to me like it is getting confused as to what it is hosting. Are you hosting the same service in multiple protocols? If so, maybe try hosting it as TCP/IP only. I suppose it could also be a security thing if it is HTTP. I have seen that happen. Generally, if you run the host as Admin (which allows it to take over just about anything) that should not happen though.


Markus
Marked as answer by NancyFolsom on 4/2/2014 at 4:28 PM
Apr 2, 2014 at 11:28 PM
Thank you, Markus. You nudged me down the right path. Thank you so much!

My WPF App.config was pointing to my windows service host instead of my development service host. I forgot to set it back after doing an initial deployment test last week.

I was stepping thru ServiceClient.Call to tell you exactly where it bombed and re-read for the millionth time the error message. I thought it was weird that it mentioned the IP address but the data and the service live on the same (test) server. But since I disconnected the data back end it really didn't makes sense it would reference it. another clue that I knew was weird but didn't know what to do with was that the service method call wouldn't break. However, I figured it was blowing up before it got there. Which it was.

So, to summarize, I was trying to use a service that was on my development service, but the WPF project was pointing to the Windows service host. That's why it worked in the development host, but not the ViewModel.

Thanks again to you, Jeff, and emrahyildirim.

-Nancy
Coordinator
Apr 3, 2014 at 6:11 AM
Cool! Glad it works now! :-)

Markus