Visual Studio Extensibility can appear daunting to the uninitiated.

This article will look at the blogging effort on, as well as the VSMessenger sample application, and examine how they improve overall approachability to Visual Studio Extensibility.

In retrospect, some aspects of my initial transition from classic ASP to ASP.NET were brutally difficult. Sadly, a primary contributor to much of the difficulty during that transition stemmed from my lack of familiarity with object-oriented programming (OOP). In fact, when I got started with the .NET Framework (during initial beta stages of the 1.0 Framework) I was really nothing more than a self-taught scripter. Sure, I'd had plenty of experience coding with Visual Basic, VBA, VBScript, and even PHP-and while I loved using “classes” in PHP and VBScript 3.0, I really still didn't fully understand all of the true benefits of OOP.

A perfect example of one of the times that I really wondered what in the world was going on with the .NET Framework was when I went to add a new ListItem to an ASP.NET DropDownList control that had already been populated from a database (i.e., imagine a drop-down with a list of all 50 U.S. states pulled from a database and wanting to add something like “Other” to the list without modifying the database). Using Classic ASP this would have been a trivial task; I would have just needed to emit more markup using whatever mechanism I had just used to populate the previous entries. In ASP.NET, adding this additional custom option was much harder. Not only did I have to get the timing of my “addition” right (otherwise I would overwrite my initial data-binding), but the whole process of programmatically creating a new ListItem instance, populating it with text, and then adding it to the collection of Items used by the DropDownList control just seemed like an incredibly huge amount of work for something that had been so trivial before.

In a large way, I think that my transition to ASP.NET from Classic ASP was very similar to what many developers go through when they make their first foray into Visual Studio Extensibility (VSX).

In a large way, I think that my transition to ASP.NET from Classic ASP was very similar to what many developers go through when they make their first foray into Visual Studio Extensibility (VSX). Take, for example, what is required to output some simple text in a Message Box from within a VSPackage:

IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell));
Guid clsid = Guid.Empty;
Guid clsid = Guid.Empty;
int result;
                       ref clsid, 
                       "This is a message.", 
                       0, // false
                       out result);

Merely scanning that code shows that it takes a lot more development and coding to output some simple text in a message box than what would be required of any .NET Windows Forms developer:

MessageBox.Show("This is a message");

Note too that both of these examples are in managed code; but the VSX code looks an awful lot more complex. It can also look a bit daunting or even intimidating if you're not familiar with all of the arguments and enumerations. However, if you've spent much time doing VSX and are used to the underlying paradigms involved, then the message box code above is really trivial.

Some of the Pitfalls of VSX

Just as I bumped into problems during my transition to ASP.NET due to my lack of understanding of OOP concepts and principles, competent .NET developers can run into some real pitfalls when they begin to undertake any serious VSX efforts. Some of the major pitfalls that I've encountered during my own forays into the vast world of VSX include:

  • Inaccurate Walkthrough and Sample Documentation. Sadly, some of the walkthroughs and tutorials provided by the Visual Studio SDK just don't work. This isn't a super-common occurrence, but it's one problem many people bump into when they first start out their VSX efforts. To be fair, I'm not sure if some of this has to do with subtle environmental difference between machines where the samples/tutorials were written and where they're re-hydrated, or if it's more due to the constantly changing nature of the SDK itself. Either way, it can be a real downer to find what you think will be a solution to one of your problems-only to see that you can't get the solution to work.
  • Disjointed Assumptions. Some aspects of VSX development fall into a grey-area where the developers and owners of the VS SDK at Microsoft (who typically have years of C++, Win32, and COM experience) just assume that developers working with the SDK will know certain things about the registry, installers, or some of the inner workings of Windows itself. A great case in point would be the dearth of information around installers in general when it comes time to deploy your own VSX solutions-the SDK goes into lots of warnings about why self-registration of your VSPackage is a bad idea, but never really explains what self-registration is or how you'd avoid doing it. The expectation, or assumption, is that you're an old-hat at writing installers, which may or may not be the case.

These pitfalls, however, are really inconsequential compared to the main pain and difficulty of initial VSX development which stems from attaining the paradigm shift needed to understand how Visual Studio works, and how it can be extended. Thrown into that mix too is the whole nature of the Managed Package Framework-along with its incumbent benefits and limitations. It should therefore come as no surprise that many developers feel intimidated during their initial approach to VSX development. The problem, of course, is that as daunting as VSX development can appear, there really are a lot of cool things that you can do to extend Visual Studio once you've addressed aspects of the learning curve.


Given that Visual Studio Extensibility can represent a substantial paradigm shift for many developers, and given that the VS SDK itself is constantly in flux (and therefore hard to document as properly as one would expect), Microsoft launched the site to help serve as a resource for developers interested in taking the VSX plunge. Metaphorically speaking, I like to think of as a site intended to help show people that they can, indeed, jump into “Double-Dutch” jump-ropes without getting hit. Or, more importantly, if they do get hit, how to recover from being hit and how to move on.

As such, the VSX team designed to take normal developers (with technical proficiency and experience using Visual Studio and .NET technologies), and “throw them into VSX” in order to allow anyone following along with the blog posts to get a feel for just how hard things really are. So far what has resulted is a chronicle of the overall adventure, including some of the mis-steps, work-arounds, as well as some of the successes and triumphs.

Of course, if all of this sounds like is just a developer “journal” designed to transparently chronicle some adventures in VSX, then you've perfectly grasped the intention of the site. But as we all know, it's typically much easier to learn from other people's experiences and mistakes than from our own-so in that light can serve as an invaluable asset for developers taking the initial plunge into Visual Studio Extensibility.

Enter VSMessenger

The VSX team created the VSMessenger sample application for two main reasons. Firstly, as a chat or messaging application, it's something that everyone can easily understand in terms of desired functionality (i.e., to allow chat functionality from within Visual Studio). Secondly, by creating a full-fledged sample application, developers following along with the blogging effort on could learn about an end-to-end sample application as it gets developed, tested, signed, and deployed.

Personally I attach a lot of value to this last benefit, as many of the samples or tutorial applications that are defined in the VSSDK itself are really just stand-alone samples that may show off a handful of concepts and features, but really don't help provide enough context about the whole picture of how these extensions should be deployed to help make them as valuable as they could be. By providing a fully-documented, end-to-end sample application with source-code, hopefully developers can use VSMessenger as “training wheels” to help jumpstart their own VSX efforts.

Hopefully developers will be able to use VSMessenger as “training wheels” to help jump-start their own VSX efforts.

Likewise, as for the chat functionality itself, that does seem a bit lame-at least superficially. But the end-goal of VSMessenger is to allow it to directly interact with Visual Studio project and solution files to keep track of any contacts assigned to a given project or solution. Then, on open-source projects with lots of collaborators, this functionality can be used to create context-sensitive contact lists and functionality allowing collaborators to more easily communicate given their typically different schedules.

If you are curious to see what sort of functionality VSMessenger provides, I strongly recommend watching the first two screen-casts (VSMessenger Introduction and VSMessenger Intro Part II) listed in the screen-casts section of the site. These screen-casts will provide you with some of the background behind VSMessenger, as well as with an overview of typical workflows handled by VSMessenger. The second screen-cast (VSMessenger Intro Part II) also provides some insights into future direction and development of the application itself.

You'll discover one key aspect of working with VSMessenger when you download and play around with the bits, because there are really two “flavors” of VSMessenger. The first is a Windows Forms version of the functionality (found in the VSMessenger.Console project). In this sample application, the VSX team implemented the initial IM functionality as a proof-of-concept in terms of interaction, UI, and operation. The benefit of having this project within the VSMessenger Solution is that it can help developers easily contrast which bits of code in the Solution are IM-related, and which parts directly pertain to Visual Studio Extensibility. The second VSMessenger application found in the VSMessenger solution is, of course, the VSPackage version of the application. In this project the same core IM logic (VSMessenger.Core) that is extended by the Windows Forms application is extended-but as a Visual Studio Extensibility Project. By contrasting the implementation details for both projects, developers unfamiliar with VSX can quickly gain a good sense for what kind of effort, activity, and integration is required to take one of their own ideas (which they would be comfortable coding as a Windows Forms application) and integrating it with Visual Studio. RoadMap will continue to showcase some additional VSX projects and sample applications, and then hopefully begin to serve as part of a catalyst to possibly look into writing some project templates and other resources that will make it easier for developers to jump-start their own VSX projects. As an example of the type of projects that you may see in the future, consider something like an Installer Setup Wizard. Any real VSX project that developers make will need to be deployed and installed to machines without the VSSDK installed-so why not use a custom Visual Studio template along with a wizard to bundle up your project output, package load key, and other particulars? Not only would this be a great resource to help budding VSX developers output their own projects, but blogging about the development efforts behind creating a new VS project template and wizard to accomplish this task would help provide valuable insights to anyone looking to create their own templates or wizards-which is exactly the spirit of Insights and Resources

Of course, by blogging about some of the problems encountered during VSX development of VSMessenger, has become a resource in its own right-culled from the experiences of its authors. For example, remember the pitfall that I mentioned of the tutorials occasionally not working correctly? I've found in my own VSX development efforts that the sample applications that ship with the VSSDK itself (i.e., the solutions saved to disk-not the ones you create from scratch by following the tutorials in the SDK documentation) always work. In fact, not only do they always work, but they're actually some of the best resources in terms of documentation and explanation available in the entire SDK. On I constantly call attention to these sample applications and some of the things I've been able to learn from them. Likewise, you'll also see that on I occasionally mention the sample applications found in the Archive folders of the SDK-another great set of resources.

In addition to insights and links to other resources, also provides tips and tricks along with some tutorials and screen-casts designed to help steer developers clear of some implementation pitfalls and potential problems that they may encounter during VSX development. You'll also find plenty of success stories too, which is a key consideration because VSX development is very exciting and very rewarding most of the time.

VSX development is very exciting and very rewarding most of the time.

Make time to check out and feel free to provide any feedback on the site about direction or sample applications that you'd like to see in the future.