Category Archives: MZ-Tools Articles Series

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Get the icons of files in the Solution Explorer

After explaining how to navigate the files of the Solution Explorer using the IVsHierarchy interface (which can be done from a package or from an add-in), as I stated I am going to show how to get the icons of the Solution Explorer items (solution, projects, files, folders, etc.):

HOWTO: Get the icons of files in the Solution Explorer
http://www.mztools.com/articles/2014/MZ2014010.aspx

I have done it with a package rather than with an add-in, but once you understand the technique you can adapt it to your extension.

Once loaded, the package provides a toolwindow that shows a treeview filled similarly to the Solution Explorer.

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Create a project item from a Visual Studio add-in

A question in the MSDN VSX forum has reminded me that I had pending to write this article about how to add new project items (files) to a project or folder, either from a template or existing (and in turn copied or linked):

HOWTO: Create a project item from a Visual Studio add-in
http://www.mztools.com/articles/2014/MZ2014009.aspx

This article completes a series about using the automation model (EnvDTE) to create solutions, projects, projects inside folders, folders, project items and issues and bugs that you may encounter:

MZ-Tools Articles Series

MZ-Tools Articles Series: BUG: DTE.ActiveWindow.ProjectItem.Document null for files in Solution Items folder.

This is a small bug in the automation model (EnvDTE) that I discovered yesterday when a customer of my MZ-Tools add-in reported a NullReferenceException when sorting code elements in a file outside a project:

BUG: DTE.ActiveWindow.ProjectItem.Document null for files in Solution Items folder.
http://www.mztools.com/articles/2014/MZ2014008.aspx

And here it is the bug report that I have opened at Microsoft Connect:

DTE.ActiveWindow.ProjectItem.Document null for files in Solution Items folder
https://connect.microsoft.com/VisualStudio/feedback/details/816629/dte-activewindow-projectitem-document-null-for-files-in-solution-items-folder

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Navigate the files of a solution using the IVsHierarchy interface from an add-in.

Continuing with the use of the native IVsHierarchy interface when using add-ins, if in my last article I showed how to get the IVsHierarchy and Item Id of EnvDTE.Project and EnvDTE.ProjectItem, in this new one I show how to navigate the Solution Explorer using that interface instead of the automation model:

HOWTO: Navigate the files of a solution using the IVsHierarchy interface from an add-in.
http://www.mztools.com/articles/2014/MZ2014007.aspx

As you can see in the sample code, the use of that interface is quite complicated because nodes are identified by unsigned 32-bit integers, but when you ask the ids of child or sibling nodes, you can get signed 32-bit integers and even IntPtr values in some cases. You have the documentation here.

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Get the IVsHierarchy and Item Id of EnvDTE.Project and EnvDTE.ProjectItem

As part of the transition of my MZ-Tools add-in to a package I am learning more and more about the “native” way of doing things using the interfaces provided by Visual Studio (SDK) assemblies, which can be used also from an add-in as I explained in this article:

HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/articles/2007/MZ2007015.aspx

In a future article I will show how get the icons used in the Solution Explorer (something that can’t be done with the automation model EnvDTE), but first I need a building block that I explain in this new article:

HOWTO: Get the IVsHierarchy and Item Id of EnvDTE.Project and EnvDTE.ProjectItem
http://www.mztools.com/articles/2014/MZ2014006.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Get standard / additional include directories of Visual C++ project from an add-in

From time to time I see questions about the Visual C++ extensibility model in the MSDN VSX forum. While I haven’t used it (since my MZ-Tools add-in targets mainly C# and VB.NET), I like to take the challenge and investigate if I can provide an answer. I find that the Visual C++ extensibility model is even more tricky than the general one (EnvDTE).

I have written two small articles about a question that I answered some time ago:

HOWTO: Get standard include directories of Visual C++ project from an add-in
http://www.mztools.com/articles/2014/MZ2014004.aspx

HOWTO: Get additional include directories of Visual C++ project from an add-in
http://www.mztools.com/articles/2014/MZ2014005.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: BUG: NullReferenceException showing properties of executable project if inside solution project

This is a small bug that I found a few months ago while stil using VS 2012:

BUG: NullReferenceException showing properties of executable project if inside solution project
http://www.mztools.com/articles/2014/MZ2014002.aspx

I reported it through Microsoft Connect but I verified yesterday that it is not fixed yet in VS 2013.

MZ-Tools Articles Series

MZ-Tools Articles Series: INFO: CLR HRESULT errors loading add-ins

In the past few years, I have been documenting quite a few CLR strange error codes loading add-ins that I have found:

The strange case of error 8013101b loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2014/01/23/the-strange-case-of-error-8013101b-loading-a-visual-studio-add-in

The strange case of error 80131515 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2013/07/08/the-strange-case-of-error-80131515-loading-a-visual-studio-add-in

Another strange case of error 80131522 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2012/09/26/another-strange-case-of-error-80131522-loading-add-ins

The strange case of <Unknown Error> 8013150A loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2009/03/24/the-strange-case-of-lt-unknown-error-gt-8013150a-loading-a-visual-studio-add-in

The strange case of <Unknown Error> 8013141A loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2008/11/28/the-strange-case-of-lt-unknown-error-gt-8013141a-loading-a-visual-studio-add-in

The strange case of error 80131018 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2007/03/23/the-strange-case-of-error-80131018-loading-a-visual-studio-add-in

and in all cases you are clueless given the error code. Today I wondered where those CLR error codes would be defined (that Visual Studio can’t get the meaning) so at least you could get manually the definition to get a clue about the cause of the problem. I have found that they are defined in a file named CorError.h. The details are in my new article:

INFO: CLR HRESULT errors loading add-ins
http://www.mztools.com/articles/2014/MZ2014001.aspx

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Get an EnvDTE.DTE instance from a Visual Studio package

Two extension approaches (add-in, packages), two APIs (automation model, services)… and four combinations:

It happens that add-ins not only can use its more natural API (the EnvDTE automation model), but can also use services provided by the Visual Studio shell and packages. The EnvDTE automation model doesn’t provide a direct way to get a service but you can do it as I explained long time ago in this article:

HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/Articles/2007/MZ2007015.aspx

And packages not only can use its more natural API (services), but can also use the EnvDTE automation model. In fact, the EnvDTE*.* reference dlls are added by default to VS Package projects!. Getting the DTE instance from a package is not difficult except for a little detail: if the package is marked to load on startup (autoload), rather than using delayed loading, it can happen that the IDE is not initialized yet and the package can’t get the DTE instance. This IDE initialization problem happens also with add-ins, which have an OnStartupComplete method and therefore there is pattern to initialize correctly an add-in. Alas, packages need to use a more complicated pattern to get notified when the IDE is fully initialized, with a trick that Microsoft explained originally in this post:

Dr. eX: Why does GetService(typeof(EnvDTE.DTE)) return null?
http://blogs.msdn.com/b/vsxteam/archive/2008/06/09/dr-ex-why-does-getservice-typeof-envdte-dte-return-null.aspx

Since I found the code of the package class somewhat dirtied with that approach, I have rewritten it with a more clean approach (using a separate class for the task):

HOWTO: Get an EnvDTE.DTE instance from a Visual Studio package
http://www.mztools.com/articles/2013/MZ2013029.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Create a project from a Visual Studio add-in inside a solution folder

A couple of weeks ago I wrote about how to create a project from a Visual Studio add-in. A question today in the MSDN VSX forum has made me to realize that I only covered the case when you add a project directly to the solution, not the case when you want to add the project to a solution folder.

At first I thought that it wouldn’t be possible because of this similar scenario:

PRB: NotImplementedException adding a solution folder to a solution folder in Visual Studio from a macro or add-in.
http://www.mztools.com/articles/2011/MZ2011002.aspx

But it happens that it is possible, so I have written another article with sample code in C# and VB.NET:

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

And of course I have to correct the article above because it is also possible to add nested solution folders, although it seems that only virtually (not on disk).