CODEWITHSUNDEEP
c#web-serviceswcf
Giardino
Giardino

Reputation: 1387

Reusing types with message contracts

I have a WCF service and a client and I want both to share the same class library so they both have access to the same types. My issue is that one of the classes is a MessageContract because it is an object that is used to upload files to the server via streaming. The class is as follows:

[MessageContract]
public class RemoteFileInfo : IDisposable
{

    private string fileName;
    private long length;
    private System.IO.Stream fileByteStream;

    public string FileName
    {
        set { this.fileName = value; }
        get { return this.fileName; }
    }

    public long Length
    {
        set { this.length = value; }
        get { return this.length; }
    }

    [MessageBodyMember(Order = 1)]
    public System.IO.Stream FileByteStream
    {
        set { this.fileByteStream = value; }
        get { return this.fileByteStream; }
    }

    public void Dispose()
    {
        if (fileByteStream != null)
        {
            fileByteStream.Dispose();
            fileByteStream = null;
        }
    }
}

This class is contained in a library that is shared between the server and the client. If I comment out the line that says [MessageContract] and then update the service reference, I am able to successfully share the type with the client and the service reference does not try to re-implement the type on its own. However, in order for streaming to work I need to make sure that this class is indeed a MessageContract so that the WCF service knows to only expect a single body member in the message and to deal with it appropriately.

If I uncomment the line that says [MessageContract] and update the service reference on the client side, it tries to re-implement RemoteFileInfo via the service reference instead of reusing the RemoteFileInfo that already exists in the library that both the service and the client are sharing. This means I end up with two of the same classes, MyClientProject.Shared.RemoteFileInfo and ServiceReference.RemoteFileInfo, which is ambiguous and causes the code to throw tons of errors.

I can get around it (sloppily) by commenting out the [MessageContract] line, updating the service reference, and then uncommenting the line on the service side before starting the service, so the client side thinks that it is just a normal class but the WCF service thinks its a MessageContract. This seems very silly to have to do and I am convinced theres a better way to do it. Any ideas?

Upvotes: 2

Views: 181

Answers (1)

tomasr
tomasr

Reputation: 13849

Since you're already sharing all your data contracts, what's the point of not sharing your service contract interface as well, and simply avoid doing code generation at all? That would make far more sense.

Upvotes: 3

Related Questions