WCF - 传递未声明为 ServiceKnownType 的对象

Question

I have the following WCF interface that is exposed via net.tcp:

[ServiceContract]
public interface IMyWCFService
{
    [OperationContract]
    Response ProcessRequest(Request request);
}

This is driven by the following classes (much simplified for the purposes of this question):

[Serializable]
public abstract class Message
{
    [XmlAttribute]
    public string Sender { get; set; }
    [XmlAttribute]
    public string Recevier { get; set; }
}

[Serializable]
public abstract class Response : Message
{
    [XmlAttribute]
    public int EventCode { get; set; }
}

[Serializable]
public abstract class Request : Message
{
    [XmlAttribute]
    public string SourceSystem { get; set; }
}

[XmlRoot(Namespace="http://blah.blah.com/blah/")]
public class StringRequest : Request
{
    [XmlElement]
    public string Payload { get; set; }
}

[XmlRoot(Namespace="http://blah.blah.com/blah/")]
public class StringResponse : Response
{
    [XmlElement]
    public string Payload { get; set; }
}

Note: We use XMLSerializer rather than DataContractSerializer as these classes have to be compatible with legacy systems that are .NET 2 based.

As the interface uses the abstract Request/Response classes in the ProcessRequest method we have to declare StringResponse / StringRequest as ServiceKnownType , for example:

[ServiceContract]
[ServiceKnownType(typeof(StringRequest))]
[ServiceKnownType(typeof(StringResponse))]
public interface IMyWCFService
{
    [OperationContract]
    ResponseMessage ProcessRequest(RequestMessage request);
}

This works perfectly and all is good in the world, however.....

The WCF listener is just one component of a much larger framework and the classes described above are used throughout. We have also designed the framework to allow us to add new types of Request/Response messages with relative ease. For example I might add:

public class CustomRequest : Request
{
    public MyCustomXmlSerialisableRequestObject Payload { get; set; }
}

public class CustomResponse: Response
{
    public MyCustomXmlSerialisableResponseObject Payload { get; set; }
}

Which also works fine until I get the the WCF service interface. When we add a new custom request/response pair we also need to update the ServiceKnownType on the interface to include them. Which then means I have to redeploy the service. So the question is - is there any way I can avoid having to update the interface?

As an example when we used remoting we could pass through any objects we liked as long as they were serialisable so I assume/hope that there is a similar solution in WCF.

EDIT: Update

Following the guidance found here:

http://ashgeek.blogspot.com/2011/02/wcf-serialization-dynamically-add.html

I seem to be on the right track. However when I update the client service reference it pulls in all the dynamically types into the service reference. Which is undesirable as not all clients need to, or should, know about all messages that derive from Request/Response

More importantly I seem to lose the the ServiceClient class that is used to push messages, eg:

// Client proxy class goes AWOL after service reference update
var client = new MyServiceReference.Client();
var responseMessage = client.ProcessRequest(requestMessage)

Answer 1

At the beginning you are mentioning that you need compatibility with .NET 2.0 services but in the same time you are complaining that something which worked in .NET remoting doesn't work in WCF - you are limited by features possible with .NET 2.0 web services where both server and client must know about transferred types on the service layer = types must be in service description and WSDL. Moreover because you decided to use XmlSerializer you generally lost most of the ways how to achieve that:

• ServiceKnowType can load known types from static method
• KnownTypes defined in configuration (requires DataContractSerializer )
• DataContractResolver (only WCF 4) and loading all derived types on startup (requires DataContractSerializer )
• Passing .NET type information in messages (requires NetDataContractSerializer and custom behavior) = generally this is the same functionality as in remoting and it demands sharing types between service and client and both service and client must be .NET application using WCF stuff.

With XmlSerializer you have one option

• Return XElement and receive XElement in your service operation and deal with XML by yourselves - doesn't work in .NET 2.0

Edit:

There is no dynamic behavior in service description. It is created only once when the host starts and after that doesn't change until you restart the host. If you need subset of WSDL per client you need separate endpoint for each client and you must define exactly which data contracts should be exposed on each endpoint.