My MZ-Tools add-in was experiencing a random “System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.” when using the EnvDTE.DTE.ActiveSolutionProjects property that I knew that other developer reported in the MSDN VSX Forum in January. Today I tested a guess of Ryan Molden (from Microsoft) in his answer about a dependency on the visibility of the Solution Explorer and he was right.

But when I was writing the corresponding MZ-Tools Series article as I always do to document all the issues and bugs of the Visual Studio automation model (EnvDTE), I noticed that the problem didn’t happen in Visual Studio 2005 or 2008, only in VS 2010, so rather than considering it a “by design” issue, I opened a bug at Microsoft Connect:

BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown
https://connect.microsoft.com/VisualStudio/feedback/details/735830/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown#details

So, in VS 2010 the problem happens when one condition is met: The Solution Explorer is not shown.

Then, I tried in VS 11 Beta, which is more annoying because the Macros IDE is gone and you have to use an add-in to reproduce bugs, and I noticed that the problem doesn’t happen when a solution is loaded, but still happens when two conditions are met: The Solution Explorer is not shown and there is no solution loaded. So, I opened a separate bug against VS 11 Beta:

BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown and no solution loaded
https://connect.microsoft.com/VisualStudio/feedback/details/735835/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown-and-no-solution-loaded#details

Since my laptop has several software issues that will require a fresh installation at some point in the near future, I decided to install VS 11 Beta side by side with VS 2010, and one thing that I noticed the other day was that my MZ-Tools add-in, when loaded in VS 2010, was showing gray pictures (rather than color pictures) for controls of the System.Windows.Forms namespace in some of its features.

Yesterday I decided to investigate the glitch and I noticed that the Document Outline built-in toolwindow of VS 2010 was also affected. Since my add-in gets the icons from the embedded resources of the System.Windows.Forms library, calling type.Assembly.GetManifestResourceStream(type, type.Name & “.bmp”), I used .NET Reflector to examine the resources and certainly it seems that VS 11 Beta installs a new version of System.Windows.Forms 4.0.0.0 that uses the new awful gray icons for controls, while the original System.Windows.Forms 4.0.0.0 of VS 2010 used colored icons. This seems to be a case of breaking the look & feel backwards compatibility of a product 😉

I reported it to Microsoft last night. You can see the attached image in the bug report to know what I mean:

Document Outline toolwindow of VS 2010 shows icons of VS 11 Beta (gray)
https://connect.microsoft.com/VisualStudio/feedback/details/735124/document-outline-toolwindow-of-vs-2010-shows-icons-of-vs-11-beta-gray#details

So, not only the new developer experience of VS 11 is the most hated feature, it also affects some features of VS 2010 and 3rd party extensions for that IDE when VS 11 Beta is installed side by side. And AFAIK, Microsoft continues to be silent about the future of the new look and feel introduced by VS 11 Beta, despite the huge negative response of the community of VS developers.