locked
Problem using "MessageContractAttribute" - parameters of different types RRS feed

  • Question

  • I've graduated from sending Int32s and Strings to my own type.  Well, I've tried but it's not working.  I've created a DataContract class at the receive side (a Declarative Sequential Service Library) and a matching MessageContract (with IsWrapped = false) on the send side according to a blog post I found.  I'm new to WCF and WF and struggling with the error I'm getting:

    "The operation 'GetData' could not be loaded because it has a parameter or return type of type System.ServiceModel.Channels.Message or a type that has MessageContractAttribute and other parameters of different types. When using System.ServiceModel.Channels.Message or types with MessageContractAttribute, the method must not use any other types of parameters."

    Any idea which part of it is relevant and why?
    Friday, October 2, 2009 9:02 AM

Answers

  • Never mind.  I'm not sure what I was doing wrong as I went through many steps before finally resolving this.  I think one key issue was the lack of Namespace = parameter on the DataContract attribute and WrapperNamespace = parameter on the MessageContract attribute.
    • Marked as answer by SSG31415926 Tuesday, October 6, 2009 2:39 PM
    Tuesday, October 6, 2009 2:39 PM

All replies

  • Try using IsWrapped=true
    Friday, October 2, 2009 1:07 PM
  • I got the same result.  I'm going to start from scratch with a known-working service that sends a string and then change the parameter to a custom type.  I'll let you know how I get on.
    Friday, October 2, 2009 5:24 PM
  • Okay, I'm still getting that error.  I had a service that was sending a string.  I used .ToString() on the variable everywhere so I could change its type and it would still work, and gradually introduced the custom type.  I've taken the custom type down to the bare minimum.  I've included the type definitions below.  The service was still working when it was sending emp.ToString() but as soon as I switched the ValueType at the send end (along with the equivalent change at the service end) it broke.

    It doesn't matter whether IsWrapped is set to true or false.  This is the type at the client end:

        [MessageContract(IsWrapped=true)]
        public class Employee
        {
            [MessageBodyMember]
            public string Name { get; set; }
    
            public override string ToString()
            {
                return this.Name;
            }
        }
    and at the service end:

        [DataContract]
        public class Employee
        {
            [DataMember]
            public string Name { get; set; }
    
            public override string ToString()
            {
                return this.Name;
            }
        }
    I'm wondering if it's the CorrelationHandle that's the problem.
    Friday, October 2, 2009 7:07 PM
  • Never mind.  I'm not sure what I was doing wrong as I went through many steps before finally resolving this.  I think one key issue was the lack of Namespace = parameter on the DataContract attribute and WrapperNamespace = parameter on the MessageContract attribute.
    • Marked as answer by SSG31415926 Tuesday, October 6, 2009 2:39 PM
    Tuesday, October 6, 2009 2:39 PM
  • When in doubt, add a Service Reference, specify the proper url, open the generated code and compare.
    Tuesday, October 6, 2009 2:55 PM
  • That was one of the strategies I tried but I'm working from home and my printer is out of ink and spotting the wood from the trees in a Service Reference on screen...  well, I didn't spot the problem that way.

    But thanks for the suggestion - you never know.
    Tuesday, October 6, 2009 3:02 PM