Stuart Kent - Building developer tools at Microsoft - @sjhkent

February, 2008

  • 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

  • stuart kent's blog

    Great links from Gareth


    Gareth is obviously settled in the US now, because he's starting to become a prolific blog poster again. Unlike me, who only manages it in spurts.

    He's recently put up a series of posts with some great links. So for those of you who don't already read Gareth's blog here's some stuff worth investigating:

    On code generation:

    Fun use of T4 to generate strongly-typed web navigation

    More general-purpose T4 goodness

    Help in tackling the hard problem of model -- code synchronization

    On using DSLs as part of Software Factories:

    Wojtek at Wicsa

    Team Architect Case Study with Software Factories

    On evolving DSLs:

    Gerardo explores domain-specific language evolution tools

    On getting started with VSX:

    Inovak learns VSX - Now!

    And finally, a video of a situation which I find myself in many times as part of distributed development team in Microsoft...

    Too much of life wasted on this soundtrack

  • stuart kent's blog

    Great posting on distributed development


    One of my colleagues (thanks Blair) pointed me at this:

    Our team is distributed between the US and UK and many of the points mentioned ring true in our experience. Eric stresses the need to maintain as high bandwidth communication as possible.

    We try and make maximum use of livemeeting and office communicator and use video cameras with those which makes a huge difference. And, by the way, I've discovered that connecting wirelessly to the newtwork introduces impedance which can really impact the reliability of those channels. Since I've stopped using wireless at home, I find I can trust those tools now.

    If any of you have your own experiences of distributed development which you'd like to share, pleas add a comment. 

Page 1 of 1 (6 items)