Can I include classes not used by utility operations in WCF service metadata?
By default, all data entities involved in the implementation of a service operation (and their known types are included in the service metadata). I'm trying to figure out if it's possible to include other classes or data contracts in the metadata. The reason for this is that I have some enums that can be used to populate the string fields of the objects involved in the maintenance operation, or when the service returns error messages, they have an identifier that I would like to "translate" or give a value to it, without referencing any assembly, form an external service.
Is this possible, or are there any other clues on how to deal with this?
An illustrative example of a service declaration would look something like this:
[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 to define an API. The metadata will reflect only those types that are actually used by the service. If you want clients to use other types, then you must do the same as in the class library: put the generic types in a shared assembly.
Of course, this doesn't help clients who don't run .NET, but by trying to expose random types, you've already moved away from SOA, so it's not worth thinking a lot.
source to share
You can decorate your service with the ServiceKnownType attribute . This will result in the specified type being included in the metadata even if it is not directly used by the service contract (which does not participate in the graphing of an object of one of the other public types).
As you already did, you must mark the enumeration as [DataContract] and each value of the enumeration as [EnumMember]. Adding the following line to your ServiceContract interface will render the enum on the client.
Remember that you need to update the service link to see the changes in the generated code.
[ServiceKnownType(typeof(SearchTaskField))]
source to share
If you add [DataContract] to your enums, they should be automatically included in your metadata. This is the easiest way to do it.
You can also extend the way metadata is created and presented - in WCF you can extend just about anything :-) - but that involves a lot more code. One example is Christian Weyer " Aligning WSDL " Service Behavior "- he gets into the metadata creation process by adding endpoint behavior to his service endpoints.
Likewise, you can write your own endpoint behavior to extend your service, but again: just tagging the enum types with [DataContract] should be much easier.
Mark
UPDATE: I think your enum is not serializing to metadata as it doesn't seem to be used, or is this the wrong impression?
What happens if you, for example, add a field of this type "enum" to one of your DataContract classes? I would have thought that if it is actually used it will show up in your metadata ...
source to share