WCF ServiceKnownType设计问题

Question

I'm designing a new solution that will consist of three projects:

"Server" - a WCF service

"Client" - a winforms app that will call the WCF service

"ServiceContract" - a class lib containing some base classes plus the WCF service contract (interface). This will obviously be referenced by the Server, and also by the Client (I'm using a ChannelFactory rather than have VS generate a service reference). The service contract looks something like this:-

[ServiceContract]
[ServiceKnownType("GetCommandTypes", typeof(CommandTypesProvider))]
public interface INuService
{
    [OperationContract]
    bool ExecuteCommand(CommandBase command);
}

It's a very basic operation - the client creates a "command" object and sends it to the server to be executed. There will be many different commands, all inheriting from CommandBase (this base class resides in the "ServiceContract" project). As I'm using the base class in the WCF operation signature, I have to specify the known types which I'm doing dynamically using the ServiceKnownType attribute. This references a helper class ( CommandTypesProvider ) that returns all types deriving from CommandBase .

I've created a simple proof of concept with a couple of derived command classes that reside in the "ServiceContract" project. The helper class therefore only has to reflect types in the executing assembly. This all works fine.

Now in my "real" solution these command classes will be in different projects. These projects will reference the ServiceContract project, rather than vice-versa, which makes it difficult (or impossible?) for the helper to reflect the "command" assemblies. So my question is, how can I provide the known types?

Options I've thought about:-

• The "Server" and "Client" projects will reference both the "ServiceContract" project and the various "command" projects. My helper could reflect through AppDomain.CurrentDomain.GetAssemblies() , but this fails because the "command" assemblies are not all loaded (I could force this by referencing a type in each, but that doesn't feel right - I want it to be a dynamic, pluggable architecture, and not have to modify code whenever I add a new command project).
• Specify the known types in config. Again it would be nice if the app was dynamic, rather than have to update the config each time I add a command class.
• Is there any way to access the underlying DataContractSerializer on both the client and server, and pass it the known types? I guess I'll still have the same issue of not being able to reflect the assemblies unless they've been loaded.
• Refactor things to enable the ServiceContract project to reference the various command projects. I can then reflect them using 'Assembly.GetReferencedAssemblies()'. I guess the various command classes are part of the service contract, so perhaps this is the way to go? Edit: looks like this has the same problem of only finding loaded assemblies.

Any ideas greatly appreciated! Is it something that can be achieved or do I need to rethink my architecture?!

Thanks in advance.

Answer 1

One thing to consider is using the DataContractResolver.

Few resources:

WCF Extensibility – Data Contract Resolver by Carlos

Building Extensible WCF Service Interfaces With DataContractResolver by Kelly

Configuring Known Types Dynamically - Introducing the DataContractResolver by Youssef

Answer 2

Thanks for the replies regarding the Data Contract Resolver guys. I probably would have gone down this route normally but as I was using Windsor I was able to come up with a solution using this instead.

For anyone interested, I added a Windsor installer ( IWindsorInstaller ) to each of my "command" projects, which are run using Windsor's container.Install(FromAssembly.InDirectory... . These installs are responsible for registering any dependencies needed within that project, plus they also register all the command classes which my known types helper can resolve from the container.