Stuart Kent - Building developer tools at Microsoft - @sjhkent

May, 2007

  • stuart kent's blog

    Extending the capabilities of DSL Tools

    In my most recent post, I mentioned that the DSL Editor powertoy shows how you can exploit the openness of the DSL Tools architecture to extend the capabilities of the tools. Jezz pointed out to me that he has written up a general approach to extending DSL Tools in his blog, and indeed did so some time ago. I should pay more attention.
  • stuart kent's blog

    Next milestone of DSL Editor powertoy reached


    Jezz has just announced the release of the next milestone in this project. To quote:

    <quote>We released the next milestone of the DSL Editor PowerToy today on CodePlex.

    "A means to add multiple editors to your DSL, either hosted in a tool-window, or replace the graphical designer of your DSL"


    Thanks Jezz for implementing my suggestion of allowing the editors to be hosted in a a window that replaces the graphical design surface. When this powertoy is complete, it will be really easy to produce a forms-based DSL for languages which either don't suit a graphical representation, or where the effort of designing the graphical syntax is deemed not worth the investment. That's in addition to using the tool window in conjunction with a graphical surface. I'm really looking forward to the next milestone where we start to see some generated UI for the content.

    Also, related to my last post, it's great to see Jezz exploiting our approach of generating code from a dsl definition then allowing that code to be further extended through custom code. This has allowed Jezz to look for patterns in custom code you would need to write to implement his editors, and then add new code generators (and, his case, a new DSL as well) to generate to those patterns. This allows the capabilities of the tools to be extended by third parties, to cover all those bits we haven't thought of yet or haven't had time to implement.

  • stuart kent's blog

    Steven Kelly bashing us again


    I see that Steven is having another go at Microsoft's DSL Tools.

    Not for the first time, my impression is that he makes it look worse than it actually is. To quote:

    "As long as Microsoft thing of building modeling languages as a programming project, it's going to be impossible for them to make the changes they need to, without breaking existing modeling languages built with their tools. If they have the possibility to make major improvements to DSL Tools, my suggestion would be to go right ahead: the important market is those who have not yet been reached. Those brave enough to use CTPs, betas and version 1.0 knew what they were letting themselves in for.

    This is of course a problem with tools that require programming to build modeling languages, or a separate compilation step between the definition of the metamodel and using it to model with. In MetaEdit+, the metamodel is specified directly in the tool, with no programming, and models are made based directly on it, with no intermediate compilation. In other words, the metamodel is expressed as pure data, which makes both metamodel updates and tool updates easy and painless for the users."

    In DSL Tools, a large proportion of the code for a designer is generated from a dsl definition. If we make changes to the code generators, then to migrate to a new version is a matter of regenerating the code. If we make changes to the designer definition, then, in the case where those changes are not pure extensions to the designer definition language, we can provide a tool to migrate existing definitions across to the new format. If the designer author has written custom code to finish off their designer, then we could break that custom code if we make sigificant changes to the APIs it is written against, although there are various techniques that can be used to mitigate some of the pain (for example, deprecating APIs over versions). Now, as we add more features to DSL Tools, we will do our best to reduce the amount of custom code that designer authors will feel the need to write, but I think we'll always want to provide that outlet, as authors will always want to push the boundaries of the designers they wish to create beyond what we have thought about in advance when designing the dsl definition format.

    Now, I wonder what happens in the MetaEdit+ case. If the format in which the metamodel (dsl definition) is expressed changes (which it might if they want to add new features), then there has to be code somewhere which migrates metamodels expressed using previous versions to the new version. And I don't see how this is any different to us providing a tool (which may be integrated with the DSL designer itself) that migrates a dsl definition expressed in previous versions of the dsl definition language into newer versions. The difference in the two situations is that with DSL Tools, the extra custom code needs to be converted, but I wonder how much effort that really is, given appropriate guidance and the fact that significant changes to the APIs are not exactly frequent occurrences.

  • stuart kent's blog

    Published at last...


    Our book on DSL Tools is now available. Available at amazon and other online stores. You can also read it online at

    BTW, if you're interested in meeting with the authors, then you can find Gareth at Tech Ed in the USSteve at Tools Europe, and me at ECMDA and Microsoft Developer Days in the Netherlands.

  • stuart kent's blog

    Orcas version of DSL Tools now available


    A version of the VS SDK (download from, which includes DSL Tools, is now available for Visual Studio Orcas Beta 1. Gareth has the details.

Page 1 of 1 (5 items)