I have a reporting service that implements a number of reports. Each report requires certain parameters. Groups of logically related parameters are placed in an interface, which the report then implements:

[ServiceContract]
[ServiceKnownType(typeof(ExampleReport))]
public interface IService1
{
    [OperationContract]
    void Process(IReport report);
}

public interface IReport
{
    string PrintedBy { get; set; }
}

public interface IApplicableDateRangeParameter
{
    DateTime StartDate { get; set; }

    DateTime EndDate { get; set; }
}

[DataContract]
public abstract class Report : IReport
{
    [DataMember]
    public string PrintedBy { get; set; }
}

[DataContract]
public class ExampleReport : Report, IApplicableDateRangeParameter
{
    [DataMember]
    public DateTime StartDate { get; set; }

    [DataMember]
    public DateTime EndDate { get; set; }
}

The problem is that the WCF DataContractSerializer does not expose these interfaces in my client library, thus I can't write the generic report generating front-end that I plan to. Can WCF expose these interfaces, or is this a limitation of the serializer? If the latter case, then what is the canonical approach to this OO pattern?

I've looked into NetDataContractSerializer but it doesn't seem to be an officially supported implementation (which means it's not an option in my project). Currently I've resigned myself to including the interfaces in a library that is common between the service and the client application, but this seems like an unnecessary extra dependency to me. Surely there is a more straightforward way to do this? I was under the impression that WCF was supposed to replace .NET remoting; checking if an object implements an interface seems to be one of the most basic features required of a remoting interface?