Category Archives: VS 2012

How to detect Visual Studio 2012 theme changed using IVsBroadcastMessageEvents

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.

MZ-Tools Articles Series: HOWTO: Get the current theme and detect changing it from a Visual Studio 2012 add-in.

I am currently adding support for the Dark / Light themes of Visual Studio 2012 in my MZ-Tools 7.0 add-in for Visual Studio, which is resulting much harder than expected because there are a lot of issues. I will blog about them in a future post when the work is done, but meantime I have written this sample to show how an add-in can know the current theme and how to get notified when the theme is changed:

HOWTO: Get the current theme and detect changing it from a Visual Studio 2012 add-in.
http://www.mztools.com/articles/2012/MZ2012012.aspx

One thing that may surprise you is that if you have opened several VS 2012 instances, changing the theme in one of them changes it in ALL of them. So, it is not enough for an add-in to know when the theme has been changed through the Tools, Options window of the instance where it is hosted. Visual Studio 2012 broadcasts a

WM_SYSCOLORCHANGE message
, so an add-in must intercept that message through some top-level window. While an add-in could do subclassing of the main IDE window, that’s an approach prone to crashes if two extensions do the same (because subclassing must be undone in reverse order), so my sample uses a dummy invisible top-level form.

The new Visual Studio 2012 IDE and SDK introduces new services and methods related to themes, for example the IVsShell5 interface of the Microsoft.VisualStudio.Shell.Interop.11.0.dll assembly, so maybe there is some other way to get notified when the theme changes (I don’t know), but my approach with MZ-Tools is to use a single binary add-in dll, so I can’t add as references assemblies that are not in VS 2005, as I explained in the article:

HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.
http://www.mztools.com/articles/2011/MZ2011012.aspx

MZ-Tools Articles Series: BUG: Setting CommandBarPopup.Visible to False doesn’t work when CommandBarPopup in context menu.

When I thought that I have fixed the bug that I explained in my last post, I found another subtle one: in VS 2010 and 2012, setting to False the Visible property of a CommandBarPopup was not honored if the CommandBarPopup was created on a context menu (for example, in the Code Window context menu), but it worked if created on a Toolbar (for example, the Standard toolbar).

This is another bug introduced in the WPF-based commandbars of VS 2010, since it works as expected in VS 2008 and before. Unfortunately I was unable to detect these two bugs back in 2009 during the VS 2010 beta since MZ-Tools 6.0 did not offer the more complete customization offered by the new MZ-Tools 7.0 version to show / hide buttons and dropdown menus. But fortunately, the workaround is as easy as adding the children CommandBarButtons before setting the Visible property to False.

I have written a small article to document it:

BUG: Setting CommandBarPopup.Visible to False doesn’t work when CommandBarPopup in context menu.
http://www.mztools.com/articles/2012/MZ2012008.aspx

And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):

https://connect.microsoft.com/VisualStudio/feedback/details/758545/commandbarpopup-visible-false-doesnt-work-when-commandbarpopup-in-context-menu#details

MZ-Tools Articles Series: BUG: CommandbarPopup.Caption changes CommandbarPopup.CommandBar.Name and viceversa.

A couple of days ago a customer of the new version MZ-Tools 7.0 for Visual Studio reported a bug regarding the dropdown menus visibility not preserved across Visual Studio sessions. I isolated the bug which happened to be a bug in the WPF-based commandbars of Visual Studio 2010 (and 2012), not happening in VS 2008 and before.

I have written a small article to document it:

BUG: CommandbarPopup.Caption changes CommandbarPopup.CommandBar.Name and viceversa.
http://www.mztools.com/articles/2012/MZ2012007.aspx

And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):

https://connect.microsoft.com/VisualStudio/feedback/details/758550/commandbarpopup-caption-changes-commandbarpopup-commandbar-name-and-viceversa#details

Visual Studio 11 User Interface Updates Coming in RC

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…

Bugs with the EnvDTE.DTE.ActiveSolutionProjects property with VS 2010 and VS 11 Beta

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

VS 11 Beta issue: making System.Windows.Forms of VS 2010 gray too

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.

VS11 Beta bug: it does not raise AppDomain.AssemblyResolve to receive the satellite dll in add-ins in localized versions

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.

VS 11 Beta issue for add-ins and extensions: asynchronous solution loading

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.

VS 11 Beta: language packs

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.