WCF DataContract Class is not defined in Client Application

Question

I have a solution that contains a WCF Project and a Project for Data Classes, each class is owned as a "DT" class. Each of these DT classes are marked as a DataContract() with each property labeled as a DataMember().

    [DataContract()]
public class AttachmentDT : IAttachment
{

    private System.Int32 mAttachmentID;
    [DataMember()]
    public System.Int32 AttachmentID
    {
        get { return mAttachmentID; }
        set { mAttachmentID = value; }
    }

    private System.DateTime mCreateDate;
    [DataMember()]
    public System.DateTime CreateDate
    {
        get { return mCreateDate; }
        set { mCreateDate = value; }
    }

    private System.Byte[] mFileBytes;
    [DataMember()]
    public System.Byte[] FileBytes
    {
        get { return mFileBytes; }
        set { mFileBytes = value; }
    }

    private System.String mFileName;
    [DataMember()]
    public string FileName
    {
        get { return mFileName; }
        set { mFileName = value; }
    }
}

My WCF project has a class reference to the data classes project so i have access to these classes. If i do not use any of them in the WCF interface, the client application that uses the WCF cannot see the data classes either. Why is this? Must i seriously have to create an empty method for each data class that i want the client to see? For example in my WCF interface, i create a useless method...

    [OperationContract()]
    void AttachmentDT(AttachmentDT a) { }

If i have 20 data classes i want to give visibility too, i have to do this stupid crap for each? Please tell me there is a less ignorant way to get visibility to these DT classes.

Answer 1

I agree with Rahul. Your intentions does not make much sense to me, but if you still want to go there, i think you can achieve this by simply adding:

[ServiceKnownType(AttachmentDT)]

attributes on top of your wcf interface. That way you won't need those empty methods, and the service WSDL should contain those types, allowing any client who references your WCF service to generate proxies for them.

Answer 2

Aside from the usual issues like class visibility (public in your case) and missing the DataMember attribute (also not the case here), I usually run into this issue with duplicate types in referenced assemblies between client and server components.

Assuming you're generating the client-side proxy in Visual Studio, have you tried checking the "re-use types in referenced assemblies" option? I sometimes run into issues unless I reuse System.Runtime.Serialization.dll

Here's the MSDN tutorial on it: http://msdn.microsoft.com/en-us/library/vstudio/bb628653(v=vs.100).aspx

Answer 3

That's obvious right? I mean that's what we call Abstraction-encapsulation. Those Data classes are visible (if that have to be) only through WCF service layer. Client don't have (shouldn't have) any idea what those data classes are and what they do.

If you still want to explicitly have access to those Data classes and their members, you can always add a reference to those Data Class project DLL, to your client application; but which may not be recommended (OR) may not make much sense.

Answer 4

I concur with Roman adding [ServiceKnownType(...)] to my WCF service's interface, properly exposed all my data contract classes to the client.