DSL Tools Deployment – Domain-specific WiX or a DSL?

None other than Rob Mensching himself, the godfather of WiX, is kind enough to mention our new deployment feature on his blog. (And rest assured, we’ve already fixed our slightly embarrassing file extension typo bug 🙂 ).
As Rob says,

“The DSL Setup Project is a specialized setup package builder.”

i.e. it is a domain-specific setup builder (in the domain of creating DSL designers). Of course, as soon as we sniff this pattern in our code we do our darndest to dogfood. Consequently, the language used to specify the setup isn’t just a plain ol’ schematized xml file, rather it is a DSL tools language itself, albeit one without a graphical editor.  In actual fact we generate the XSD directly from the domain model definition.
You might be thinking that if the DSL tools make it so gosh-darned easy to create a graphical designer for any-old DSL, why didn’t we do it in this case? Well it’s a case of trying hard not to treat everything as a nail, given we have a hammer.
We get huge value out of going beyond schematized xml with this file; we can use our validation framework to do really rich validations of the file, far beyond what’s possible with XSD and we can process the file in our text templates using a nice friendly .Net object model rather than a using a nasty DOM or other non-domain-specific API. So it’s a no-brainer to use a DSL model.
However, it’s not so obvious that a graphical language would be a great experience for processing this model. As models go, it’s long on detail and lists and short on relationships (in fact it has no relationships). This screams “Forms-based UI” at me; some classes of model data are simply best expressed using traditional GUI elements rather than diagrams.
As the model is small, and the XML editor in Visual Studio 2005 is so good, we think the xml experience for editing this particular model stands up right now (unlike our designer definition file which we’ve heard loud and clear from you needs an editor).
Maybe we’ll create a WinForms-based editor for this model (we haven’t built bits to generate those automatically for a DSL just yet) or provide an InfoPath form for editing it. 
What do folks think about the experience of launching InfoPath from Visual Studio? Does everyone even have Office 2003 on their Dev boxes?
Comments (8)

  1. robmen says:

    Gareth, what does the "this model" refer to when you say: "However, it’s not so obvious that a graphical language would be a great experience for processing this model."

    I’m wondering if you’re talking about a general UI for the WiX toolset (which would be very interesting). I’ve seen people try to use InfoPath on the WiX language but the generated forms always seemed quite cumbersome to use.

  2. GarethJ says:

    Nope, I was refering to our Deployment DSL itself, which is generative of general purpose WiX.

    WiX itself seems to have plenty of cross references in it, which is one of the signs that it would be quite amenable to a box-and line style graphical language, although it also has heavy-duty detail, so I think you’d probably be looking at a hybrid, with diagrams for the large scale structures that are represented and referenced and something more terse such as GUI for the detail. As there’s a good deal of hierarchy, something structured in a tree like the DSL Tools Domain Model Designer might work out well.

  3. David says:

    I am very interested in the Infopath-as-an-editor idea, beyond the scope of the setup tool. I haven’t looked at DSL tools for a while, mainly due to the so called CTP madness. Since that is over, I’ll give it a try again. Here are some questions I have right now:

    Creation of XSD from domain model – is this automatically supported for any domain model I create?

    Once I have an XSD, it should be fairly easy to point Infopath to that and create a form, right?

    Also, for the future: Infopath 12 will have the ability to host forms as ActiveX or WinForms controls. It seems that this would allow one to build a new type of editor for a domain model with Infopath that runs inside VS. Is this something you guys are looking at for a V2?

  4. GarethJ says:

    RE XSD from domain model.

    There’s an intermim solution in today’s bits. We’ll replace this with something better in an upcoming CTP, but for now, on the DmdFileLoader class, you can call

    public static string GenerateXsdSchema(CdlModel model, string namespacePrefix, string namespaceName);

    from any text template to create a schema for your domain model.

    I didn’t know that about InfoPath 12 – that sounds very interesting.

    You can alos create a simplistic file reader for many domain models (doesn’t quite work with all) using the public static string GenerateModelReader(CdlModel model);

    method on the same class. This will read a model file conforming to the generated schema. All this will of course change, but it makes for quicker experiments at present.

  5. David says:

    I think this might turn into a slightly longer discussion. So I moved it over to the forums at


    Would be great if you could continue there!