Cave Markings 

I just read on Rob Foster's blog that my buddy John Kellar in Nashville was recently named a Microsoft MVP.  I can't think of anyone more deserving.  John is the inspiration (and much of the blood, sweat and tears) behind DevLink.

Speaking of DevLink, I need to get my session descriptions to John before he takes me off the speaker list.   In honor of John's incredible efforts for the .NET community in Tennessee, I would like to dub him "The Hardest Workin' Man in Software."  We'll see if it sticks.

Cheers,

++Alan

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'l