A way of using ASP.NET MVC-style attributes to generate restrictions in WSDL files generated through WCF. Hopelessly outdated now, but possibly interesting nonetheless.
This was built due to an odd set of requirements: the supplier that I was writing a service for insisted that a very particular WSDL be followed, despite them being the client of the service, and the service was required to generate the WSDL file systematically rather than just "faking" a static file, to ensure that the WSDL couldn't get out of sync with the service.
WCF has fairly loose restrictions schema-based data validation, only checking that something is a valid type for input to the service, so, for example, any integer may be valid by the WSDL even though only 6-digit numbers are actually accepted by the service. It is usually up to the service to then validate that information and return SOAP errors accordingly.
It was these two seemingly conflicting requirements that led me to research how WSDL/XSD restrictions were generated by WCF, discover the extensibility points (which were barely documented), and try to plug in my own restrictions.
WCF provides an extension point to allow injection of extra information into a WSDL file. The methods are all extremely general, don't offer much obvious guidance, and weren't well documented at the time, so time was needed to understand MessageDescriptions, OperationDescriptions, and MessagePartDescriptions, and various types of XmlSchemaFacet. I did this largely through the Immediate window, breakpoints on lots of empty functions implementing extension interfaces, and generating huge numbers of WSDLs to see what the in-box options could do.
The team implementing the service had some experience of ASP.NET MVC but none in WCF, and, other than me, were flat out on the actual functionality of the service. I built this specifically with the rest of the team in mind, allowing them to think of WCF services in much the same way as ASP.NET MVC controllers, and using the same sorts of data annotations they had become used to. About 30% of the complexity (basically, all of the reflection) here was in allowing reuse of the System.ComponentModel.DataAnnotations attributes.
Although the structure isn't particularly amenable to extension, the code is fairly clear and it's easy to see what I would need to do to add new types of restriction from here.
In the back of my mind at the time was the team's transition from MVC 3 to 4, so I was especially careful to not do anything too undocumented or seemingly version-specific. Looking back, I appear to have achieved this reasonably well.
This is pretty much unforgivable for a project in this vein: it should be reasonably simple (if possibly quite time-consuming) to build a set of decent tests that cover all of the major cases and confirm that attributes are being picked up, generating the correct entries in the WSDL, etc. At the time, I wasn't much good at building tests, and I hadn't made the shift to realising the benefit of building them even if they would have taken a while.
There is a nominal sort of structure to adding new restriction types here, but it requires editing a few different functions, and a richer (possibly abstract/override-based) setup would be substiantially neater. That said, this covered all the restriction types that were needed for the project, so it was good enough at the time.