Calling Marshall.ReleaseComObject

February 21, 2014

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
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.releasecomobject.aspx

Marshal.ReleaseComObject Considered Dangerous
http://blogs.msdn.com/b/visualstudio/archive/2010/03/01/marshal-releasecomobject-considered-dangerous.aspx

The mapping between interface pointers and runtime callable wrappers (RCWs)
http://blogs.msdn.com/b/mbend/archive/2007/04/18/the-mapping-between-interface-pointers-and-runtime-callable-wrappers-rcws.aspx

Chapter 2: Basics of Office Interoperability (Part 2 of 3)
http://msdn.microsoft.com/en-us/library/office/aa679807%28v=office.11%29.aspx


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

February 19, 2014

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:


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

February 9, 2014

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.

February 5, 2014

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: HOWTO: Navigate the files of a solution using the IVsHierarchy interface from an add-in.

February 1, 2014

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: HOWTO: Get the IVsHierarchy and Item Id of EnvDTE.Project and EnvDTE.ProjectItem

January 30, 2014

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: HOWTO: Get standard / additional include directories of Visual C++ project from an add-in

January 25, 2014

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: BUG: NullReferenceException showing properties of executable project if inside solution project

January 25, 2014

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: INFO: CLR HRESULT errors loading add-ins

January 24, 2014

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
http://blogs.msmvps.com/carlosq/2014/01/23/the-strange-case-of-error-8013101b-loading-a-visual-studio-add-in.aspx

The strange case of error 80131515 loading a Visual Studio add-in
http://blogs.msmvps.com/carlosq/2013/07/08/the-strange-case-of-error-80131515-loading-a-visual-studio-add-in.aspx

Another strange case of error 80131522 loading a Visual Studio add-in
http://blogs.msmvps.com/carlosq/2012/09/26/another-strange-case-of-error-80131522-loading-add-ins.aspx

The strange case of <Unknown Error> 8013150A loading a Visual Studio add-in
http://blogs.msmvps.com/carlosq/2009/03/24/the-strange-case-of-lt-unknown-error-gt-8013150a-loading-a-visual-studio-add-in.aspx

The strange case of <Unknown Error> 8013141A loading a Visual Studio add-in
http://blogs.msmvps.com/carlosq/2008/11/28/the-strange-case-of-lt-unknown-error-gt-8013141a-loading-a-visual-studio-add-in.aspx

The strange case of error 80131018 loading a Visual Studio add-in
http://blogs.msmvps.com/carlosq/2007/03/23/the-strange-case-of-error-80131018-loading-a-visual-studio-add-in.aspx

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


The strange case of error 8013101b loading a Visual Studio add-in

January 23, 2014

Another error that can happen loading an add-in that I have found today is the following (with an unhelpful error message as usual):

Error Message: <Unknown error>
Error number: 8013101b

This error happens if you have compiled the add-in with a CLR version higher than the one supported by the Visual Studio IDE where you are trying to load it. For example, if you compile the add-in using Visual Studio 2010, 2012 or 2013 using CLR 4.0 and you try to load it in Visual Studio 2005 or 2008, which only support CLR 2.0.

Remember that the CLR is not the same than the .NET Framework. The correspondence is as follows:

  • .NET Framework 1.0 use CLR 1.0
  • .NET Framework 1.1 use CLR 1.1
  • .NET Framework 2.0, 3.0 and 3.5 use CLR 2.0
  • .NET Framework 4.0, 4.5 and 4.5.1 use CLR 4.0

And there is no such thing as CLR 3.0, CLR 3.5, CLR 4.5 or CLR 4.5.1. While .NET Framework 3.0 and 3.5 just installed new libraries without touching the CLR 2.0, .NET Framework 4.5 and 4.5.1 do touch the CLR 4.0 (a kind of in-place replacement) but keeping it backwards compatible and maintaining the version 4.0.

This means that for example, the problem doesn’t happen if you compile the add-in with VS 2013 using .NET Framework 4.5.1 (uses CLR 4.0) and you try to load it in VS 2010 (supports CLR 4.0). A problem can happen if you use some assembly of .NET Framework 4.5 or 4.5.1 because it would be missing on a machine with only VS 2010 and .NET Framework 4.0 but that would be a different issue, not a 8013101b error.

I have updated my article about troubleshooting add-ins with this new error number:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/mz2007009.aspx