Just what IS a DSL Tools designer?

Recently, an anonymous participant in our newsgroup posted to ask about building code in the debugging solution we provide with the templates in our December DSL Tools CTP. She'd built a DSL designer and was successfully using it to create documents.

Our DSL tools are designed to make it easy to use code to access the documents they create with an intuitive .NET API onto the domain specific model that you specify in our DMD editor. For example, if you have a model fragment like this

then you could expect a class Architecture with a collection of Components named Components.  The class Component would have a collection of Components called DependentOn and a property (perhaps) called Parent of type Architecture.

Our intrepid user was then taking advantage of this domain model API along with the simple code generator we provide in the build of each designer and our built-in code template technology to spit out some custom C# code of her own based on the DSL documents created in her designer.

She wasn't sure where or how to get this code to build in the solutions we provide from our wizard and I advised her that it should build in the Debugging project that the wizard generates.

I should note that the debugging project is really designed for getting to grips with the working of your designer, rather than as the way you'd use the designer in production to generate code.  Eventually we'd expect your end-users to use your new DSL designer in whatever Visual Studio solutions they'd normally work with.

What you've actually created when you use our tools to build a DSL designer is a new VSIP package.  Once you have a complete designer, you'd typically package it up with an installer and register it in the regular rather than experimental version of Visual Studio.  You'd also need to acquire and add a VSIP package load key before you could deploy your designer to regular Visual Studio users.

As we're strictly a community technology preview release, right now we don't have any tools or help to make this stuff simple. (Although you can achieve it technically by following the VSIP 2005 beta documentation).

In the fullness of time, we hope to be able to make deploying a designer you've created a fairly simple process.

I'd be interested to hear views on how much of VSIP we can afford to expect people to learn and how much we need to hide it behind simpler (but of necessity more restrictive) tools.