In this post I showed an approach using an invisible form to trap the WM_SYSCOLORCHANGE message that is fired when VS 2012 changes the current theme (from Dark to Light or viceversa). Don’t miss the comment in that post  where Sean points how to do it for packages using the IVsShell and IVsBroadcastMessageEvents interfaces. You can use that approach in an add-in too since you can get services as I explained in the article:

HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/articles/2007/mz2007015.aspx

I have tested it today and it works like a charm.

If Monty Hammontree and his team continue to ignore the community feedback like so far, this is the macro that you need to fix the ALL CAPS of the main menu of VS 11:

Sub NoALLCAPS()

   Dim commandBar As Microsoft.VisualStudio.CommandBars.CommandBar

   commandBar = CType(DTE.CommandBars, Microsoft.VisualStudio.CommandBars.CommandBars).Item("MenuBar")

   For Each control As Microsoft.VisualStudio.CommandBars.CommandBarControl In commandBar.Controls
      control.Caption = StrConv(control.Caption, VbStrConv.ProperCase)
   Next

End Sub

Disclaimer: I haven’t tested it in VS 11, I created a similar one to set ALL CAPS in VS 2010 just for fun and I got dismayed 😉

Oops! they removed the Macro IDE…

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.

The approach that I described in the following article to use a single satellite Dll with the “en-US” culture using the AppDomain.AssemblyResolve event doesn’t work in VS 11 Beta:

HOWTO: Create a command with a custom picture using a managed satellite DLL for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012002.aspx

I have just opened a bug report at Microsoft Connect:

VS11 Beta does not raise AppDomain.AssemblyResolve to receive the satellite dll in add-ins in localized versions
https://connect.microsoft.com/VisualStudio/feedback/details/731914/vs11-beta-does-not-raise-appdomain-assemblyresolve-to-receive-the-satellite-dll-in-add-ins-in-localized-versions#details

BTW, some other bugs that I have been reporting will be fixed in next builds of VS 11, according to the Microsoft answers. Hopefully this is fixed too.

In the Visual Studio blog it has been published the expected Visual Studio 11 Beta Performance Part #2 about changes in the solution loading experience that can explain the issues that I posted some days ago:

VS 11 Beta issue: EnvDTE.Project.CodeModel returns null for a project just loaded without open documents
https://www.visualstudioextensibility.com/2012/03/09/vs-11-beta-issue-envdte-project-codemodel-returns-null-for-a-project-just-loaded-without-open-documents

VS 11 Beta issue: EnvDTE.SolutionEvents.Opened event not fired for a solution just loaded without open documents
https://www.visualstudioextensibility.com/2012/03/09/vs-11-beta-issue-envdte-solutionevents-opened-event-not-fired-for-a-solution-just-loaded-without-open-documents

As the article explains, solution loading is now done in two phases, one “modal loading” in the main UI thread, and other “background loading”, which has important effects on extensions (add-ins, packages, etc.). Specifically the article explains why the previous issues only happen when there are no files open from the last session:

During the Modal Loading phase, we load projects most likely to be needed by the user and block the UI thread to ensure this task has the highest priority. Specifically, we create only the projects that had files left open in the last VS session or projects. We rely on the new Preview Tab feature (discussed here) to help ensure that only projects that you were actively working with in your last session are loaded in this phase of solution load. (…) Finally, we notify components and extensions that the Modal Load phase of solution loading is about to complete, so they can initialize their data models.

and:

In the Background Loading phase, we unblock the UI thread and start processing the background load tasks one at a time. Each time a project is loaded in the background, we notify components and extensions that the project has loaded.  If the user requests information about a project that has not finished loading, we immediately load that project and its dependencies (on the UI thread for maximum performance). We made this operation cancellable if you don’t want to wait. Once all project loading tasks have been processed we notify all components and extensions that the Background Loading phase of solution load has completed.

So, it seems that VS 11 notifies extensions when each project has finished loading, when the Modal Loading phase is about to complete and when the Background Loading phase has completed. The question is how add-in extensions are notified since the EnvDTE.SolutionEvents only has a Opened event and there are no events for projects, I guess that for packages new services are introduced in the SDK and Microsoft is working with “popular extensions” to address the changes and issues, but for add-ins I am not sure if new events will be introduced in the EnvDTE automation model. Maybe we will have more information when Microsoft answers the two Microsoft Connect issues that I opened.

One new “feature” of Visual Studio 11 is that it will support language packs to provide multiple languages for the user interface (UI). You can download them for VS 11 Beta here:

Microsoft Visual Studio 11 Beta Language Pack
http://www.microsoft.com/en-us/download/details.aspx?id=30681

This is something I wanted to have since long time ago (I wish Visual Studio had Multilingual User Interface (MUI) implemented as on Windows Vista). And finally Microsoft has provided this. While multiple languages for the UI is not important for most developers (they will use only one), it is a very important feature for developers of add-ins and other extensions. Why? Because chances are that you will develop your extension in Visual Studio in English and it will fail when some user uses Visual Studio in Spanish, German, French, etc. In the following post I explained things to be aware of:

MZ-Tools Articles Series: HOWTO: Testing add-ins in localized versions of Visual Studio
https://www.visualstudioextensibility.com/2010/04/01/mz-tools-articles-series-howto-testing-add-ins-in-localized-versions-of-visual-studio

(In a next post I will talk about another area to take into account: the language of the satellite dlls used by add-ins to provide custom pictures for commands and buttons, which depend on the language of Visual Studio, but I found a workaround to use only one satellite dll.)

Until now, you had to install the full Visual Studio in some language on top of the Visual Studio in some other language (and the service packs) to get the two languages in the “Tools”, “Options” window, “Environment”, “International Settings” section. Now, you can just install a language pack on top of the Visual Studio in some language, which supposedly will take less time.

But Visual Studio is half of the environment. The other half is the Windows operating system, which also varies from one language to another, and some folders are localized (for example, “Application Data” in Windows XP), which can cause bugs if you are not careful as the bug of Visual Studio described in the post mentioned above. To catch these problems since I have two computers in one of them I have Windows and Visual Studio in Spanish (my native language) and in other in English. Of course you can use virtual machines for foreign languages if English is your native language.