Visual Studio Extensibility Demystified

  • Article

Since we have placed the VS 2005 SDK 3.0 on the Microsoft Download Center in September, we have seen a lot of developers downloading the SDK. The developers who are using the SDK now are no longer just developers who build commercial VSIP products. Users of the SDK now include students and developer enthusiasts who are building Visual Studio extensions to make their work more productive or just for fun and curiosity.

To that end, I'd like to spend a little bit of time explaining the various levels of Visual Studio extensibility to help developers who are new to the Visual Studio platform get ramped up.

Within the Visual Studio environment itself, there are 3 levels of extensibility: macros, add-ins and VSPackages.

Macros

Macros are the easiest way for developers to quickly gain access to Visual Studio's underlying automation object model.  If you hit Alt+F11 in Visual Studio, the Macros IDE will appear in which you can start writing your macro. Macros are sometimes called the "duct tape" of Visual Studio because of its versatility and flexibility. You can easily combine Visual Studio commands or set automation properties to create interesting behaviors. For example, the following is a very simple macro that toggles the word wrap text editor option:

Sub ToggleWordWrap()

DTE.Properties("TextEditor", "Basic").Item("WordWrap").Value = _
Not DTE.Properties("TextEditor", "Basic").Item("WordWrap").Value

DTE.Properties("TextEditor", "PlainText").Item("WordWrap").Value = _
Not DTE.Properties("TextEditor", "PlainText").Item("WordWrap").Value

DTE.Properties("TextEditor", "CSharp").Item("WordWrap").Value = _
Not DTE.Properties("TextEditor", "CSharp").Item("WordWrap").Value

DTE.Properties("TextEditor", "C/C++").Item("WordWrap").Value = _
Not DTE.Properties("TextEditor", "C/C++").Item("WordWrap").Value

End Sub

If you are interested in learning more about how to create, record and use macros, I would suggest that you go here for some resources.

So when should you use macros as the VS extensibility model? The scenarios that are great for using macros are those where you are trying "script" Visual Studio to automate certain tasks, provided that you can accept several limitations:

  1. Macros can only be written in VB .NET.
  2. To share macros with others, you must give them your macro projects which will include source code. Since the user of the macros can see the source code, there is no protection of your intellectual property.
  3. Some extensibility scenarios cannot be achieved via macros. For example, you cannot create a new tool window, a new editor or a new project system via macros.

Scripting the IDE is powerful and often useful in many scenarios. But if you want to do more than "duct-taping", you will need to develop Add-ins or VSPackages.

Add-ins

Similar to macros, add-ins also leverage on the automation object model of Visual Studio. But unlike macros, add-ins are compiled into binary code so your intellectual property can be protected. Perhaps more importantly, add-ins allow you to seamlessly integrate new tool windows, plug in options pages, dynamically enable commands and add branding onto the splash screen & Help About boxes - scenarios that macros do not enable. Features offered by add-ins can fit seamlessly into the IDE as if they were a part of Visual Studio. In implementation, you also have the choice of creating add-ins in C#, VB .NET or C++.

There are many great add-ins in the community today. Visual Studio Hacks has a list of interesting add-ins here. James Avery has written a great MSDN article about the ten must-have tools (some of which are add-ins) for Visual Studio. A couple of student interns from the C# team has created some interesting add-ins that enhances code navigation and editing.

As you can see, add-ins can be used to build tools and features that support a large number of scenarios. The automation object model is extremely powerful. To get a sense of what this automation object model looks like, you can refer to the Automation Object Model chart here on MSDN. If you are interested in learning more about how to create add-ins, Creating Add-ins and Wizards is a great place to start on MSDN.

VSPackages

Now here comes the most powerful way to extend Visual Studio - VSPackages . Using VSPackages (a.k.a. VSIP interfaces), you gain access to the same API that internal teams at Microsoft have to integrate anything you want inside Visual Studio. This deep level of integration allows developers to build everything that add-ins enable, plus more. With VSPackages, you can even build custom project systems, debuggers, editors, data designer extensions and language integrations. IronPython is a great example of a language integration project built with VSPackages, and you can find this sample integration in the Visual Studio SDK.

By the way, the Visual Studio SDK is a great way to start learning about how to use this powerful mechanism to deeply integrate with Visual Studio. You can view the online documentation here. It is easy to get started with VSPackages once you have the SDK installed because it provides Wizards to help you create your first command, tool window or editor via VSPackages. In VS 2005, the Managed Package Framework has made VSPackage development a lot easier. But one thing that continues trip up a lot of developers when creating a VSPackage is the need for a Package Load Key (PLK). Normally, in order for a VSPackage to load, it needs to have a unique PLK that matches several pieces of information about the package. But on the VSPackage developer's machine, this is not needed because the Visual Studio SDK installs a developer key that allows all packages to load without PLKs. So while you are developing your VSPackage, it may work perfectly, and then when you deploy it to other machines, your VSPackage may fail to load.

What you need to do is to request a PLK through the VSIP member site. You need to register for an account (it's free!) before being able to request for a PLK, and you need to make sure the information you entered in PLK request process remains unchanged in your code. The PLK is generated based on the following pieces of information:

  • Company Name
  • Package GUID
  • Product Name
  • Product Version
  • Minimum Product Edition

If you change any of this information in your VSPackage, you will need to re-request a new PLK through the website. Next month, we will cover more about debugging package load failures.

Conclusion

Visual Studio is a great extensibility platform that offers developers many choices for how they want to customize and extend their development environment to meet their unique needs. Which one of macros, add-ins or VSPackages is right for you depends on your scenarios. In general, you can use these rule-of-thumbs:

  • If you are trying to do automate tasks in the IDE quickly and you are fine with distributing your code in source code form, macros maybe the most appropriate.
  • If you want to distribute your code in binary form, and the automation object model satisfy your needs, add-ins maybe the most appropriate.
  • If you want to create a custm project system, editor, debugger or language service, you will need to use VSPackages.

I hope that was helpful in demystifying VS Extensibility.

- Dr. Ex.