Cave Markings

You only get one chance to make a first impression.  I want to record mine regarding VSX before I get too familiar with it.

First, the documentation and comments in the project template are very thorough and helpful.  If the legacy systems I've supported in my career were half as well documented, I'd probably be less obsessed with TDD these days.

Speaking of TDD, there is a great set of sample projects in the SDK.  These are found in %VSSDK_InstallDir%\%Version_Number%\VisualStudioIntegration\Samples\IDE\CSharp\.  In that folder, there are some reference projects, each of which include a TDD\ folder with unit tests.  Sweet!

So, kudos to the VSX team for the good documentation and the unit tests, on to what was less than stellar.  There must be a way to abstract the CTC file.  It isn't poorly formatted for a config file, but It could be so much better.  XML anyone?  I know XML takes it's lumps when it is used for scripting, or as a data serialization format, but it is ideal for a config file.

At the very least, there needs to be a CTC Editor GUI tool to prevent me from fat fingering some comma separated value.  Here is an excerpt from the tutorial:

This line contains comma-delimited fields. The first field is the command that will receive the key binding. This field is in the form GUID:ID, where the first part is the GUID for the package, which is defined in Guids.h (also in the CtcComponents folder). The second half is the command identifier you typed in when you ran the wizard; this identifier is defined in CommandIds.h (which is also in the CtcComponents folder).

The second field is a GUID representing where this keyboard shortcut will be available. Different parts of Visual Studio can have different keyboard handlers. For example, when you are inside a text editor, the keyboard shortcut CTRL+I runs the Incremental Search command. But when the Solution Explorer is active, CTRL+I has no key binding. Thus, CTRL+I is only available to the text editor.

We want our keyboard shortcut to be available everywhere in Visual Studio; thus, it will be global. For global keyboard shortcuts, we use the GUID defined by guidVSStd97.

The third field is not presently used; for now, you use the same identifier from the second field, guidVSStd97.

The fourth and final field is the keyboard shortcut. This takes the format 'character':otherkeys, where the character for the shortcut goes in single-quotes. The otherkeys portion represents SHIFT, CTRL, and ALT with the letters S, C, and A, respectively. In this sample we're using CS, which means CTRL and SHIFT. The letter used in this example is M; thus, this keyboard shortcut is CTRL+SHIFT+M.

Couldn't I have an editor that allows me to select values from lists, rather than manually locating them in guids.h?  This is "hold your mouth right" programming.  How am I supposed to remember that the third field isn't used, and why do we put in a value if it isn't used?  How about creating an enum that I can access in code, rather than making me remember the constant guidVSStd97?  How long can I continue with these rhetorical questions?  Seriously, this aspect of VSX screams for better tooling.  Perhaps this is what VSSDK Assist does.

Finally, I have a real issue with the PLK.  It is a bottleneck to community development to request a new key for every dll.  Perhaps we could have one key for all community created packages, while commercial vendors are required to have unique keys.

If I sound negative, it's only because I know I will become accustomed to these annoyances in my quest to master VSX, and I want to record them to remind myself what it was like to be a noob.

Cheers,

++Alan

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

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