Random DevTools Entry: #009

You may also like...

2 Responses

  1. Jon Galloway says:

    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.

  2. Chuck says:

    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.