It seems that as I learn more and more about the IDE services (VS SDK) and how to call them from an add-in, I can’t stop playing with them and wondering if I can solve problems that previously seemed unsolvable. One of them, very old, was how to get the Guid of the project subtype, to identify Test projects (for example), a problem that I posted long time ago in the MSDN VSX forum and I got a partial answer. What I really wanted is, given an EnvDTE.Project, get all its project type/subtype Guids, without using convoluted code. Yesterday I found a promising solution by another MVP, Daniel Cazzulino, but I was not completely satisfied having to read the .vbproj or .csproj files to get the Guid of the project (not to be confused with the Guid of the project type) in order to get the IVsHierarchy object, which is the key piece here to cast it to IVsAggregatableProject and call the GetAggregateProjectTypeGuids method. Finally I got inspired and thanks to the EnvDTE.Project.UniqueName property you can get the IVsHierarchy object calling IVsSolution.GetProjectOfUniqueName. I wrote the detailed solution in this article:

HOWTO: Get the project flavor (subtype) of a Visual Studio project from an add-in
http://www.mztools.com/Articles/2007/MZ016.htm

Although I am happy with the new world of IDE services called from add-ins, it is a somewhat bittersweet feeling: on the one hand it is great to be able to call them from an add-in, but, on the other hand, I can’t help thinking that add-ins are second-class citizens in the VS extensibility and that a lot of  functionality is not directly available to them and you have to use the complex and intimidating SDK… I wish there was a single, simple, unified and managed (.NET) approach. Do you feel the same? I hope your comments about it.