Calling Marshall.ReleaseComObject

If you ever develop COM add-ins for the VBA editor (or for some Office application), you may find that sometimes you need to call Marshall.ReleaseComObject (when you get strange errors that disappear when calling Marshall.ReleaseComObject) and most of the time (by default) you don’t have to (when you get an InvalidComObjectException). The issue is a bit tricky because of a number of factors, such as:

– The RCWs are reused and cached per-AppDomain

– An AppDomain can contain more than one .NET add-in

– RCWs have a reference counter, and the COM-object that the RCW wraps has another reference counter.

– There can be COM singletons involved.

– Etc.

Here you have some useful links to get a better knowledge:

Marshal.ReleaseComObject Method

Marshal.ReleaseComObject Considered Dangerous

The mapping between interface pointers and runtime callable wrappers (RCWs)

Chapter 2: Basics of Office Interoperability (Part 2 of 3)

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

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:

The strange case of VS 2010 Macros stop working after February 2014 Windows Update

I have noticed today that VS 2010 macros stopped working.

Fortunately the cause is known (a security patch of Windows Update) and there is a workaround. See:

Visual Studio 2010 Macros Stop Working after February 2014 Windows Update


The strange case of VBA editor prompting to repair Visual Studio (again)

On one of my computers I have started to suffer again the strange case of a prompt to repair Visual Studio 2010 when launching the VBA editor of any Office application. I already posted about this back in 2012 when I learned that a cause for that issue was having an external hard drive connected to the computer while you installed Visual Studio. When the drive was disconnected, the issue appeared. Since I did use an external hard drive as source for the setups of Visual Studio, that was certainly the case. Since then, I never have an external hard drive connected while I install Visual Studio, I copy the setups to the desktop, disconnect the drive and proceed to install.

So, what is causing the issue now, out of the blue? I am reading again the post How to work around the issue when opening Office applications repairs Visual Studio where Heath Stewart explains the issue and the workaround, and again, the cause is the presence of a drive unit that was present while Visual Studio was installed and sometime later that drive letter is no longer available. In my new cause these days, it was caused because the computer is an office laptop, and my company partitions the hard drive in two units, “C:” for apps and “D:” for data. Since that is plainly useless (the hard drive is the same so if broken you lose both partitions and most data goes anyway to the “Desktop” or “My Documents” locations, which are on “C:”), a couple of days ago I removed the empty “D:” partition and joined the space to the “C:” partition (which was almost full). Alas, since the “D:” unit was removed the issue with the VS 2010 prompt to repair appeared.

The post of Heath Stewart explains how to find the offending component filtering by “Warning” kind, “MsiInstaller” source and “1001” event id. But it you filter instead by “1004” event id, you will get the offending missing unit (“D:” in my case).

I have been unable to fix the issue yet with the instructions of the post, so I have had to uninstall VS 2010. I am now gettting a prompt to repair Visual Studio 2013…oh my…, you see, the installers of Visual Studio are so crappy that if you are a developer of extensions for Visual Studio and get a new computer you know you have to spend a lot of hours installing VS 2005, SP1, VS 2008, SP1, VS 2010, SP1, VS 2012, VS 2013, tons of patches and updates, etc. and when you think it’s done, some day you discover that you need to uninstall all of them (or to format the hard drive to start again) as I did in 2012 and it seems that I will have to do this next week again…

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.

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

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.

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.