stuart kent's blog : VSX

Extending UML designers in VS2010 Beta2

Stuart Kent — Mon, 02 Nov 2009 13:37:27 GMT

As mentioned in this post, the UML designers in VS2010 Ultimate now come with a set of APIs that makes them easy to extend. I see that Peter Provost has now posted the first of a series of articles (going by the title of this one) explaining how to get started: Extending Visual Studio 2010 UML Designers – Part 1- Getting Started.

Jean-Marc blogs about DSL Tools in VS2010 Beta2

Stuart Kent — Mon, 02 Nov 2009 13:31:47 GMT

Back from holiday (in Cyprus, 30 degrees C, very relaxing thanks), and as I suggested might happen in my previous entry, I see that Jean-Marc has blogged about DSL Tools in VS2010 Beta2: We released the DSL SDK for Visual Studio Beta2 this morning.

IMS Locks Sample for VS DSL Tools 2010 Beta1

Stuart Kent — Tue, 23 Jun 2009 14:47:44 GMT

I see that Jean-Marc has just posted another sample on the DSL Tools Code Gallery landing page, this time about the new IMS Locks capability. This allows you to make some parts of your models read-only, which is good for situations where some users (say an architect) are allowed to make changes to some aspects of the model (say the core architecture components), and other users (say developers) are only allowed to make changes to other aspects (say the properties specifically focused on driving the code generators). As author of the DSL you have complete control in the locking policy used. More details in Jean-Marc’s post.

ModelBus Adapters Project Template

Stuart Kent — Wed, 17 Jun 2009 09:49:46 GMT

Jean-Marc has just posted a ModelBus Adapters project template on the Visual Studio Gallery. This template makes it easy to a modelbus adapter and adapter manager to your own DSL, which exposes your DSL for reference and access from other DSLs. This compliments the sample recently posted, as described in my last post.

DSL Tools VS2010 Beta1: ModelBus Sample

Stuart Kent — Thu, 04 Jun 2009 01:07:42 GMT

One of the most common asks from customers of the DSL Tools has been support for integrating models and designers, that is the ability to have models of the same or different DSL cross-reference one another, and the ability to write simple code that exploits these cross-references to implement interesting interactions between designers.

In VS2010 we’re providing this support which can now be previewed in VS2010 Beta1 release. Jean-Marc has just posted a sample (StateMachineOverModelBus.zip, documentation) that illustrates how the modelbus can be used to achieve the behaviors described above, and I’ve just posted a short video demonstrating the behaviors and giving a quick insight into what you need to do to realize them in your own designers.

Details on how you can provide feedback can be found on our the DSL Tools Code Gallery landing page. Or by all means provide feedback on this blog.

Much simpler deployment of DSLs in VS2010

Stuart Kent — Sat, 23 May 2009 01:54:51 GMT

In Visual Studio 2010 you’ll find a new extension manager that makes it much easier to package and deploy extensions to Visual Studio. Pedro has more information: Early Buzz on the VS SDK and Extension Manager, Introducing VS Extension Manager.

We’ve exploited this to deploy DSL Tools. Gone has the DSL Setup project which used WiX to create and MSI. Instead, a DSL authoring solution builds a VSIX package and uses that to install the DSL in the experimental instance of Visual Studio. But even better, to install the DSL in the main instance of Visual Studio, all you have to do is open the VSIX file in windows explorer and respond to the prompts. Restart Visual Studio and your DSL is installed! How easy is that?

I’ve captured all this on video.

T4 Roundup

Stuart Kent — Sat, 23 May 2009 00:39:25 GMT

Gareth has been posting a lot about T4 over the past few months. In case you missed it, here’s a roundup of all his posts, in chronological order. Lots there to get your teeth into.

You can now try out the VS2010 features mentioned above with the release of VS2010 Beta1, VS2010 SDK Beta1, and VS2010 DSL SDK Beta1: see Dsl Tools for Visual Studio 2010.

I’ll also add one more link:

http://tangibleengineering.blogspot.com/2009/05/tangible-t4-editor-for-visual-studio.html

As you can see, T4 is getting popular!

And for VS2010 there’s more to come on top of the features that Gareth describes. Not available in Beta1, but in Beta2 we’ll be providing support for accessing models in T4 via the modelbus. This will enable text templates to access models created with the new UML designers in Visual Studio and more enterprise-scale orchestration of code generation.

Migrating DSLs to VS2010 Beta1

Stuart Kent — Sat, 23 May 2009 00:12:31 GMT

When we released DSL Tools for VS2008, the migration story from VS2005 was not great: basically we provided a sheet of manual instructions which led to a fragile and long-winded experience. This time we’ve done a lot better. In the VS2010 DSL SDK Beta1 you’ll find a migration tool that converts your projects and solutions for you automatically. We’ve been using this internally to convert samples, test projects and so on, and it does a lovely job. There are links to a video showing the tool in use, and some documentation on the Downloads tab of the DSL Tools Code Gallery. Life is good.

DSL Tools for Visual Studio 2010

Stuart Kent — Fri, 22 May 2009 13:41:26 GMT

It seems that my blog entries and those of some of my colleagues (Steve, Jean-Marc, Gareth) are like London buses: you wait for ages and then three come at once. And I’m definitely the worst offender – that bus which breaks down all the time.

Anyway, the reason why we’ve been so lax is that we’ve all been desperately busy getting Visual Studio 2010 out the door.

So it’s really exciting to announce the availability of DSL Tools for Visual Studio 2010 Beta1, hot on the heels of Visual Studio 2010 Beta1 itself and the corresponding Visual Studio SDK. Jean-Marc has all the details. We have a page summarizing the new features.

Various members of the team will be following up with blogs and samples, and we look forward to your feedback: the good, bad and ugly (actually, I’m sure you’re all extremely eloquent, so I don’t expect any ugliness). We’ll keep you up to date through the DSL Tools Code Gallery page.

Back with Team Architect

Stuart Kent — Wed, 03 Dec 2008 20:10:30 GMT

As Cameron blogged in Visual Studio Team System 2010 Architecture: Prologue, the DSL Tools team have recently moved back to Team Architect from the Visual Studio Platform team. We’ve been working increasingly closely with Team Architect since they renewed their focus on building VS modeling tools integrated using the DSL Tools. By moving back to that team we’ll be better placed to focus on three goals:

Evolve the platform to deliver a better experience for users of tools developed on that platform, including seamless integration with other tools used for software development (particularly those in Visual Studio), and rich productivity features for example around linking and transforming models. The experiences Team Architect have in mind will place strong demands on the platform; we can work closely with the teams building those experiences to make sure we get the platform right.
Evolve the authoring tools in the platform to make teams building tools using it more productive. This goes for teams inside Microsoft as much as for customers outside.
Provide a seamless experience for customization of the tools that we ship, from lightweight extensions of UML, through to patterns of integration and transformations layered on those tools, through to the creation of whole new DSLs which can be used in isolation or un harmony with the other tools.

We expect to make progress on all three goals in VS2010.

That said, our sojourn with the VS Platform Team was time well spent. We understand a lot better the technologies and the direction of the core VS platform and, just as importantly, know the people in that team a lot better. DSL Tools is layered on top of that platform and, already in VS2010, we’ll be taking advantage of the integration of the Managed Extensibility Framework (MEF) into the heart of VS (see e.g. this post) and the technologies underpinning the Extension Manager.

Teach yourself DSL Tools

Stuart Kent — Mon, 10 Nov 2008 15:33:43 GMT

Jean-Marc has just posted a lab on code gallery, which provides a fully worked, step-by-step example of creating a DSL from scratch. If you're new to DSL Tools, or want to teach others how to use them, then you may find this useful.

Nearly forgot the link. It's at:

http://code.msdn.microsoft.com/DSLToolsLab

Chinese version of DSL Book published

Stuart Kent — Mon, 11 Aug 2008 13:05:54 GMT

Our colleagues in China have been busy translating our DSL Book into Chinese. It's taken 6 months and 9 translators. See http://blogs.msdn.com/stbcblog/archive/2008/07/24/Domain-Specific-Development-with-Visual-Studio-DSL-Tools.aspx for the story. The translation is available for sale online.

VSX Developer Conference

Stuart Kent — Mon, 11 Aug 2008 12:42:26 GMT

We're holding our first Visual Studio Extensibility Developer conference in September. See http://msdn.microsoft.com/en-us/vsx/cc676517.aspx for details, including information on how to sign up.

More rapid deployment of VS extensions

Stuart Kent — Fri, 08 Feb 2008 14:50:00 GMT

Over on Deep's blog I came across the following comment to his post on Tools for Tools.

I had looked at creating a DSL for one of our projects a while ago, and in the end decided against it because the deployment was too complicated. In particular, here is how I want deployment to work:

In my normal solution of my project, I add a new DSL project, along with my other C# projects that constitute my end piece of software. In the DSL project I define a new DSL that I can then use right away in the C# projects that are part of the solution as well. That is, I don't want any setup at all, but rather want the DSL to be loaded as for example WinForm custom controls and the designers that go along are loaded from a dll project that is simply part of the solution of the consuming project.

Why is this so important? First, this would automatically solve the version problem. In my case we would rapidly (or shall I say "agile" ;) change the DSL as the project goes along. With a model where the DSL is installed wia a setup program on a machine wide basis, we run into huge trouble when we want to work with a previous version of our source code (say a branch from the source code repository that corresponds to a previous version). We would need to make sure that our DSL project can always load old versions, i.e. we would need to be super backword compatible. But I don't want that, I want the DSL versioned along with the source code so that I get a predictable match of tools and source code artefacts.

Also, of course, deployment via setup is just a pain, I really just want my solution file to have all the info about tools (be it DSL, compilers what have you) needed to build it and take care of that.

Any chance that we might end up with something like that?

Generalizing this scenario a bit, I think what the commenter is asking for is the following two capabilities:

1) For VS extensions (in this case DSLs) to be checked in the rest of the code on a project, so that you can manage the tools used to build your code just in the same way that you manage the code itself.

2) Not to have to go through an expensive process (e.g. install an MSI) every time you want to reconfigure VS with the tools (extensions) needed for a particular project, or when you want to update those tools.

There are things you can do now to get over these two problems.

For (1) you can have a separate tools authoring solution that is checked in and used to rebuild the tools. You can do this now, and I don't see any issues around this. Indeed I would argue that it's not a good idea to mix your tools authoring solution and application development solutions, just because I think it's a good idea to keep these two concerns separate. However, you still need a way of getting revisions of tooling quickly out to developers, rolling back to past versions and so on. And making sure that before you build your application code, the right version of the tools is built and installed.

For (2), if you don't want to go to the trouble of installing an MSI, then, today, you could do the application building in the experimental version of VS (though you'll need to have the VS SDK installed for that). Building the authoring solution will install the tools in the experimental hive, and then you just need to remember to launch VS Exp rather than VS to do your work. So once you've updated your machine from source control, you'd go an build the authoring solution, then you'd go an open the experimental version of VS and continue with your development. You can reset the experimental version of VS anytime to mirror main VS, when you want to switch projects.

An alternative is to work in virtual PCs (our team does much of its development this way). Then to roll out a new version of the tools to your team, you build a new VPC with the tools installed and distribute this. The advantage of this approach is that you can set up multiple VPCs for different projects and then it's very easy to switch between them. Of course there is more upfront cost taking this approach. This is a good solution if you are distributing tools to a team of developers, you want to retain some stability in the toolset they are using, and you expect developers to be needing to switch context between projects.

Ideally, what I'd like to see happen is that when a developer signs up for a Team System project, they get their machine configured automatically with the necessary tools, and, further, that designated members of the team (which could be anyone) can go and make changes and rebuild those tools, which then get pushed out to other members of the team via Team System. When you switch to a different project, VS reconfigures itself with the tools required for that project. This won't be achieved overnight - it requires some platform changes to VS - but it's certainly on the radar.

Book on VS Extensibility

Stuart Kent — Fri, 08 Feb 2008 13:56:25 GMT

I've just seen in the VSX newsletter that there is a book on Visual Studio Extensibility soon to be published. Details on http://nayyeri.net/.