Will changing interface break existing clients

Question

Preface: This code is used within a windows desktop application, client / server application, where the server sends and receives messages to/from the client using SMessage based classes

I have the following interface

public interface IMessage
{
    string ID { get; }

    string R_ID { get; set; }

    DateTime Send { get; }
}

Here is the concrete implementation of this interface:

[Serializable]
public class SMessage : IMessage
{
    public string ID { get; set; }

    public string R_ID { get; set; }

    public DateTime Send{ get; set;}

    public SMessage()
    {
        R_ID = "";
        ID = Guid.NewGuid().ToString();
        Send = DateTime.UtcNow;
    }

    public SMessage(SMessage msg)
    {
        ID = msg.ID;
        Send = msg.UTCSend;
        R_ID = msg.R_ID;
    }

}

I have released software to the world using the above interface and now I need to add a piece of additional data to this interface "Where"

public interface IMessage
{
string ID { get; }

string R_ID { get; set; }

DateTime Send { get; }

string Where { get; }
}

My question : Will adding this piece of data break existing clients in the field?

If so, how I can I update the interface / concrete classes so existing clients don't break?

Thanks

Additional info:

The SMessage is the base class for other messages that are sent within the application:

public class InstallMessage : SMessage
{
}

public class ChangeState : SMessage
{
}

How can I keep from breaking existing clients?

So, if I do this:

public interface IMessage2 : IMessage
{
string Where { get; }
}

And this:

public class SMessage : IMessage2
{
 // the correct implementation for IMessage2 is added and omitted here for brevity
}

So what I am unsure about is how do I handle the case where I don't know if the message is from IMessage2 or not? ( NOTE: this code is in the client and server applications )

EXISTING CODE IN THE FIELD:

public void ReceiveChange( ChangeState msg )
{
    string x = msg.ID.ToString();
}

NEW CODE THAT WILL BE SENT OUT WITH NEXT VERSION:

public void ReceiveChange( ChangeState msg )
{
    string x = msg.ID.ToString();

    // do I need to do some converting to keep from breaking ?
    IMessage2 iMsg = msg as IMessage2;
    if( iMsg2 != null )
    {
       string y = iMsg2.Where;
    }
}

Thanks

Answer 1

If in an WebAPI scenario.

It will only break existing clients if you have a dependency upon the newly added fields in a method that accepts IMessage as a parameter.

public void ServiceMethod(IMessage message) {
   if (message.Where == null)
      throw new ArgumentException("message.Where is null");
}

you can add things to interfaces and as long as you have code to properly handle the missing information existing clients will be fine.

The proper way to handle this though is to 'version' your services and data contracts. I find namespace versioning the easiest to maintain. You would define a new namespace (say v2) and redefine everything that actually changes, methods, data contracts, etc. And then in your routing, route the v2 messages (http://acme.com/api/v2/messages) to the new namespace or if not specially routed (http://acme.com/api/messages) route it to the old namespace.

If in a directly referenced library.

Then yes - it will break existing clients. Unless your factory that produces concrete implementations can determine which the client wants. Something similar to the WebAPI routing - but for directly referenced libraries. But this is extremely difficult.

Answer 2

Your interface's consumers won't complain, but the implementations will.

If you want to avoid this, then create a new interface that extends from the old one:

public interface INewMessage : IMessage
{
    string Where { get; set; }
}

Answer 3

Yes, it will break the existing clients if they implmented their own classes that use IMessage that do not derive from SMessage. This is the reason why Microsoft has not updated interfaces in the .NET framework between versions to add new features. For example in .NET 4.5 DbDataReader got new async methods that returned tasks but they could not update IDataReader because that would have broken anyone who implemented IDataReader without deriving from DbDataReader.

If you don't want to break the code of people who created classes with IMessage but without using SMessage you must either create a new derived interface that has the additional field (For example this is what COM objects do, you will often see ISomeInterface, ISomeInterface2, ISomeInterface3 etc.) or not update the interface at all and only update concrete implementations that other people may have derived from.