Valamas
Valamas

Reputation: 24729

WCF OperationContract property forgets value

recently have been successful getting my IIS hosted WCF service to work with basic authentication.

Since successfully implementing that. I have noticed that property values are not remembered.

Here is some code:

[ServiceContract]
public interface IEcho
{
    string Message { [OperationContract]get; [OperationContract]set; }
    [OperationContract]
    string SendEcho();
}

public class EchoProxy : IEcho
{
    public string Message { get; set; }
    public string SendEcho()
    {
        return string.Concat("You said: ", Message);
    }
}
public class EchoService : System.ServiceModel.ClientBase<IEcho>, IEcho
{
    //-- ..... CONSTRUCTORS OMITTED ....

    public string Message
    {
        get { return base.Channel.Message; }
        set { base.Channel.Message = value; }
    }
    public string SendEcho()
    {
        return base.Channel.SendEcho();
    }
}

Here is the console and the result:

EchoService client = new EchoService("SecureEndpoint");
client.ClientCredentials.UserName.UserName = "test";
client.ClientCredentials.UserName.Password = "P@ssword1";
client.Message = "Hello World";
Console.WriteLine(client.SendEcho());

Expected Result: You said: Hello World
Actual Result: You said:

I have Uploaded the sandbox project to my skydrive. I have included a SETUP.txt in the API project.

Click here to download.
How can I get properties to work?

thank you

Upvotes: 2

Views: 2573

Answers (2)

to StackOverflow
to StackOverflow

Reputation: 124726

To understand what's happening, you need to know how the lifetime of the service object you're connecting to is configured. A good starting point is the MSDN article on Sessions, Instancing, and Concurrency.

For example, with InstanceContextMode.PerCall, a new service object will be created for each call, so no properties of the service object will be remembered between calls.

At the other end of the scale, InstanceContextMode.Single means a single instance handles all client requests for the lifetime of the application. In this case properties set by one client will be visible to all clients, not usually desirable.

In general, I would recommend using a stateless service object. But if you want a stateful service object (e.g. one with properties), you should use InstanceContextMode.PerSession, and (important) use a binding that supports sessions.

While I agree with @JTew that you shouldn't generally expose operations as properties, you will have the same problem if you try to use an object that stores state between calls in another way (such as a private field). I.e. the following would have exactly the same problem:

[ServiceContract]
public interface IEcho
{
    [OperationContract]
    void SetMessage(string message);

    [OperationContract]
    string GetMessage();

    ... etc ...
}

Upvotes: 1

JTew
JTew

Reputation: 3189

I have never seen WCF contract used with a property to transfer data. i.e. the Message property. AFAIK its just not possible.

My recommendation would be to keep the concerns that are part of the contract separate, i.e. Operation and Data.

[ServiceContract]
public interface IEcho
{
    [OperationContract]
    string SendEcho(string Message);
}

Or

[ServiceContract]
public interface IEcho
{
    [OperationContract]
    string SendEcho(Message message);
}

[DataContract]
public class Message
{
    [DataMember]
    public string Message {get; set;}
}

At some later point you may wish to change the Message Object.

[DataContract]
public class MessageV2 : Message
{
    [DataMember]
    public DateTime Sent {get; set;}
}

While this changes the contract, changes like this can be backwardly compatible if managed carefully.

Upvotes: 3

Related Questions