Generic explorer nodes, like the Features or the Content Types node, weren’t really made to be extended. After all, all they do is to wrap the “real” nodes, so that using the SharePoint Explorer is easier and better performing. Still, there might be situations, when you could want to add some extra functionality to a generic folder node like for example displaying Content Types in groups or grouping Features in Enabled and Disabled.

While extending the Visual Studio SharePoint development tools you might be working on an extension that would be using the fully qualified (4-part) name of an assembly. It could be for example a custom Deployment Step or a MSBuild Task.

If you work a lot with custom assemblies that you reference from your SharePoint Projects in Visual Studio SharePoint development tools, you might want to create an extension that does that automatically for you.

One of the things that I very often needed, while creating Visual Studio SharePoint development tools extensions, was a reference to the current project. No matter whether you want to add a reference or a new project item, a reference to the object that represents the current project is the first part of the solution.

The new Visual Studio SharePoint development tools are way more than “only” a set of tools that helps you during the process of developing SharePoint 2010 solutions. The new development tools ship with a whole framework that allows you to extend the tools to fit your specific needs. While the team responsible for the tools, put a lot of effort into making the extensibility very easy, there are some hidden gems, which, if you know them, will make extending the tools even easier.