Tools for Tools

Published 27 October 07 01:36 AM

As we come close to shipping VS 2008 SDK V1, I would like to talk a little about the future of the VS SDK and the plans we have around supporting the extensibility community.

We have been focussing a lot on the samples and tooling to make it easier for extenders to use the VSIP APIs and consume the VS SDK but now we are going to be changing the focus to build Tools for Tools. What this means is that we want to make it create Tools that make it easy for the VSX extenders to create the developer tools for the end users.

It has been challenging for the VSX community to create extensions and deploy these extensions. It is also tricky migrating extensions from previous versions of Visual Studio to a later version. VS Shell introduces another layer of complexity in sharing extensions. We are now taking this challenge and will try to provide solutions tha will make some of these tasks easier in future.

Make it easier to create extensions
–VSX DSL for defining packages containing commands, tool windows etc.
–Generate the skeleton code from a VSX definition
–Similar to experience that DSL Tools offers for creating DSLs

Make it easier to test and debug extensions
–Generate test stubs from a VSX definition
–Specialized inspectors to view the state of extensions during debugging

Make it easier to deploy extensions
–VSX Setup DSL to define set of VSX assets to be deployed
–Experience to get a PLK from within VS
–Experience to upload/list your extension on online catalog

Make it easier to migrate extensions between versions of VS
–Exploit VSX DSL and code generation

Make it easier to customize the VS Shell
–Specialized designers for customizing the shell 

Let me know what you think about these ideas and challenges that we are taking on!

Thanks
Deep

by ddubey
Filed under: , ,

Comments

# MSDN Blog Postings » Tools for Tools said on October 26, 2007 11:16 PM:

PingBack from http://msdnrss.thecoderblogs.com/2007/10/26/tools-for-tools/

# davidacoder said on October 27, 2007 6:06 AM:

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?

# ddubey said on November 2, 2007 2:03 AM:

David, you have an interesting usage scenario for DSL. You want to consume the DSL extension that is in the solution in another project in the same solution.

Current templates for DSL/VSIPs target the experimental hive of Visual Studio so that if you do something bad in your extension, it doesn't affect the main VS hive. Having SXS DSL with other projects would work if you were to target the DSL against the main VS hive.

Thank you for your suggestion. We'll definitely look into this scenario and see if there's some tooling that will help this development model.

Thanks

Deep

Anonymous comments are disabled

This Blog

Syndication

Page view tracker