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 ship with a broad support for the process of developing SharePoint solutions. One part of that process is packaging SharePoint artifacts into a WSP package and deploying it to a SharePoint server. By know you probably know that the Visual Studio SharePoint development tools are highly extensible, but did you know that you can even extend the way how the Visual Studio SharePoint development tools package SharePoint artifacts?