Question

I have an service Interface:

[ServiceContract]
[ServiceKnownType(typeof(Models.ArticleImage))]
public interface IPhotoManagementService
{
    [OperationContract]
    bool Login(string username, string password);

    [OperationContract]
    bool IsLoggedIn();

    [OperationContract]
    void UpdateImage(string articleID, string selectedImage);
}

As you can see I specify a typeof(Models.ArticleImage) on my ServiceContract.

So building the WSDL of this service should cause ArticleImage to pop up in the WSDL. Unfortunarly this doesn’t happen at all. Why is that?

ArticleImage has DataContract on it. And when I return an ArticleImage in my interface, then the WSDL does pick up ArticleImage.

Edit: it doesn’t even pop up in the service reference in the consuming project!

---

This is the result of a lot of testing:

• The model I’m trying to add is a LINQ to SQL model.
• When I add a normal model with ServiceKnownType it works.
• When I use my LINQ to SQL entities in my Interface it works.
• When I add my LINQ to SQL entity through ServiceKnownType it doesn’t pop up.

Answer 1

Why would it need to? Where does your service expose something that could possibly be an ArticleImage?

Re your comment; when using [ServiceKnownType], the extra trype is still exposed in the “mex” (consumed via “svcutil”) – but not by the WSDL. Are you using a WCF client? It should appear (I’ve just checked… it did). In general, though, returning vague data from a web-service isn’t a great idea… sub-types, sure! Dictionary<string,ArticleImage> or even Dictionary<string,SomeBaseType> (with [KnownType] etc), fine! But object, HashTable, etc – aren’t a good idea (IMO).

You might also just return a list of your type (List<ArticleImage>) which will work in all scenarios (and be easy for WSDL etc); and let the client make the dictionary at their end.

---

With regards to LINQ-to-SQL; objects for “mex” need to be decorated with [DataContract] / [DataMember]. You can do this in the designed by toggling the “serialization” property for the dbml. With this set (Serialization Mode = Unidirectional), it should work. To be honest, though, I think you be better-off just adding a dummy method that makes the type explicit on the API.