DSL Tools beyond VS2008

  • Article

I promised a while ago to publish a roadmap for what we're doing with DSL Tools, post VS2008. Now that VS2008 and the VS2008 SDK have just shipped (thanks Gareth for providing a post which points at both announecements) now seems a good time honour that promise.

There are two main themes in how we expect DSL Tools to develop in the future:

  • Evolve the graphical designer and code generation platform to provide more capabilities, to integrate better with other parts of the VS platform, to componentize it so it is easier to choose which parts you want to use, to better support extensibility and customization, and to improve performance.
  • Generalize the authoring approach pioneered in DSL Tools, to the creation and maintainence other kinds of Visual Studio extension, and integrate the DSL authoring experience with that. These are the tools to build tools that I've used as a tagline for my blog, although, in the context of Visual Studio, VSX Tools might be a better term.

I mentioned the second theme soon after the DSL Tools team joined the Visual Studio platform team. That is still in our sights and will be part of our roadmap for the VS SDK as a whole, which we'll publicize when it's ready. For the remainder of this post, I’ll focus on the first theme.

Roadmap for VS codename Rosario

Below is a list of features we have in the backlog for Rosario. We’re not promising to complete all of them, but expect to complete a significant subset. Some of the features may appear earlier in a service pack for VS2008.

  • DSL extensibility. This enables you to extend a designer that has already been deployed – i.e. without cracking open the source. An extension defines a set of domain class extensions (adding new domain properties, new relationships, new domain classes), which appear on elements of that domain class when the extension is enabled. An extension also defines a root domain class and a scope. You activate an extension on an element of the root domain class, and then all elements in scope also get that extension enabled. Extension activation is dynamic through the UI of the designer (we’ll provide some standard UI, and the base designer author will be at liberty to write their own custom UI). Multiple extensions may be activated on the same element. The root domain class for an extension may be the root of the domain model of the DSL being extended, which then allows an extension to apply to the whole model. Extensions may also define additional validation constraints, in the usual way. I’ll write a separate blog entry on this with more detail a bit later. The authoring experience for extensions will require support for referencing one dsl definition from another, which will also benefit customers who want to build a set of designers that share some parts of their definition (e.g. a common core set of domain classes).
  • Support for databinding of domain model to Winforms. Although it is possible to create a custom editor with a placeholder for you to write your own forms-based editing surface, and it is also possible to add new tool windows to supplement the graphical design surface, there is currently no support for easily binding the form to underlying model elements. This feature involves generating the appropriate APIs from a domain model so that the standard Winforms databinding experience can be used.
  • Nested shapes. Although there is some support for nested shapes, it is harder work than it should be to get them to work. This feature involves improving the overall experience and fixing some bugs in the runtime which currently need to be worked around.
  • Various fit & finish items, for example:
    • Print preview. Enable the print preview menu for designers built with DSL Tools, so that you do not have to print to a file in order to preview the page layout. Page setup already provides some control on how to layout the pages.
    • Search and replace. Enable search and replace to work with designers built with DSL Tools. You should be able to search for a text string and replace that string throughout the model.
    • Sticky tools on the toolbox. Once a tool is sticky, you don't need to keep going back to the tool to use it repeatedly on the design surface.
    • Standard layout options. The underlying framework supports a number of layout options. This feature would surface it through some standard UI in the generated designer.
    • Pan/zoom control. A pan/zoom control provided as part of the standard UI in the generated designer, rather than having to custom code this as you do now.
  • Provide better support for orchestrated code generation. At present we have a button in the solution explorer for executing all templates in a solution. It is possible, with a little custom code, to hook templates up to a menu command (there's an example in our book), and then write code which does things like apply the same template multiple times to a model, generating a new file for each application. One option for improving this (though we're not fully decided yet) is to hook code generation into the build system, using MsBuild to coordinate it, and make it easy to write custom build actions that do the kind of things you can do when you launch code generation off a menu command. 

Post-Rosario

The two main investments we’re considering post-Rosario are:

  • WPF-based design surface. We'd like to replace the current graphical design surface with one founded on WPF (WIndows Presentation Foundation). Not only will this open up many new possibilities in the quality of visualization that one can achieve, we also believe it will make it much easier to customize the graphical notation. At the same time, we'd take the opportunity to componentize the architecture, so that it would be possible to bind a graphical design surface built on top of this component to other data sources, such as XML or a database.
  • First class support for cross-referencing between different models and multiple views. This has been requested many times by customers, although it's also interesting to note that many customers have been able to achieve their scenarios by writing custom code.

Well, that's all for now. Please provide your feedback on this. What do you like? What don't you like? What's on your wish list?

Comments

  • Anonymous
    November 22, 2007
    Now Visual Studio 2008 is released (I know, I'm blogger #100.000 to mention this) it is interesting to

  • Anonymous
    November 22, 2007
    Thanks for this amazing (SDK) piece of software, the scope and possibilities are endless. Even without WPF and all the features you mention for the next release this SDK opens up a whole world.

  • Anonymous
    November 23, 2007
    I would like to have a generated-model without requiring Microsoft's assemblies. As I am following a <a href="http://www.himalia.net/blogs/leovernazza/2007/11/models-runtime.html">runtime approach</a> for the end-user (not the dsl user, but the end user), I require the model assemblies not only in the dsl user machine but in the end-user one. I don't want to be tied to the Microsoft policies with my end-user-runtime.. (can I distribute them?,  does the user need VS?, etc.) My approach so far, has been to create my own model, and use the dsl-generated-model as a bridge. It could be far better to automatically use your model... I can also rewrite the model-generation templates. This will be probably my next step... Thanks for publishing the roadmap...

  • Anonymous
    November 23, 2007
    I’m sure you know that Visual Studio 2008 has shipped, but did you also know that the Visual Studio 2008

  • Anonymous
    November 26, 2007
    Stuart has blogged a roadmap of future plans for DSL Tools.

  • Anonymous
    November 26, 2007
    Buenas hace unos días Stuart Kent nos comentaba en su blog parte de las ideas que guían el Roadmap para

  • Anonymous
    November 26, 2007
    Buenas hace unos días Stuart Kent nos comentaba en su blog parte de las ideas que guían el Roadmap para

  • Anonymous
    November 26, 2007
    Buenas hace unos días Stuart Kent nos comentaba en su blog parte de las ideas que guían el Roadmap para

  • Anonymous
    November 26, 2007
    "Although it is possible to create a custom editor with a placeholder for you to write your own forms-based editing surface" Are there any examples or guidiance on this? As this is the exact scenario I'm trying to investigate if DSL Tools is a valid solution for our problem. I'd love to have the DSL designer in our client winforms app, without having to customize the VS Shell.

  • Anonymous
    November 26, 2007
    Stuart Kent has posted a roadmap for DSL Tools for VS Rosario and beyond. This one (post-Rosario, ie...

  • Anonymous
    November 26, 2007
    In response to BrentP: There's an example of how to do this in our book, with sample code on the website www.domainspecificdevelopment.com In the DSL Designer, you delete the editor node in the explorer, then add a new custom editor to replace it (note that you'll lose all your toolbox entries when you do this). When you regenerate and rebuild you'll find there is a build error with a comment in the generated code with instructions on the method you need to provide. Note, however, that we only currently support the scenario where the designer is hosted in a VS shell, including the new customizable, and freely distributable VS2008 shell.

  • Anonymous
    November 26, 2007
    This is a development roadmap for the DSL Tools published by Stuart Kent: DSL Tools Beyond VS2008

  • Anonymous
    December 03, 2007
    The comment has been removed

  • Anonymous
    December 03, 2007
    Hi Stuart, Thanks for publishing the information about the plan.  I would honestly like to see "First class support for cross-referencing between different models and multiple views" sooner rather than later. If it is later, could you either maintain or "open the source" to the DIS powertoy (it contains great references about how to load and inspect the model so that you can cross reference models). I would also like Microsoft to provide better template highlighting - without the need for clarius 74 template highlighter (it is a great editor however). I would also like to have the ability have a template run across all models of a certain type so the following template directive: <#@ DALRepositoryLanguage processor="DALRepositoryLanguageDirectiveProcessor" requires="fileName='........Data Access ModelSample.repos'" #> might read: <#@ DALRepositoryLanguage processor="DALRepositoryLanguageDirectiveProcessor" requires="fileName='........Data Access Model*.repos'" #> This will stop me from having to hard code my model file into the template. Thanks for your time. Kind Regards, Paul Kinlan

  • Anonymous
    December 04, 2007
    Hi, futhermore to my previous comment. I would love to see some extra shape types as standard, one such shape could be a UML style lifeline.  I belive one could custom code this but it is a lot of effort and would be specfic to a developer and not the community as a whole.  Is this type of extensibilty where you see WPF for the designer surface being used? Kind Regards, Paul Kinlan

  • Anonymous
    December 04, 2007
    Another thing that I would like to see is better support for multiple output files from a single template. I would also like to see templates be able to perform actions inside vs ide against the ide, such as create project at transform template time. I would also love to see the directive processor (if I am correct) expose custom events that can be consumed by the application transforming the templates and also have the events triggered by "directives" in the template. Kind Regards, Paul Kinlan

  • Anonymous
    December 06, 2007
    Paul - thanks for all your suggestions. We hear you on better orchestration for code generation, multiple input/output files etc. and work in that area is on the backlog. I note your request about doing cross-referencing sooner rather than later. You can custom code the lifeline ('cos I've seen it done), but you are right that the move to WPF is intended to make it much easier to customize the design surface, as well as open up a new world of possibilities.

  • Anonymous
    December 11, 2007
    This is indeed the most elegant piece of software I have ever seen (and I really mean it). Now I guess we agree that DIS is not a serious implementation for cross-referencing. So I would also like to have cross-referencing sooner rather than later. The current lack of serious cross-referencing is, I believe, the key feature that is preventing unconditional adoption of Microsoft DSLs. As an example, just think about the enterprise-wide reuse of partial data contracts (in different DSMs) without cross referencing. Or think about any analysis level language: For example a business process modeling language. Or a language to model scenarios. A language to model human interactions.... These absolutly need easy cross-referencing, because, by definition, they do not represent real implementation that might (as a work around) link different items at the code level (vs at the model level). Without such cross-referencing features integrated in the DSL toolkit, implementation of DSM interoperability tend to be applied only to situations where each isolated model maps to a specific piece of code and it is some other code (created by hand) that is providing the links. Thanks to you, we can raise the level of abstraction using discrete DSMs. It would be really great if we could raise the level of abstraction on DSM references, views, composition and navigation as well... sooner than later. Cheers Alain

  • Anonymous
    January 15, 2008
    This month's letter includes information about what the VSX team has been working on in the past few

  • Anonymous
    January 18, 2008
    hi, presently i am working on DSL tools +VS2008 but i dont know enything about it, is there any samples how to quickstart with DSL tools in VS2008

  • Anonymous
    March 31, 2008
    There are some rumbling on the software factories from MS. It has been nearly 4 years since Jack Greenfield articulated Microsoft Software factories vision. He talked about state of software engineering in his famous book.

  • Anonymous
    May 31, 2008
    I promised a while ago to publish a roadmap for what we're doing with DSL Tools, post VS2008. Now that VS2008 and the VS2008 SDK have just shipped (thanks Gareth for providing a post which points at both announecements) now seems a good time honour tha