One of the first things that you learn about Visual Studio packages is that by default they are loaded on demand (delayed loading), not when Visual Studio launches (because there are tons of them and it would take a lot of time, CPU and memory to load all of them).
However, what if you really need to load a package on startup? (for example because it needs to listen to VS events). It happens that the answer is more complicated than just a binary flag. It is made with an attribute with a special Guid. My second article about packages explains it, with some insight of the whole mechanism from that attribute and Guid to the Windows registry where Visual Studio locates which packages to autoload and when:
One of the consequences of my decision to move to SDK packages (apart from changing the title of the blog “Visual Studio Extensibility with Add-ins” at some point) is to start the MZ-Tools Articles Series (about Visual Studio SDK packages). I have created a new section on my Resources about Visual Studio .NET extensibility page for the MZ-Tools Articles Series (about packages) that I plan to write in
the next years. My first impression is that if extensibility with add-ins is tricky, extensibility with packages is hard, because of the lack of an object model, the COM roots of Visual Studio, etc. You only have to compare the code of the projects generated by the add-in project and the package project wizards… so there is a lot to learn and to write about :-). My approach will be the same than in the MZ-Tools Articles Series about add-ins: many small articles, with sample code, focused on specific things (HOWTO, INFO, BUG, etc.), classified by area. I hope they will help not only developers starting with Visual Studio extensibility from scratch, but also developers moving from add-ins to packages.
Since all this means that I will create a lot of packages for
the articles samples, the first article is how to customize the templates used by the package wizard:
Nine years ago, back in July 2004, my very first article of the MZ-Tools Series was about changing the source code of templates used by Visual Studio when generating projects (Class Library, etc.):
All these years later I have used hundreds of times the Visual Studio add-in wizard to generate the samples of add-ins for the articles, and I find myself changing the default code over and over. Some days ago I wondered about publishing online better templates with the correct patterns, etc. but that is not possible because the code is generated by a wizard, that is needed to generate the .AddIn file outside the project folder (otherwise an add-in project is just a Class Library project). So, what I have done is to modify the templates used by the wizard, which happen to be in a hidden location, documented in this new article:
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.
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:
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:
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: