All posts by Carlos Quintero

MZ-Tools Articles Series, VS 2012

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

2 Comments

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, VBA add-ins

MZ-Tools Articles Series: HOWTO: Generate Interop assemblies to create an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.

This is the first article of the series devoted to creating add-ins for the VBA editor (32-bit / 64-bit) of Microsoft Office that I announced here.

It discusses the use of private vs Primary Interop Assemblies for Office, the .NET Framework 2.0 vs 4.0 to use and how to generate the private interop assemblies.

HOWTO: Generate Interop assemblies to create an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012011.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: Changing gears (just a little bit)

For the past years I have been writing articles in the MZ-Tools Series and posts in this blog about developing add-ins with Visual Studio .NET for Visual Studio .NET, using the .NET Framework. All this knowledge comes from my experience developing since 2002 the versions 4.0, 5.0, 6.0 and 7.0 of my MZ-Tools add-in for Visual Studio. As you may know, I have also the MZ-Tools 3.0 version for Visual Basic 6.0, 5.0 and the VBA editor, that I created with Visual Basic 6.0 back in 2000.

When Office 2010 came out, for the first time there was a 64-bit version, not only a 32-bit version, and, alas, the VBA editor of the 64-bit version doesn’t support 32-bit COM add-ins. So, MZ-Tools 3.0 for VBA doesn’t support Office 2010 64-bit. I have received some requests to support it, and things only will get worse as more developers install the 64-bit version. The same is happening to other developers creating add-ins for the VBA editor. Until now, the common answer was that it was not possible, since VB6 can only create 32-bit COM add-ins and Office 2010 64-bit can’t use 32-bit COM add-ins.

About 3 months ago I devoted some thoughts about it and I got the idea of developing an add-in for the VBA editor of Office 64-bit using the .NET Framework, since .NET assemblies can be 64-bit, and .NET assemblies can be registered as COM components… I was so excited that I halted the development of MZ-Tools 7.0 during a week to make a prototype and after several difficulties…I succeeded  :-).

Not only I got a Hello World prototype, but I also managed to create toolbars, buttons, toolwindows, to use a single NET .dll and setup to target the 32-bit and 64-bit versions of the VBA editor and as bonus tracks, to install the add-in without admin rights and to avoid the use of the clipboard to use custom pictures in buttons (two common sources of issues of MZ-Tools 3.0 for VBA).

So I am going to write a few articles in the next weeks to document the whole approach from start (Hello World) to end (the setup). Of course, I will keep writing about Visual Studio add-ins.

PS: the (great) future of MZ-Tools 3.0 for VB6/VB5/VBA will be announced in the MZ-Tools blog in the next months.

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Get assemblies of the Add Reference dialog from a Visual Studio add-in.

My new tutorial explains how to get the assemblies that Visual Studio shows in the .NET tab of the Add Reference dialog, since they are not the assemblies in the Global Assembly Cache (GAC):

HOWTO: Get assemblies of the Add Reference dialog from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012010.aspx

So, normally assemblies are located at two places: in some folder (to be used at development time by Visual Studio) and in the GAC (to be used by the application when deployed).

There are rare occasions where an assembly is only in the GAC, but you can even add a reference to an assembly in the GAC as I explained in this other article:

HOWTO: Reference a Visual Studio assembly in the GAC from an add-in
http://www.mztools.com/articles/2007/mz2007012.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Get loaded add-ins and installed products from a Visual Studio add-in.

I have received several bug reports in the last years about MZ-Tools for Visual Studio .NET that after some investigation I have discovered that the bugs only happen when certain 3rd party add-in or package is installed, or even not installed. For example, this one only happens when CodeRush is installed. And this other one only happens in VS 2008 if the Code Analysis Tools are not installed. And I have found another ones that I have not even documented in this blog, just patching my code to prevent them.

Since diagnosing those bugs is extremely difficult without that information, my new MZ-Tools 7.0 for Visual Studio includes in the bug reports information about loaded add-ins and installed products. I have created an article with a sample add-in to show how to get that information:

HOWTO: Get loaded add-ins and installed products from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012009.aspx

The article explains too a Registry redirection that Visual Studio 2010 and higher does, which I mentioned the first time in this post.

And you can get even more information to be included in bug reports here:

HOWTO: Detect installed Visual Studio editions, packages or service packs
http://www.mztools.com/articles/2008/MZ2008003.aspx

MZ-Tools Articles Series, VS 2010, VS 2012

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, VS 2010, VS 2012

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

The strange case of...

The strange case of VB6 prompting to repair VS 2010 when MZ-Tools 3.0 is loaded

I have got a new laptop (an Apple MacBook Air 11″) and after installing BootCamp, Windows 7, VB6, VS 2005, 2008 and 2010, yesterday I noticed that when loading MZ-Tools 3.0 for VB6, it prompted to repair Visual Studio 2010. I had received the same or similar issue from 2 or 3 users these last years that I never knew how to solve, so I could only recommend to repair or reinstall Office, VB6 ,etc. Today I have investigated more and it seems that there are multiple causes but one of them documented by Heath Stewart was certainly my case:

How to work around the issue when opening Office applications repairs Visual Studio
http://blogs.msdn.com/b/heaths/archive/2009/05/29/how-to-workaround-the-issue-when-opening-office-applications-repairs-visual-studio.aspx

That is, if there was an external drive connected when you installed Visual Studio, you get the issue when you load some Office application, or some application using VB/VBA. Of course this issue doesn’t happen if you install from the DVD, because the drive (typically D:) will be there always, but it happens if you have an external drive connected, specially if that is the drive where you are installing from!. It happened that other times I copied the setups to the internal hard drive before installing Visual Studio, but since the MacBook Air has only 128 GB of internal hard drive, I installed from an external drive.

That said, the workaround proposed in the post didn’t work for me. I guess that using the variable %ProgramFiles% on my Windows 7 64-bit rather than %ProgramFiles(x86)% didn’t help. Anyway, I got it so messed that finally I had to uninstall completely VS 2005, 2008 and 2010, which is a horrible experience because you have to uninstall lots and lots of separate setups (Visual Studio is by far the worst product regarding uninstallation). Then I started again the installations, but this time copying the media to the internal hard disk (it is a good thing to have USB 3.0 technology). And now I have 27 updates to install from Windows Update, but the issue is solved.

I hope this help others, and myself in the future 😉

VS 2012

Visual Studio 11 User Interface Updates Coming in RC

2 Comments

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…

VS 2010, VS 2012

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