WCF (Windows Communication Foundation) is a great think. If you ever though supplying and consuming web-services with .Net 1.1 & .Net 2.0 was easy – think again! WCF goes a long way to even reduce the burden of this process!

OK, so you’re all excited about using WCF and setup your service-contract by defining an interface like this:

[ServiceContract]
public interface IReviewService
{
[OperationContract(IsOneWay=true)]
void InitiateReview(IReviewTrigger reviewTrigger, IDocument reviewDocument);
}

As you can see, I used interfaces as ther parameters for my operation-contract. Within the application I’ve a concrete implementation of the IReviewTrigger as well as the IDocument interfaces, So now you go ahead and consume your service in an application like this:

ChannelFactory<IReviewService> factory = new
ChannelFactory<IReviewService>("WorkflowDmsReviewServiceEndPoint");
IReviewService myService = factory.CreateChannel();
ReviewTrigger myTrigger = new ReviewTrigger();
Document myDocument = new Document();
myService.InitiateReview(myTrigger, myDocument);

But this is a booboo. You will get an exception from the service-host, that an object of type ReviewTrigger was not expected. Well, what should I say – the contract defined IReviewTrigger instead of ReviewTrigger. I would consider this to be a shortcomming of WCF … but who is asking me!!

Well, after struggeling with this for quite some time (and being stubborn not to use the concrete class in my operation-contract!) I found a solution. Aaron Skonnard blogged about using a NetDataContractSerializer instead of the built-in serializer … and all over sudden this works!!

Follow-Up: I finally did give up on passing complex types (objects) to operation contracts; instead I’m only passing the primary key of my object to the operation contract. This is reducing the overall overhead and eliminates the necessarity of the NetDataContractSerializer. I just read my Trigger and Document from the above example from my data-layer instead.