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

I found a couple of days ago a bug that I hadn’t seen before: when you create an add-in with Visual Studio 2013 (you need to install the VS 2013 SDK), hit F5 to debug it, which launches a second VS 2013 instance and close this instance (even without loading the add-in), you get:

An unhandled exception of type ‘System.Runtime.InteropServices.InvalidComObjectException’ occurred in mscorlib.dll
Additional information: COM object that has been separated from its underlying RCW cannot be used.

This exception happens in System.Threading.Tasks.AsyncCausalityTracer.TraceSynchronousWorkCompletion(System.Threading.Tasks.CausalityTraceLevel, System.Threading.Tasks.CausalitySynchronousWork)

Searching the web I have found that it happens also with packages and DSL designers of the VS 2013 SDK, that is, with any kind of extension. It was reported on Microsoft Connect:

Visual Studio 2013 Domain Specific Language Designer crash on exit.
https://connect.microsoft.com/VisualStudio/feedback/details/813425/visual-studio-2013-domain-specific-language-designer-crash-on-exit

and Ryan Molden (MSFT) acknowledged the bug in this thread of the MSDN VSX forum about packages:

Default VSPackage template in VS2013 SDK Throws Exception when exiting
http://social.msdn.microsoft.com/Forums/vstudio/en-US/06c0c8f3-e616-4c8c-9a62-aa87a6a63edb/default-vspackage-template-in-vs2013-sdk-throws-exception-when-exiting?forum=vsx

It is a bug of the async causality tracing stuff of the CLR 4 modified by the .NET Framework 4.5.1 (and used by VS 2013), because it didn’t happen with the CLR 4 of the .NET Framework 4.5 (used by VS 2012). Notice that it doesn’t depend on the .NET Framework used by your extension (.NET 2.0 in my case).

We will need to live with this bug until the Windows team (which owns the CLR, not the VS team) fixes it. An interesting thing is that I hadn’t seen this problem until I reformatted my laptop with Windows 8.1 a couple of days ago. Previously I was using Windows 7 and in fact I haven’t been able to reproduce the problem today on another laptop with Windows 7.

Another problem apart from this other one that can happen installing Visual Studio 2012 language packs to try your extension with other languages is the following:

“Windows Program Compatibility mode is on. Turn it off and the try Setup again”

The error message is misleading: I have found that it happens if you rename the setup file from the original name “vs_langpack.exe” to something else, such as “vs_langpack_english.exe”, etc. (for example, to have all the language packs in the same folder).

Notes:

• The problem doesn’t happen with Visual Studio 2013 language packs, though.
• I am using Windows 8.1 RTM. It could be that the problem doesn’t happen on other Windows versions.
• Apparently the same happens to VS 2012 (not a language pack) if not named correctly, according to this bug report on Microsoft Connect. Microsoft says it’s a bug of Windows 8.1 RTM.