MZ-Tools Articles Series: BUG: EnvDTE.FontsAndColorsItems.Item(“Keyword”).Background not updated after changing Visual Studio 2012 theme.

One of the things that you need to test in a Visual Studio 2012 add-in or package is that is themed correctly when the VS theme is changed dynamically from Dark to Light or viceversa (through the Tools, Options window). I noticed that sometimes the textboxes that show colorized C# or VB.NET code in my MZ-Tools 7.0 add-in were showing an incorrect background for strings, comments and keywords. I use the RichTextBox control and I get the color information from the EnvDTE.FontsAndColorsItems class, as explained in the article:

HOWTO: Get the text editor font and colors information in a Visual Studio add-in

After reading this thread in the VSX forum, I realized that it happened when switching themes. And today I have filed a bug to Microsoft Connect:

EnvDTE.FontsAndColorsItems.Item(“Keyword”).Background not updated after changing theme

And I have documented it here with the workaround that I am using:

BUG: EnvDTE.FontsAndColorsItems.Item(‘Keyword’).Background not updated after changing Visual Studio 2012 theme

The workaround is not perfect but I also played with the RefreshCache method of the IVsFontAndColorCacheManager interface to no avail.

MZ-Tools Articles Series: reached 200 articles

After my first trip to the Microsoft campus at Seattle / Redmond back in April 2004 for the MVP Summit, shortly after being awarded as MVP, I returned with a boost of energy to do things related to the extensibility of Visual Studio with add-ins. One of the things was to start writing small articles about how to do common things, repetitive questions that appeared in the forums (at that time the now dead Yahoo forum about Visual Studio.NET add-ins). Although I started writing Microsoft Knowledge Base Community Articles, soon I decided to create them on my own MZ-Tools web site, as sections in these two pages:

Resources about Visual Studio .NET extensibility

Resources about Office extensibility

Last night I wrote the article #200. And I think I have material to write a few more 🙂

MZ-Tools Articles Series: BUG: EnvDTE.CodeElement.StartPoint.Line wrong result with duplicated ‘using’ statement.

The other day a customer of MZ-Tools 7.0 reported an exception in the Sort Code Elements feature that after investigation turned out to be a bug of the file code model.

I have documented it here:

BUG: EnvDTE.CodeElement.StartPoint.Line wrong result with duplicated ‘using’ statement.

And I have reported it to Microsoft Connect:

EnvDTE.CodeElement wrong start line for duplicated “using” statement

MZ-Tools Articles Series: HOWTO: Debug Visual Studio assemblies with .NET Reflector.

I am thrilled to write about this new technique that I discovered only some days ago. While I have been using .NET Reflector since many years ago to disassemble .NET and Visual Studio assemblies to understand how they work, until now I had to use my brain as debugger when trying to figure out things.

Some time ago Microsoft provided a way to debug assemblies of the .NET Framework. With the .NET Reflector tool (VSPro edition) and the approach presented here, you can debug Visual Studio assemblies too. In the sample provided, you can debug the installation of an extension through the Extension Manager of Visual Studio:

HOWTO: Debug Visual Studio assemblies with .NET Reflector.

Cyan: Another magic color for developers of Visual Studio 2012 add-ins

So far there were two magic colors to be known by developers of Visual Studio add-ins:

Ryan Molden (Visual Studio team) posted in a comment here explaining that you can exclude a custom bitmap of a command from being color-inverted in Visual Studio 2012 when using the Dark theme setting the top-right pixel of the picture to the Cyan value (RGB = 0, 255, 255). This allows you to create an add-in that appears colorful both with the Dark and Light themes, provided that the borders appear fine with dark background (you can use ARGB bitmaps with partial opacity if needed).

I have updated the first article to include this information.

Another strange case of error 80131522 loading a Visual Studio add-in

OK, this is a post mainly for me (to be found in the future) because yesterday it was the second time that it happened (and I barely remembered the first one). It is a so subtle scenario that it can only happen if you create lots of add-ins for multiple versions of Visual  Studio (I need to do this for the MZ-Tools Articles Series about developing Visual Studio add-ins) and some day you do not clean up properly.

So, yesterday this is what happened:

  • I created an add-in named MyAddIn1 in Visual Studio 2005 (I tend to use this IDE for the samples of articles to ensure that I use .NET Framework 2.0).
  • I edited the file MyAddIn1 – For Testing.AddIn in the “C:\Users\<user>\Documents\Visual Studio 2005\Addins” folder to add <HostApplication> entries for Visual Studio 2008 (9.0), 2010 (10.0) and 2012 (11.0).
  • I copied the file MyAddIn1 – For Testing.AddIn to the AddIns folders of those IDEs.
  • I loaded the add-in using the Add-In Manager (the add-in was marked not to load on startup) and it loaded correctly in VS 2005, 2008 and 2010, but I got error 80131522 in VS 2012. What???

I was well aware that the usual cause for that cryptic error is when the namespace and class name of the “Connect” class in the code don’t match the value of the FullClassName tag of the .AddIn file, as I explained in this article:

HOWTO: Troubleshooting Visual Studio and Office add-ins

But this was not the case, because the .Addin file was exactly the same (copied to four folders) and in fact the add-in loaded correctly in three IDEs. So, I used ProcMon to see if I noticed something strange:

HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems

I certainly I found that the first appearance of MyAddin1.dll was being loaded from the folder “C:\Users\<user>\Documents\Visual Studio 2012\Projects\MyAddin1\MyAddin1\bin”, not from the “C:\Users\Carlos\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddIn1\bin”. So, there was a second add-in dll named MyAddIn1.dll (from the past) that was being loaded before the MyAddIn1.dll created with the steps above. This dll used a different namespace for the Connect class (even subtly “MyAddin1” vs “MyAddIn1”, notice the different case of just one letter) and therefore the error 80131522.

The only thing that remained unexplained yesterday was why this old MyAddIn1.dll was loaded at all if I replaced its “MyAddIn1 – For Testing.AddIn” file by the new one pointing to the folder “C:\Users\<user>\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddin1\bin” (I remembered the Windows Explorer prompt to confirm replacement) and today I have found the explanation: this old add-in created a permanent CommandBarButton, so its underlying MyAddIn1.dll file was loaded. As soon as I removed that button, the new add-in loaded fine.

Bottom line: the error 80131522 can happen if a wrong add-in dll (with the same name) is loaded. The ProcMon tool should help to find the folder where an add-in dll is being loaded from.

MZ-Tools Articles Series: HOWTO: Get the bitmap of a component type from Visual Studio add-in

Continuing with the problems introduced by the new gray icons of Visual Studio 2012, my new article explains the approach that Microsoft used to solve this problem that I reported:

Document Outline toolwindow of VS 2010 shows icons of VS 11 Beta (gray)

My MZ-Tools add-in provides a Control Explorer feature that is like the Document Outline feature of Visual Studio but enhanced (multi-selection, property grid with most used properties, etc.). After weeks theming MZ-Tools icons, toolwindows and modal forms, the last piece was how to get the gray icons of controls and components in the treeview of that feature like the Document Outline does, rather than the colored ones. It took me several hours of investigation but I figured it out:

HOWTO: Get the bitmap of a component type from Visual Studio add-in

Incredible as it is, while the Document Outline of Visual Studio 2012 uses that approach, the Toolbox doesn’t. The gray icons of the System.Windows.Forms controls used in the VS 2012 toolbox seems to be stored in a unmanaged resource dll (Microsoft.VisualStudio.Windows.FormsUI.dll in the folder C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\1033). I don’t know why yet but I will investigate it some other day (all this is quite exhausting).

Dark/Light themes headaches in Visual Studio 2012

On Sep 12 Microsoft launched Visual Studio 2012, arguably the ugliest Visual Studio version ever launched according to very strong feedback from the community of developers. For the first time Visual Studio added support for themes. It is arguable if individual applications should be themed, or if themes should be provided by the operating system and applications should just be themed automatically. Anyway, Microsoft Office initiated that path a few years ago with Office 2007 (own theme and fonts) and Visual Studio followed suit. The problem is that rather than providing full support for themes, Microsoft has just supplied two themes (Light and Dark) that provide new icons and lack color, and it hasn’t provided a Visual Studio 2010 theme. Not everybody likes the new icon style, and Microsoft has been reluctant to add color (some in the Release Candidate and apparently there is more coming slowly). Furthermore, after people complaining about ALL CAPS captions in toolwindows, the fix was to make the main menu all caps instead.

Since then, two development efforts in opposite directions are happening:

On the one hand, people that find VS 2012 unpalatable are trying to get back color and icons to the IDE:

– You can now use multiples themes (not just Dark/Light) using the Visual Studio 2012 Color Theme Editor available on the Visual Studio Gallery.

– Some people are even patching the icons of VS 2012 to replace them with the ones of VS 2010: Visual Studio Icon Patcher, a so crazy idea that can even work.

-Note: Microsoft provided a registry entry to remove the ALL CAPS of top menus (HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General\SuppressUppercaseConversion, REG_DWORD value: 1), so no Visual Studio extension is required for that.

On the other hand, developers of extensions (like me) are working hard (that is, weeks or months) to adapt our add-ins, packages, etc. to the themes of Visual Studio. I have spent the last weeks doing it with MZ-Tools 7.0 and I have learned quite a bit that I will share in next posts, but suffice to say that theming Visual Studio extensions is quite a headache, even for Microsoft. For example, while all Visual Studio 2012 toolwindows are themed, only a few modal forms are (New Project, Add Reference, etc.) but many others are not (most notably, the Options window). This is because new forms use WPF while old forms use Windows Forms, and not all Windows Forms controls are well suited for themes (TabControl tabs, ListView header, disabled controls), so it is tricky, specially if you don’t own all the content of a modal form.

Microsoft has had also issues with the new themes, like these ones that I have reported, some of which were fixed for the RTM:

Document Outline toolwindow of VS 2010 shows icons of VS 11 Beta (gray)

(this was fixed with a convoluted hack that I will explain in a future post/article)

And others are not fixed yet:

Document Outline dropdown menus with black forecolor with Dark theme

MZ-Tools Articles Series: BUG: Command.Bindings causes Exception when setting value from an add-in in localized Visual Studio.

This is another bug that happens in localized versions of Visual Studio when an add-in needs to re-create a command for whatever reason and it tries to preserve the existing command binding:

BUG: Command.Bindings causes Exception when setting value from an add-in in localized Visual Studio.

I have filed a bug through Microsoft Connect:

EnvDTE.Command.Bindings causes Exception when setting value from a Visual Studio add-in

And Ryan Molden (VS team) posted a workaround in this thread of the Visual Studio Extensibility forum.

Update (19-OCT-2012): the list of keys to translate with that workaround is the following (these constants are got from Common7IDE1033msenvui.dll):

13358,     “Ctrl”
13359,     “Alt”
13360,     “Shift”
13361,     “Bkspce”
13362,     “Tab”
13363,     “Break”
13364,     “Break”
13365,     “Space”
13366,     “PgUp”
13367,     “PgDn”
13368,     “Home”
13369,     “Ins”
13370,     “Del”

13387,     “Left Arrow”
13388,     “Right Arrow”
13389,     “Up Arrow”
13390,     “Down Arrow”
13391,     “End”
13392,     “Enter”
13393,     “Esc”

Visual Studio 2008 and higher:

13394,     “Clear” 

MZ-Tools Articles Series: BUG: CommandBar.Name property localized in VBA editor of Office.

Visual Studio causes problems to developers of add-ins in localized versions (as I blogged four years ago), but it is not the only one. The automation model of the VBA editor of Microsoft Office has also problems in localized versions. The CommandBar class has the Name and NameLocal properties for the English name and the localized name, but there are commandbars with its Name property localized (non-English) and others with its NameLocal property not localized (English). This poses a challenge to add-ins for the VBA editor when trying to get a commandbar by its (English) name:

BUG: CommandBar.Name property localized in VBA editor of Office.