Random DevTools Entry: #009
Oh yeah, we’re kicking it up with the DevTool entries.
That’s typically what happens as I ramp up on a project; I’ll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page…I had to uninstall a lot of stuff previously to get it back down to two pages).
Today’s entries are tools to help you think “contract first”. I hadn’t really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.
Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists. I briefly contemplated using it for my .Net 2.0 project that I’m on now, but couldn’t bring myself to it; there must be a better way, right? Well, up until now, the only other .Net solution that I had come across was Matias Wozloski’s GAT implementation (with slight modification?) of Daniel Cazzulino’s (kzu) version of XsdObjectGen. Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I’m sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work. The resultant markup is not nearly as nice as the output from XsdObjectGen.exe. As I’ve mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu’s implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.
I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an “intelligent templating” approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn’t have enough time (and I probably didn’t have the rights) to extract and rewrite the codebase.
Enter dingo and thinktecture’s WSCF. While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?). WSCF, on the other hand, looks like it’s good to go with respect to .Net 2.0.
So have a look at WSCF. I’ll be downloading and evaluating it today and keep this updated with my take on it.
Update: See comments.
We’ve used WSCF on some recent projects. It worked really well. We used it to develop stub services while waiting for a provider to deliver services based on an agreed upon WSDL, which pretty much removed that project dependency until right before launch.
Highly recommended.
BAH! It still relies on the underlying XmlCodeExporter to generate the object class files though, which is really disappointing. I dunno…maybe I’m expecting too much? But the XsdObjectGen.exe implementation was nearly perfect. The one peeve (aside from many little nigglings) that I have with all of these implementations is that for list types, it generates the element name (XmlElementAttribute) as the plural form (matching the definition, of course).
With XsdObjectGen.exe, the generated element name was *not* in plural form.
For example, if I have an object Order that has a bunch of LineItems, XsdObjectGen.exe would specify the element names (using an XmlElementAttribute) as LineItem. So a sample fragment might look like so:
<Order>
<LineItem/>
<LineItem/>
</Order>
On the other hand, the generators that are relying heavily on XmlCodeExporter would generate:
<Order>
<LineItems/>
<LineItems/>
</Order>
It’s a subtle difference, but one that I don’t agree with very much. With kzu’s original library, I got around this by writing a custom extension that would remove the plural forms as part of the processing chain (along with a whole host of improvements over his base), but it wasn’t worth the effort when XsdObjectGen.exe did most of it and did it in a more agreeable manner.