Stuart Kent - Building developer tools at Microsoft - @sjhkent

  • stuart kent's blog

    So what is a DSL anyway?


    The term Domain Specific Language (DSL) is a popular buzz-word at the moment. If you look at wikipedia you’ll see the following definition:

    “In software development, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn't new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling.

    The opposite is:

    The problem I have with this definition is that it’s hard to draw the boundary between what is general purpose and what is domain specific. Instead, I prefer to think of a language having different dimensions, and to categorize a language we need to place it on each of the dimensions relative to other languages. This leads to a much more fluid categorization system, but makes it easier to identify the similarities and differences between languages. Below is a diagram I produced recently for a talk showing three dimensions. I think there are more, but these three seem quite important. I put some examples on the diagram to illustrate.


    And as a tool platform vendor, I’d like to provide facilities for creating and using languages in as many points in that 3-dimensional (though probably should be n-dimensional) space as possible. I also want to provide ways of moving between languages at different points in the space.

    What might other dimensions be? Martin Fowler makes the further distinction between internal and external DSL, so perhaps that might be another, though in that case I might concede that the dimension is binary: external xor internal, and no points between. Another might be formal/informal dimension.

  • stuart kent's blog

    More from Code Generation 2009


    Now I’m back from the conference, here’s an update on my first report.

    Some highlights for me during the rest of the conference were:

    • Seeing the second part of the joint keynote by Markus Völter and Steven Kelly, where they got to discuss views, cross-references and interaction between models. It felt good to finally have an answer for this difficult area with the new modelbus in VS2010 (see my previous post on this).
    • A great goldfish bowl to discuss the question: does modeling = programming? We got as far as agreeing that executable modeling = programming, so programming was regarded as a subset of modeling, and that we need many of the tools we use for programming at the modeling level (debug and test models, anyone?). However, there was some discussion of whether there are some mdoels which aren’t programs (I argued that there were, giving examples such as business & performance models, models showing metrics for coverage, completion and so on), although conceded that these models indirectly influenced the eventual shape of the program. There is a bit of a slippery slope here, because then one could argue that they are part of the description of the program in some way, and therefore then part of the program. Mmm… all getting a bit philosophical for me. One nugget that did come out was the fact that modeling tools (at least graphical and forms-based ones) don’t let you model informally very well, and then incrementally change the informal to formal. You kind of get this for free with a text editor, because you can write pseudo code in comments and then step-by-step formalize that building as you go, until you get a successful build, at which point you can try executing the code which then leads you to a further step of validation.
    • Lots of interesting conversations, including a discussion on code generation on the MSFT platform with Kathleen Dollard.
    • Positive feedback received on the DSL Tools and T4 features we’re shipping in VS2010. Jean-Marc gave a session on this, which was well-received with lots of questions afterwards from folks wanting to know more. Folks particularly like the aforementioned modelbus. Indeed I came away with the general feeling that Visual Studio 2010 provides a solid, competitive platform and set of tools for those wanting to do model-driven development, whether it is from their own DSLs, from UML or some integrated combination of the two. 
    • Feedback received from a number of people, who have tried using both Eclipse GMF and DSL Tools, and who told me how much easier it was to build graphical designers using DSL Tools than GMF. We’re often told how hard it is to extend Visual Studio in comparison with Eclipse, but here is one area where it looks like we are some way ahead. I think folks will be surprised at the the new functionality put into the core Visual Studio platform in 2010, with the VS Extension Manager and Managed Extensibility Framework. We’ve exploited this already in DSL Tools, and have been working on exploiting it further to make the new Team Architect tools really easy to extend – but you’ll have to wait for the next preview after VS 2010 Beta1 for that. The new editor can also be extended using these mechanisms: see

    [Added on 23rd June 2009]

    I missed another highlight. There was a demo of Jetbrains Meta-Programming System (MPS). Although perhaps not for the masses, I thought this was conceptually very clean and nicely done. Great interactive session as well.

  • stuart kent's blog

    IMS Locks Sample for VS DSL Tools 2010 Beta1


    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.

  • stuart kent's blog

    News from code generation 2009


    I’m at the Code Generation 2009 conference in Cambridge, which started yesterday.

    Numbers are a little down on last year, but not much. Attendance is mostly from industry, with some academics. As usual it’s stuffed full of people with tons of experience in building code generators and languages to drive them.

    I gave a talk yesterday which placed model driven development and code generation in the wider context of what I called the design cycle (see image below). Perhaps I’ll write it up as an article on this blog someday. I also illustrated this with a demo of some of the features of Visual Studio 2010, including the new tools for visualizing existing code through graphs.


    Interesting panel yesterday on migrating to model driven development. There is real, concrete data out there which demonstrates the productivity benefits of an MDD approach. Why is it, then, that everyone isn’t doing it? Lots of discussion, with the top reason being social and cultural issues. It was also suggested that tooling isn’t good enough for broad use.

    I’m sitting in the keynote which has an interesting format: the two invited keynote speakers (Markus Völter and Steven Kelly) decided to join forces and give a joint talk spanning the two sessions. I like it, especially when the speakers argue (e.g. textual DSLs, which Markus favors, versus graphical DSLs, which Steven favors; actually they concluded that a platform which integrates and supports both would be best).

  • stuart kent's blog

    ModelBus Adapters Project Template


    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.

  • stuart kent's blog

    DSL Tools VS2010 Beta1: ModelBus Sample


    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 (, 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.

  • stuart kent's blog

    Much simpler deployment of DSLs in VS2010


    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.

  • stuart kent's blog

    Speaking at Code Generation 2009


    I’m speaking at the Code Generation 2009 conference in Cambridge in June on the topic of Code-Centric or Model-Centric – Approaches to developing software.

    Jean-Marc is also speaking on What’s new in the DSL Tools and T4 in Visual Studio 2010.

    I’m really looking forward to going to this conference which is at the cutting edge of model-driven and code generation techniques. It will be great to meet up again with folks I haven’t seen for some time, especially colleagues I used to work with before I joined Microsoft.


  • stuart kent's blog

    T4 Roundup


    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:

    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.

  • stuart kent's blog

    Migrating DSLs to VS2010 Beta1


    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.

  • stuart kent's blog

    DSL Tools for Visual Studio 2010


    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.

  • stuart kent's blog

    Back with Team Architect


    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:

    1. 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.
    2. 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.
    3. 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.

  • stuart kent's blog

    Teach yourself DSL Tools


    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:

  • stuart kent's blog

    DSL Tools and Oslo


    The Oslo modeling platform was announced at Microsoft's PDC and we've been asked by a number of customers what the relationship is between DSL Tools and Oslo. So I thought it would be worth clearing the air on this. Keith Short from the Oslo team has just posted on this very same question. I haven’t much to add really, except to clarify a couple of things about DSL Tools and VSTS Team Architect.

    As Keith pointed out, some commentators have suggested that DSL Tools is dead. This couldn’t be further from the truth. Keith himself points out that "both products have a lifecycle in front of them". In DSL Tools in Visual Studio 2010 I summarize the new features that we're shipping for DSL Tools in VS 2010, and we'll be providing more details in future posts. In short, the platform has expanded to support forms-based designers and interaction between models and designers. There's also the new suite of designers from Team Architect including a set of UML designers and technology specific DSLs coming in VS 2010. These have been built using DSL Tools. Cameron has blogged about this, and there are now some great videos describing the features, including some new technology for visualizing existing code and artifacts. See this entry from Steve for details.

    The new features in DSL Tools support integration with the designers from team architect, for example with DSLs of your own, using the new modelbus, and we're exploring other ways in which you can enhance and customize those designers without having to taking the step of creating your own DSL. Our T4 text templating technology will also work with these designers for code generation and will allow access to models across the modelbus. You may also be interested in my post Long Time No Blog, UML and DSLs which talks more about the relationship between DSLs and UML.

  • stuart kent's blog

    DSL Tools in Visual Studio 2010


    The first public CTP of Visual Studio 10

    Anyone attending or watching the goings on at Microsoft's Professional Developers Conference (PDC) will have heard about the next version of Visual Studio.

    If you were at PDC, you will have received a VPC containing a Community Technology Preview of Visual Studio 10. If you were not, you might know that you can download it at: Visual Studio 2010 and .NET Framework 4.0 CTP.

    What about the DSL Tools?

    If you are interested in the DSL Tools, and try this CTP, you might be disappointed not to find anything new in DSL Tools. This doesn't mean we haven't been busy. In fact we've been developing a number of highly-requested new features, but unfortunately did not get these integrated into this CTP release. We'll share them with customers in our next preview release.

    Also, in the CTP you'll find a suite of new designers from Team Architect, including a set of UML designers. These have all been built using DSL Tools, and some of the new features we're delivering are directly to support this effort.

    The new features

    So what are the new features then? Below is a summary. They've been driven by a combination of supporting internal teams such as Team Architect, and responding to customer feedback. We'll blog more about these features over the coming weeks, including, we hope, publishing some videos demo'ing them as a taster whilst you wait for the next preview.

    Dsl Libraries. Share fragments of DSL definitions between different designers.

    Dsl extensibility. Extend the domain model and behavior for a DSL after it's been deployed, including DSLs shipped by a third party.

    Readonly. Selectively switch off the ability to edit models and model elements in a designer.

    Forms-based UI. Easily bind models to winforms and WPF-based forms UI. IMS now implements the necessary databinding interfaces.

    Modelbus. A new piece of platform to support cross-referencing between models and interaction between designers. This has been one of customers' main requests.

    T4 precompile. Precompile text templates so that they can be deployed for use on machines that do not have VS installed. (This applies to scenarios where text templates take inputs from data sources other than DSL models. We've had requests from internal teams to use text templates in scenarios which don't use models created from DSLs.)

    UI enhancements:

    • Moveable labels on the connectors (moveably can be activated
    • Sticky tools in the toolbox
    • Quick navigation and editing of compartments
    • Copy and paste of selection as BMP and EMF images
    • Copy and paste of elements in the same or in different diagrams
  • stuart kent's blog

    Chinese version of DSL Book published


    Our colleagues in China have been busy translating our DSL Book into Chinese. It's taken 6 months and 9 translators. See for the story. The translation is available for sale online.

  • stuart kent's blog

    VSX Developer Conference


    We're holding our first Visual Studio Extensibility Developer conference in September. See for details, including information on how to sign up.

  • stuart kent's blog

    Vs2008 version of Dsl Book Samples


    We've finally converted all the samples for our book on Domain Specific Development for VS2008. They can be downloaded from

  • stuart kent's blog

    Agile platform development. The problem.


    Classic scrum

    Our team uses Scrum to manage it's software development. A key tenet of Scrum is that there should be a product manager (PM) who own's a backlog (that is, a ranked list) of customer facing stories. Scrum organizes development work into sprints, typically 3-4 weeks long. Before each sprint, there is a sprint planning exercise, where:

    • the PM communicates the stories to the engineering team
    • the team tell him or her what's possible and where the engineering dependencies are
    • the team estimate how long it's going to take to build each story, and, by identifying 2-3 day tasks required to develop that story
    • the engineering capacity for the sprint is worked out, taking account of vacation and other activities
    • they all agree what the main theme of the sprint is - what's the overall goal of their work this time round
    • with all that information the PM and engineering team narrow down the scope of stories, re-rank, and draw a cut line

    Need - build a (tooling) platform in an agile way

    Now I'm part of a team in the business of creating a tooling platform, including tools built on the platform to build other tools that work on that platform (tools to build tools). And my job as a program manager is to come up with those stories that can be used to drive sprint planning. And I also want to do it in an agile way, so that it can be managed by the same process, and in a way that fully exploits the creativity, ideas and expertise of all members of the engineering team for whom I have the deepest respect.

    Problem 1: Mind the gap

    A problem we've identified with classic scrum is that it doesn't take into account the often large gap between business need and the software solution proposed to fulfil that need. Indeed, the process assumes that somehow the product manager will pluck out of thin air customer facing stories which are fine-grained enough to make sense to feed into the sprint planning process. That may work if the project is about adding new functionality to an existing website, say, but with a platform it's not so obvious how this should work.

    Problem 2: Two or more customers

    When building a platform, you've got two customers at least. You have the customers who use applications built on the platform, and you have the developers who use the platform to build (author) those applications. I tend to call these users and authors. With a tools platform, there's also a third customer, which is the one who uses the applications built using the tools built on the tooling platform. This impacts the way you write scenarios/stories, specifically there are stories targeted at the user and stories targeted at the author. It also impacts the meaning of 'agile'. Platform has to be delivered in time for the authors to build the applications on that platform that their customer needs. If the author is running an agile process to build their application, then you're going to need to understand their stories some sprints before the author is going to implement them, so that you can get the platform pieces in place for them to build on in time. Or you try to do it all at once, but there lies a hornets' nest.


    After 5 years experience of doing this in Microsoft, I'm starting to get a handle on a process that seems to make sense, and I thought it would be fun to try and relate that process here and see what others think.

    So watch out for postings with a title of the form:

    "Agile platform development. ..."

    I'll also tag them as follows...

  • stuart kent's blog

    Catching Up


    So now I've found myself some time to get the blog started again with Long time no blog, UML and DSLs here's a little catch up on all things VSX and DSL.


    Jean-Marc Prieur has recently joined the team as a program manager. Jean-Marc is a colleague of mine in Cambridge, and it's great to have him join us. Jean-Marc will be helping with both product work and driving community activities in Europe.


    As usual, Gareth has been summarizing others'

    blogs with lots of interesting links. Take a look at Couple more VSX bloggers and A rash of bloggers. has recently published a paper about adding prototype (pattern) support to your DSL. There's a video to go with it.


    In case you missed it, VS 2008 SP1 Beta has been released, together with a matching SDK. See Visual Studio 2008 SDK 1.1 Beta has shipped from Quan for details. Service pack releases focus on fixing bugs and increasing overall quality. For the Dsl platform, we fixed some bugs around line routing when using nested shapes. For those of you who have our book, this means that you can follow the instructions on pages 443 to 446 to implement nested shapes, rather than adopt the workaround on pages 446 to 453. The bugs we fixed remove the problem described at the top of page 446. We also provided a print preview feature. Run your designer on SP1 and you should see this capability just appear.

    Technorati Tags: ,
  • stuart kent's blog

    Long Time No Blog, UML and DSLs

    Technorati Tags: ,

    Embarrassing, but true. Last time I blogged was back in February.

    I'm on one of my regular trips to Redmond, and jet lag still means I'm getting up at 4am. Usually on these trips I use the early morning to do a bit of work, then go for a run. However, last trip I stumbled on a tree root when out running and fractured my ankle. It's the first time I've broken a bone, so I didn't know what to expect. In fact, at first I didn't really believe the doctor; x-ray looked fine to me. Little did I expect that I'd be back in Redmond 7 weeks later, still limping and definitely unable to run. So I find myself with more time in the morning, and an opportunity to contribute once again to the blogsphere, though any readership I may have had has probably already given up on me.

    So what's there to talk about. As the title suggests, I thought I would touch on the subject of UML and DSLs given a recent post on UML + DSL from Cameron Skinner, who now leads Visual Studio Team Architect. In the article, Cameron talks about a new set of designers that Team Architect are working on, which includes some UML designers, as well as some graphical DSLs. The goal is to 'make modeling more central to a broader range of people' as well as to 'seamlessly connect the two approaches [UML and DSL]'. We've found that DSL Tools is very appealing to customers who've already bought into modeling. It allows them to create their own customized model driven solutions fairly quickly. However, for those not already into modeling it's a harder sell (although, we have had customers who have seen what others have produced and decide to build something similar which focuses on their domain). To really get modeling out to a broader audience it's necessary to have tools that people can use straight out of the box. I'm still convinced that if you want to dramatically increase productivity then you should be using DSLs driving code generators, or further model transformations, or visualizing abstractions discovered from existing artifacts, or some combination of all three. On the other hand, whatever your views are about the effectiveness or not of UML, it has significantly raised the awareness of modeling with a broad audience and it is something that many people are familiar with. So I'm really pleased that Team Architect has now stepped up to drive a strategy that delivers on both sides of the modeling coin, and connects them up.

    What is more, I'm really enjoying helping them deliver on this strategy by providing a great platform to build on. Because, as Cameron points out, many of the designers being built by Team Architect (including the UML ones) are being built on the DSL Tools platform. Not only is this further proof for the robustness and flexibility of this platform, it is also helping to drive new features into the platform which will benefit anyone wanting to build their own DSLs. We're not ready to talk about those features in detail yet, but my list posted a few months ago is still fairly accurate, although there are a couple of additions and some changes in priority. Worth calling out are the features to allow a designer to be extended with new metadata once it has been deployed, and support for designers and models to interact. This will allow the designers delivered by Team Architect to be extended, and for new, third party DSLs to interact with them. Both these are key aspects of connecting UML with DSLs in the UML + DSL story that Cameron speaks about. 

    Finally, you may also have noticed that Steve is changing his role, by going back to Team Architect in order to help them deliver on the UML + DSL vision. This means that Steve will be more of a consumer of the platform that he helped create, and I'm sure will be driving hard to ensure that it meets his needs. Steve and I still share an office in the UK and will still be working closely together. Should be a fun ride, this.

  • stuart kent's blog

    If you're a student, get Visual Studio Pro for free


    If you're a student, then Microsoft has just announced a new program called DreamSpark to get Visual Studio 2008 Professional Edition (and Expression Studio and Windows Server 2003 and XNA Game Studio and SQL Server 2005) for free.

    As Aaron points out, once you've got Visual Studio you can download the VS SDK (also for free) and start extending it.

    If there are any academics reading my blog (I'm hoping that some of my academic colleagues might take a peek now and again), please let your students know about this.

    Putting on my Lecturer's hat, I'd encourage all Computer Science students to try out both Visual Studio and Eclipse before they leave college, as it's very likely that a potential employer will be using one or other, and sometimes both. Also, the more experience you have with different development environments and programming languages the more transferrable and rounded your computing skills are likely to be.

  • stuart kent's blog

    More rapid deployment of VS extensions


    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.

  • stuart kent's blog

    Book on VS Extensibility


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

  • stuart kent's blog

    Quan started blogging about VSX


    Quan is a new (and, I should say, very productive) PM on the VS Ecosystem Team. He's now started blogging about VSX stuff, and good posts there are too.

    If your new to VSX then the following post might help you get into it. He's included both VB and C# versions of the code:

    Building your own Visual Studio Source Code Outliner extension

Page 2 of 7 (152 items) 12345»