Is it possible to include classes that are not used by service operations in the WCF service metadata?

advertisements

Per default, all data contract entities, involved in realization of service operation (and their known types, are include in service metadata. I am trying to find out, if it is possible in include other classes or data contracts in the metadata. The reason for this is that i have some enums, which can be used to fill in string fields of entities involved in service operation or, when service returns error messages, they have an identifier which I would like to "translate" or give a meaning to it without referencing some assembly form the external service.

Is such thing possible, or have someone other hints how to deal with this?

Illustrative example of service declaration would be something like:

[DataContract(Namespace = "http://schemas.example.com/Common/ExampleServices/V20090903")]
public enum SearchTaskField
{

    [EnumMember]
    Id,
    [EnumMember]
    Date,
    ...
}

[DataContract(Namespace="http://schemas.example.com/Common/ExampleServices/V20090903")]
public class SearchCondition
{

    [DataMember(Name = "ColumnName")]
    public virtual string ColumnName
    {
        get; set;
    }

    [DataMember(Name = "ColumnValue")]
    public virtual object ColumnValue
    {
        get; set;
    }

    [DataMember(Name = "ObjectType")]
    public virtual string ObjectType
    {
        get; set;
    }
}

[ServiceContract(Namespace="http://schemas.examle.com/Common/ExamleServices/V20090903")]
public interface IExampleServiceServiceContract
{

    [OperationContract(Name = "Search")]
    SearchOut Search(SearchIn messageIn);
}

[MessageContract]
public class SearchIn
{

    [MessageBodyMember(Name = "Conditions", Order = 1)]
    public virtual IList<Condition> Conditions
    {
        get; set;
    }
}


Service metadata is not intended for the purpose of defining an API. Only the types actually used by the service will be reflected in the metadata. If you want other types to be used by the clients, then you should do the exact same thing you would have done with a class library: put the shared types into a shared assembly.

Of course, this doesn't help clients not running .NET, but by attempting to expose random types, you've already moved away from SOA, so you shouldn't mind much.