Both WCF/EntLib integration for Validation and Exception handling are cool, but combining them is a bit tricky.

EntLib's Exception handling allows you to send a generic SOAP fault to a client if any Exception occurs within your service. This allows you to hide exception details from the client. Unfortunately a ValidationFault also gets translated to this generic service fault.

The solution: in the EntLib configuration, under your exception policy for your WCF service (usually named "WCF Exception Shielding" add an entry for the System.ServiceModel.FaultException and set it to NotifyRethrow besides catching System.Exception and throwing a custom SOAP fault in its place. The specific exception to rethrow would be FaultException<ValidationFault> but I'm not sure how to configure EntLib for this.

Fortunately the order is not important: the EntLib configuration tool orders the added exception types alphabetically so it automatically puts the FaultException after the generic Exception handler, but it works just the same.

Today I tried to handle a SecurityException through EntLib's Exception Application Block. I though it would be useful to rethrow it as a custom type name SecurityFault. Silly me, apparently a SecurityException gets translated to a System.ServiceModel.Security.SecurityAccessDeniedException.

Lessen: don't try this at home (or at work for that matter)...

I've seen some blog entries of people having trouble using VAB in WCF when a web service has a message contract. Apparently any contained DataContracts aren't validated.

After some fidgeting I found the problem: apparently the validation starts at the MessageContract. Just decorate the message body property (decorated with [MessageBody]) with [ObjectValidator].

The ObjectValidator is a validator that allows you to validate properties of a class containing properties decorated with validators. In other words; it allows validation of subtypes.