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