The strange case of VS 2010 Macros stop working after February 2014 Windows Update

February 19, 2014

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

http://social.msdn.microsoft.com/Forums/vstudio/en-US/590abd1d-2faa-4a35-9b9c-fe404406d6cd/what-the-visual-studio-2010-macros-not-working-after-windows-update

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…

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

The strange case of InvalidComObjectException exiting Visual Studio 2013 after debugging extension

January 23, 2014

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.

InvalidComObjectException

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.

The strange case of error "Windows Program Compatibility mode is on." when installing Visual Studio 2012 language packs

January 20, 2014

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”

WindowsCompatibilityProgramOn

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.

The strange case of error "Subscript out of range" in Data View starting VB 6

September 19, 2013

I am writing this little post mainly for myself in the future and the other two users that seem to have experienced this in the past. I already saw this in the past but until today I didn’t find out how to fix it:

If you get a msgbox error with the title “Data View” and the text “Subscript out of range” starting Visual Basic 6.0, it means that your commandbars are corrupted and need resetting:
  • Right-click on any toolbar and select “Customize…” menu entry.
  • For each toolbar in the list, click the “Reset…” button.

How did I find this fix? After using SysInternals Process Monitor for a while, I only discovered that Data View is actually a kind of hidden add-in. It doesn’t appear in the Add-In Manager, but it has a Connect class, a toolwindow, etc. The clue was that right-clicking on the treeview of its toolwindow, another error “91 : object variable or with block variable not set” happened and the toolwindow was crashed. And what happens typically when you right-click a treeview node? A commandbar is shown! If the commandbar is not shown, it means that there is a problem with the commandbar subsystem (quite typical of VB6), so I tried resetting the commandbars as explained above and bingo!

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

July 8, 2013

This morning I got an error 80131515 loading my MZ-Tools add-in that I had never seen before, and it was not mentioned in my article HOWTO: Troubleshooting Visual Studio and Office add-ins, so I searched the web.

It happens that after installing the add-in through the setup on a virtual machine on Windows Azure, I downloaded a new build from my web (just the dll, not a new setup), replacing the existing dll. And this error appears when you download a dll in such way, so it is “blocked” by the OS preventing its execution for security reasons. The solution is to right-click the dll file to show its Properties window, and in the General tab, Security zone, click the “Unblock” button.

The strange case of "LoaderLock was detected" with a COM add-in written in .NET

March 17, 2013

Since some days ago, I was getting the following error when closing Visual Basic 6.0 from the Visual Studio debugger (I am developing a .NET-based version of MZ-Tools for the 64-bit VBA editor of Office, and VB6 will get it too):

LoaderLock was detected Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This is a warning of the Managed Debugging Assistants (MDA) of Visual Studio.

Today I decided to investigate. Soon it was clear that it was caused by the test-runner add-in that I created to run integration tests within VB 6.0. Since the error was caused during shutdown, I removed initializations (and the corresponding cleanups) to isolate the problem and I discovered that the problem was in this method:

internal List<string> GetAddinProgIds()
{
   List<string> colAddinProgIds;

   colAddinProgIds = new List<string>();

   foreach (AddIn objAddIn in m_objVBE.Addins)
   {
      colAddinProgIds.Add(objAddIn.ProgId);
   }
   return colAddinProgIds;
}

That method gets the registered add-ins of the VBE object (to load them in a combobox and select an add-in to run its test suites).

I soon realized that maybe I should release propertly some COM object and certainly the problem was fixed:

internal List<string> GetAddinProgIds()
{
   List<string> colAddinProgIds;
   Addins colAddins;

   colAddinProgIds = new List<string>();

   colAddins = m_objVBE.Addins;
   foreach (AddIn objAddIn in colAddins)
   {
      colAddinProgIds.Add(objAddIn.ProgId);
   }

   // The following statement is to prevent the following error:
   // LoaderLock was detected
   // Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain
   // or image initialization function since doing so can cause the application to hang.
   System.Runtime.InteropServices.Marshal.ReleaseComObject(colAddins);

   colAddins = null;

   return colAddinProgIds;
}

The strange case of "Set property ‘System.Windows.ResourceDictionary.DeferrableContent’ threw an exception."

March 9, 2013

In the recent days, each time that I clicked the New Project button of the Visual Studio 2012 IDE, I got this exception:

“Set property ‘System.Windows.ResourceDictionary.DeferrableContent’ threw an exception.”

I have been clueless about this problem until today. When a problem happens in Visual Studio, the recommended approach is to launch it in “Safe mode”, because maybe an extension (add-in, package, etc.) is causing it. As a previous step, what I did today is to take a look at the Add-In Manager and I noticed that I had an add-in (a test runner that I created to perform integration tests of my MZ-Tools add-in) marked to load on startup. I unmarked it and then the problem disappeared. Why was this add-in causing this problem?

After some isolation, it happened that this add-in was setting an event handler for the AppDomain.AssemblyResolve event (to locate required assemblies) and a silenced NullReferenceException was happening in the event handler. The following minimal add-in reproduces the issue:

public class Connect : IDTExtensibility2
{
   private DTE2 _applicationObject;
   private AddIn _addInInstance;
   private AppDomain _appDomain;

   public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
   {
      _applicationObject = (DTE2)application;
      _addInInstance = (AddIn)addInInst;

      switch (connectMode)
      {
         case ext_ConnectMode.ext_cm_Startup:

            // OnStartupComplete will be called
            break;

         case ext_ConnectMode.ext_cm_AfterStartup:

            InitializeAddIn();
            break;
      }
   }

   public void OnStartupComplete(ref Array custom)
   {
      InitializeAddIn();
   }

   private void InitializeAddIn()
   {
      _appDomain = AppDomain.CurrentDomain;
      _appDomain.AssemblyResolve += AppDomain_AssemblyResolve;
   }

   public void OnDisconnection(ext_DisconnectMode disconnectMode, ref Array custom)
   {
      _appDomain.AssemblyResolve -= AppDomain_AssemblyResolve;
   }

   public void OnAddInsUpdate(ref Array custom)
   {
   }

   public void OnBeginShutdown(ref Array custom)
   {
   }

   private Assembly AppDomain_AssemblyResolve(object sender, ResolveEventArgs args)
   {
      Assembly objAssembly = null;
      AssemblyName objAssemblyName = null;

      // Force a NullReferenceException
      if (objAssemblyName.Name == "")
      {
      }

      return objAssembly;
   }
}

The strange case of the add-in initialized twice

February 14, 2013

As I commented in my last post, I have developed my own integration test infrastructure to test my MZ-Tools add-in. As part of it, there is an add-in that is the test runner, that when loaded loads in turn the MZ-Tools add-in if not loaded, locates its friend assembly that contains the integration tests, loads it, gets the test suites, gets the test methods, shows them in a treeview and executes the ones that I select.

This worked fine if the test runner add-in was not marked to load on startup and I had to load it with the Add-in Manager. But when the test runner add-in was marked to load on startup, the MZ-Tools add-in was initialized twice, giving an exception because some code didn’t expect to run twice (duplicated key).

The code of the MZ-Tools initialization is similar to the one that I wrote in my article HOWTO: Use correctly the OnConnection method of a Visual Studio add-in and that I constantly recommend in the MSDN VSX Forums:

AddIn _objAddIn;
EnvDTE.DTE _objDTE;

void IDTExtensibility2.OnConnection(object objApplication, ext_ConnectMode eConnectMode, object objAddInInst, ref System.Array r_objCustom)
{
   _objDTE = (EnvDTE.DTE)objApplication;
   _objAddIn = (AddIn)objAddInInst;

   switch (eConnectMode)
   {
      case ext_ConnectMode.ext_cm_Startup:

         // IDTExtensibility2.OnStartupComplete will be called
         break;

      case ext_ConnectMode.ext_cm_AfterStartup:

         Initialize();
         break;
   }
}

void IDTExtensibility2.OnStartupComplete(ref System.Array r_objCustom)
{
   Initialize();
}

private void Initialize()
{
   ...
}

This pattern assumes that:

1) If an add-in is loaded on startup:
  • The OnConnection method will be called with the ext_ConnectMode.ext_cm_Startup flag.
  • The OnStartupComplete method will be called later TOO, when the Visual Studio IDE has completed its initialization.

2) If an add-in is loaded through the Add-In Manager:
  • The OnConnection method will be called with the ext_ConnectMode.ext_cm_AfterStartup flag.
  • The OnStartupComplete method will NOT be called (because the Visual Studio IDE was already initialized when you used the Add-In Manager to load the add-in).

But in my case, the Initialize method was being called twice. How was that?

It happens that there is a subtle behavior here: when an add-in marked to load on startup loads in turn another add-in (using EnvDTE.AddIn.Connect = true), in the second add-in the OnConnection method is called with the ext_ConnectMode.ext_cm_AfterStartup flag, AND the OnStartupComplete is called too!!! (because the Visual Studio IDE was not initialized when the first add-in was loaded on startup). So, the Initialize method is called twice.

I was about to report this as a bug, but I have thought that maybe the behavior is correct after all, that is, when VS has finished its initialization it calls OnStartupComplete for all add-ins that are loaded in that moment, independently of whether they were marked to load on startup or they were loaded by another add-in marked to load on startup. And what is really misleading is the MSDN documentation about the OnStartupComplete method:

(OnStartupComplete) “Occurs whenever an add-in, which is set to load when Visual Studio starts, loads.”

That implies that if add-in is not set to load on startup, its OnStartupComplete method will not be called.

The Remarks section is correct, though, since it does not relate the OnStartupComplete call to whether the add-in was set to load on startup or not:

“On occasion, OnConnection does not occur correctly, such as when an add-in is loaded, but a component required by an add-in has not yet loaded. This is unusually due to the fact that Visual Studio has not yet started completely. Using OnStartupComplete guarantees that the Visual Studio integrated development environment (IDE) has completed the startup process.”

As you realize, this is a subtlety that your add-in won’t experience unless is loaded by another add-in when Visual Studio is started.