November, 2007

Pablo has written a series of posts that should be of help to anyone thinking of hosting their applications in the VS2008 shell:

Customizing a VS Shell application

Integrating a VS Package with a VS Shell application

VS Shell application deployment

Creating a bootstrapper for a VS Shell application

VS Shell and the registry

VS Shell application switches

In preparing for my presentation at TechEd, I got a chance to try out a couple of new things with DSL Tools on VS2008:

• The T4 editor from our friends over at Clarius, available at http://www.t4editor.net/. I installed the VS2008 beta 2 version on a VS2008 release candidate and it seemd to work fine. Makes editing text templates much easier. Nice job, Clarius. Can't wait for the other features promised in the future.
• Using LINQ to write validation constraints. I was blown away by the power of LINQ. Steve has a series of posts about using LINQ for this purpose - well worth a read.

Also for those of you who have wanted to automate the code generation step as part of the build process inside VS, here's a handy hint from one of our own MCS consultants, Jelle Druyts:

Add the following definition to the EnvironmentEvents macro (open Macro Explorer, MyMacros, EnvironmentEvents):

Private Sub BuildEvents_OnBuildBegin(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildBegin
        DTE.ExecuteCommand("TextTransformation.TransformAllTemplates")
End Sub

Then build and it’s done. This will now always transform the templates before any build. Very neat.

VS2008 and VS2008 SDK have just shipped. The announcement about the SDK over on the VSX blog didn't get into much detail about changes in DSL Tools for VS2008, so I thought it would be worth summarizing them here:

• The runtime is now part of the VS platform. There is no need for a DSL author to redistribute a separate DSL runtime.
• The authoring experience now works with Vista RANU (Run as Normal User). You don’t have to run VS as an admin in order to develop a DSL.
• We’ve added a path editor to the DSL Designer. Paths are used largely to express mappings between domain classes / relationships and shapes / connectors. The new editor provides UI that allows you to select valid navigation paths through domain classes and relationships in the domain model.
• LINQ can be used in code written against the code generated from a domain model, for example when writing validation constraints or text templates for code generation. For those of you familiar with UML / MOF, LINQ gives you OCL-like querying capability (actually its far more powerful than that) against domain models.
• We’ve fixed a large number of bugs, in both runtime and authoring.

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?