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
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
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
HOWTO: Get additional include directories of Visual C++ project from an add-in
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
I reported it through Microsoft Connect but I verified yesterday that it is not fixed yet in VS 2013.
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
The strange case of error 80131515 loading a Visual Studio add-in
Another strange case of error 80131522 loading a Visual Studio add-in
The strange case of <Unknown Error> 8013150A loading a Visual Studio add-in
The strange case of <Unknown Error> 8013141A loading a Visual Studio add-in
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
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
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.
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
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).
- 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.
Happy New Year!
Microsoft awarded me yesterday my 11th Most Valuable Professional (MVP) title, which, as always, makes great the start of the new year :-).
Speaking about the new year, I want to share some of my plans in the Visual Studio extensibility area:
I would be very satisfied if I can accomplish all that 🙂