Of course, creating Visual Studio projects with the automation model that I showed in my last post is not only tricky but also fragile if there is a collision with project templates names, something that happened during the Visual Studio 2012 beta and that was fixed after I reported it:

EnvDTE80.Solution2.GetProjectTemplate(“ClassLibrary.zip”, “VisualBasic”) returns Windows Metro template
http://connect.microsoft.com/VisualStudio/feedback/details/728382/envdte80-solution2-getprojecttemplate-classlibrary-zip-visualbasic-returns-windows-metro-template

Yesterday I learned from a question in the MSDN VSX forum that other SDK tools for Visual Studio, such as the Windows Phone 8.0 SDK, can also introduce templates that cause name collisions.

I have documented it here:

BUG: EnvDTE80.Solution2.GetProjectTemplate returns wrong template for ClassLibrary if Windows Phone SDK installed
http://www.mztools.com/Articles/2013/MZ2013023.aspx

And I have opened a bug at Microsoft Connect:

EnvDTE80.Solution2.GetProjectTemplate(“ClassLibrary.zip”, “VisualBasic”) returns Windows Phone template
http://connect.microsoft.com/VisualStudio/feedback/details/792423/envdte80-solution2-getprojecttemplate-classlibrary-zip-visualbasic-returns-windows-phone-template

Long time ago I wrote how to create a (blank) Visual Studio solution from an add-in, which while not very useful, it was tricky:

HOWTO: Create a solution from a Visual Studio add-in.
http://www.mztools.com/articles/2011/MZ2011001.aspx

Today I have written the continuation with something more useful (specially if you practice integration testing), how to create a project:

HOWTO: Create a project from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013022.aspx

Apart from getting selecting nodes in the Solution Explorer and selecting them, some people want to do the same with the Server Explorer. There is mixed news here: while you can navigate the Server Explorer like you do with the Solution Explorer (its inner object is an EnvDTE.UIHierarchy), the UIHierarchyItem.Object property of each node is useless, since it returns the UIHierarchyItem type (on the contrary, nodes of the Solution Explorer return EnvDTE.Solution, EnvDTE.Project, EnvDTE.ProjectItem, etc.).

So, this new article only shows how to get the names of the nodes. Also, notice that the Server Explorer inner object can not be retrieved directly using EnvDTE80.DTE2.ToolWindows (as you do with the Solution Explorer using EnvDTE80.DTE2.ToolWindows.SolutionExplorer), and while you could use EnvDTE80.DTE2.ToolWindows.GetToolWindow(“Server Explorer”), that would work only on the English version of Visual Studio. The article shows an international solution:

HOWTO: Get the nodes in the Server Explorer from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013021.aspx

The most natural question after learning how to get the selected node(s) in the Solution Explorer is how to select them by code:

HOWTO: Select nodes in the Solution Explorer from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013020.aspx

I am going now to post some articles about common questions that appear in the MSDN VSX forum about the nodes of the Solution Explorer / Server Explorer and that I have noticed that I hadn’t addressed in my articles. The first one is about getting the selected node(s) in the Solution Explorer:

HOWTO: Get the selected nodes in the Solution Explorer from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013019.aspx

My next article of the series devoted to migrating macros to add-ins (after migrating macro methods and macro environment events) is about keyboard shorcuts for macro commands:

HOWTO: Create a keyboard shortcut (binding) to Visual Studio add-in command
http://www.mztools.com/articles/2013/MZ2013018.aspx

Don’t miss this other article if you are using non-English versions of Visual Studio:

BUG: Command.Bindings causes Exception when setting value from an add-in in localized Visual Studio.
http://www.mztools.com/articles/2012/MZ2012021.aspx

My second article about migrating from macros to add-ins (after the first one) is about the environment events:

HOWTO: Migrate macro events to a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013017.aspx

I have not tested VS 2013 Preview yet, but since the macros IDE was
not updated in VS 2010 and was completely removed in VS 2012, I wouldn’t
expect it to be back in VS 2013 (after all, colors are not getting back either). So, for those many users aggraviated by the macros removal I have written a small article that shows how to convert macros to an add-in with minimal effort:

HOWTO: Migrate macro methods to a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013016.aspx