VSX – Know Your Tool
If you’ve ever read The Pragmatic Programmer, and you should, it makes a mantra of DRY (don’t repeat yourself). The point is that you have enough to do developing good software. Don’t waste time on repetitive tasks. I apply the same principle to DRY that I apply to OOP. If I see the same scenario in code three times, I abstract it into a class. So, if I have to perform some boring, or at least repetitive, task three times, I automate it. Well, that’s the plan anyway.
This is my motivation for getting into VSX. I don’t want to perform the grunt work involved in creating Model View Presenter designs. I want to focus on the interesting job. It is the what, not the how that is difficult to get right in software development. I hope to build some tools that allow me, and my fellow developers, to focus on the interesting work.
I decided to begin my investigation with the Visual Studio Extensibility QuickStart Tutorials. These six labs promise step-by-step introductions to the various forms of VS extensions. Below are my notes, so you can follow along from home.
In order automate tasks at a fine grained level in VS, you’ll want to use the Managed Package Framework (MPF). This is a managed API introduced in Visual Studio 2005. Classes in the MPF are found primarily in the Microsoft.VisualStudio.Package and Microsoft.VisualStudio.Shell namespaces. In order to manipulate the MPF, you interact with numerous interfaces. You will implement many of these IVs* interfaces in your classes, so that VS knows how to interact with your package.
The primary elements available for creation are tool windows, document windows and commands. In the new VSPackage wizard, the options are listed as Menu Command, Tool Window and Custom Editor. Commands display visually as buttons on menus and toolbars. Commands are also available in the command window by category. Type “build.” in the command window, and intellisense lists the commands available in the build category.
It can be useful to bind a keystroke to your custom commands. The comments in the template for VS commands warn:
Notice that Visual Studio has a lot of components and commands, so it can be difficult to find a key binding not used by somebody else; if the key bindings are conflicting only one will be used and one problem is that the shell will not inform the user that a conflict was found. The only way to detect the problem is to start Visual Studio under debugger, try to execute any command and look if there is a message in the output window about a duplicated accelerator found.
In order to distribute your package, you must request a Package Load Key from the VSIP site. This is an unnecessary hassle, it seems to me. I’ve requested a PLK for the package I created following the tutorials. I understand the need to track commercial packages which extend the VS shell, but it seems like overkill for personal extensions.
It’s 11:30, and I’ve only finished the second tutorial. I’ll pick this up again tomorrow.
Cheers,
++Alan
Going Deep with VSX
I’m taking some time off around the Independence Day holiday this week. I have several projects queued up for attention. One that has priority for me is an investigation of VSX. I was introduced to the latest efforts by Don and Ken while I was at TechEd. I don’t have much to report yet, but I would like to share some resources that I’ll be exploring:
- “How Do I?” Videos for Visual Studio Extensibility;
- Visual Studio 2005 Extensibility Videos
- VSSDK Assist
- VSMessenger
- VS Orcas SDK June CTP
- XPathmania
That ought to keep me busy for a few days! I’ve got some ideas that I would like to implement in the IDE, but I don’t know how to get started as yet. I’ll report back when I’ve learned something.
Cheers,
++Alan
