1

I'm in the context of a WCF service. I am trying to validate that my client sends me a valid contract.

In my company we have hundreds of data contracts. For us it makes sense that all value types, with the exception of Nullable<T>, should by definition be required to exist in the request message (otherwise we would want to explicitly wrap them in Nullable<T>).

I know I can mark my data members as required so:

[DataMember(IsRequired = true)]

But for value-types I would like to find a way to define it globally for the service instead of per data member. What would be the right WCF extensibility point to use in order to achieve that?

Additional info:

I've come across IDispatchMessageInspector and IDispatchMessageFormatter, but those would only let me process the entire message. Is there a better extensibility point where properties are already mapped by name to a target data member, but not yet instantiated into a .NET type? Or better yet, where I have access to serialization metadata of a single data member?

For reference as to what I'm hoping to find, when I applied a similar solution to our WebAPI which is based on JsonSerializer, I had a hook into the global configuration which allowed me to define my ContractResolver. So I derived from DefaultContractResolver and overrode:

protected override JsonProperty CreateProperty(MemberInfo member, MemberSerialization memberSerialization) {
  var property = base.CreateProperty(member, memberSerialization);

  if (IsNotNullableValueType(member)) {
    property.Required = Required.Always;
  }

  return property;
}
tsemer
  • 2,959
  • 3
  • 29
  • 26
  • Value types will exist in the request message unless you set `EmitDefaultValue` to false (the default is true). Note that if a value is not specified, the default value for the type will be serialized (e.g., 0 for `int`). This also applies to reference types (which would be `null` if not otherwise specified). – Tim Jun 29 '17 at 05:31
  • @Tim, I guess I failed to mention that I'm in a WCF service, not client, so when I was talking about the request message, I was talking about deserializing (reading), not serializing (writing/emitting). I'm trying to validate that my client sends a full contract message. I'll edit the question to make it clearer. – tsemer Jun 29 '17 at 08:48
  • Ah. Off the top of my head I can't think of any extension points that would do this for you. One option (though potentially a bit ugly, but based on what you did in WebAPI) would be to derive from `XmlObjectSerializer` (which is `abstract`) and see if you can do it there. `DataContractSerializer` is `sealed`, but inherits from `XmlObjectSerializer`. – Tim Jun 29 '17 at 16:41
  • Thanks, plugging in an entirely new serializer sounds like quite an undertaking and is probably an overkill for my requirement. Since I wouldn't like to serialize differently, only scan for invalidity, I would rather opt for one of the two extensibility points mentioned in my post. – tsemer Jul 05 '17 at 11:00

0 Answers0