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
http://visualstudioextensions.vlasovstudio.com/2014/02/13/visual-studio-2010-macros-stop-working-after-february-2014-windows-update/
and:
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…
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
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.
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
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
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.
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
https://www.visualstudioextensibility.com/2014/01/23/the-strange-case-of-error-8013101b-loading-a-visual-studio-add-in
The strange case of error 80131515 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2013/07/08/the-strange-case-of-error-80131515-loading-a-visual-studio-add-in
Another strange case of error 80131522 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2012/09/26/another-strange-case-of-error-80131522-loading-add-ins
The strange case of <Unknown Error> 8013150A loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2009/03/24/the-strange-case-of-lt-unknown-error-gt-8013150a-loading-a-visual-studio-add-in
The strange case of <Unknown Error> 8013141A loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2008/11/28/the-strange-case-of-lt-unknown-error-gt-8013141a-loading-a-visual-studio-add-in
The strange case of error 80131018 loading a Visual Studio add-in
https://www.visualstudioextensibility.com/2007/03/23/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
http://www.mztools.com/articles/2014/MZ2014001.aspx
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:
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.