The strange case of...

Another strange case of error 80131522 loading a Visual Studio add-in

OK, this is a post mainly for me (to be found in the future) because yesterday it was the second time that it happened (and I barely remembered the first one). It is a so subtle scenario that it can only happen if you create lots of add-ins for multiple versions of Visual  Studio (I need to do this for the MZ-Tools Articles Series about developing Visual Studio add-ins) and some day you do not clean up properly.

So, yesterday this is what happened:

  • I created an add-in named MyAddIn1 in Visual Studio 2005 (I tend to use this IDE for the samples of articles to ensure that I use .NET Framework 2.0).
  • I edited the file MyAddIn1 – For Testing.AddIn in the “C:\Users\<user>\Documents\Visual Studio 2005\Addins” folder to add <HostApplication> entries for Visual Studio 2008 (9.0), 2010 (10.0) and 2012 (11.0).
  • I copied the file MyAddIn1 – For Testing.AddIn to the AddIns folders of those IDEs.
  • I loaded the add-in using the Add-In Manager (the add-in was marked not to load on startup) and it loaded correctly in VS 2005, 2008 and 2010, but I got error 80131522 in VS 2012. What???

I was well aware that the usual cause for that cryptic error is when the namespace and class name of the “Connect” class in the code don’t match the value of the FullClassName tag of the .AddIn file, as I explained in this article:

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

But this was not the case, because the .Addin file was exactly the same (copied to four folders) and in fact the add-in loaded correctly in three IDEs. So, I used ProcMon to see if I noticed something strange:

HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems
http://www.mztools.com/articles/2008/MZ2008024.aspx

I certainly I found that the first appearance of MyAddin1.dll was being loaded from the folder “C:\Users\<user>\Documents\Visual Studio 2012\Projects\MyAddin1\MyAddin1\bin”, not from the “C:\Users\Carlos\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddIn1\bin”. So, there was a second add-in dll named MyAddIn1.dll (from the past) that was being loaded before the MyAddIn1.dll created with the steps above. This dll used a different namespace for the Connect class (even subtly “MyAddin1” vs “MyAddIn1”, notice the different case of just one letter) and therefore the error 80131522.

The only thing that remained unexplained yesterday was why this old MyAddIn1.dll was loaded at all if I replaced its “MyAddIn1 – For Testing.AddIn” file by the new one pointing to the folder “C:\Users\<user>\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddin1\bin” (I remembered the Windows Explorer prompt to confirm replacement) and today I have found the explanation: this old add-in created a permanent CommandBarButton, so its underlying MyAddIn1.dll file was loaded. As soon as I removed that button, the new add-in loaded fine.

Bottom line: the error 80131522 can happen if a wrong add-in dll (with the same name) is loaded. The ProcMon tool should help to find the folder where an add-in dll is being loaded from.