You may have noticed that I am not blogging too much these weeks. The reason is that I have been working on the next version of MZ-Tools (and it is too early to comment about it) and testing the VS 2010 Super-Limited-CTPs that Microsoft provide to some people to test their extensions (add-ins, packages, etc.). These SLCTPs are under Non-Disclosure-Agreement (NDA) so the bug reports are private and I can’t comment what is fixed or it is still wrong. I am looking forward to the public VS 2010 Release Candidate to provide more information in the add-ins area.

On a separate thing, I have finished watching the videos of the Visual Studio Extensibility (VSX) Developer Conference October 2009 that were of my interest. I have updated the Resources page on my web site to list all the videos.

The first thing that strikes me is that none of the 20+ sessions is devoted to add-ins, and none was devoted in the 2008 conference too. Add-ins is an area of extensibility that is basically dead for Microsoft, only maintained due to the number of add-ins out there. While not as easy as they should be, historically add-ins have been the easiest way to extend Visual Studio, and originally in VS.NET 2002, the only way to do it providing a user interface (macros don’t provide user interface, the VS SDK was not introduced until VS 2005 and the former VSIP SDK was introduced in VS.NET 2003). The EnvDTE API is not certainly elegant and it suffers lots of inconsistencies and drawbacks that I have blogged about extensively all since I started this blog back in November 2006 (it turned 3 years recently), but it worked for most of us, specially because it was powerful enough for most purposes and the alternative (the SDK) was even worse until recently. If I had to start today building a VS extension, the SDK would be the way to go, but when you have an 8-years old add-in with tons of lines of code, it is difficult to think about migrating it knowing that it will provide no added value to the end users once migrated and tested completely.

The second thing that strikes me is that there are no progress in the extensibility of ASP.NET Webforms or the new WPF / Silverlight forms for add-ins (or may even for packages, I don’t know). If your extension wants to manipulate programmatically those forms or usercontrols, it’s going to be a difficult time. The Window.Object may return something for ASP.NET forms, but nothing for WPF / Silverlight forms. AFAIK, the designer of WPF is even a separate process and when they talk about WPF Designer Extensibility, they mean extensibility for developers of WPF controls to provide editors, adorners, custom actions or menus, etc. It seems that all emphasis about VS extensions is about to explore or manipulate code, and never to explore or manipulate forms/usercontrols.

The last striking thing, on the positive side, is that Visual Studio has got so much extensibility in several areas to deserve an annual conference with lots of sessions. That’s certainly great.

Happy New Year!

I have just received the Most Valuable Professional (MVP) award again, the 7th one that I receive from Microsoft. As always, I am very grateful for this award 🙂

It always fascinates me how “creative” we the developers can be solving problems that shouldn’t exist in the first place. For example, Microsoft has been too much creative in the last decade providing multiple tricky ways to solve the lack of transparency support in the original bitmap format. And now I am seeing in several places an approach that developers of add-ins are using to avoid the satellite DLLs to provide custom pictures. The first place where I saw it was in the very MSDN documentation about displaying a custom icon on the add-in button, in the Community Content section by Miguel Ferreira.

The basic idea is to give up the picture of the command, and to modify the picture of the CommandBarButton created from the command through its Picture and Mask properties. The implementation gets more complicated because those properties have the COM IPictureDisp type and therefore conversions from managed System.Drawing.Bitmap are required, and another creative technique is used to get the mask from a picture pixel by pixel rather than providing it directly (which would force to create two bitmaps per button).

I flagged that community content as “bug” because it doesn’t solve the fundamental problem, that is, providing a picture for the command, not just for its buttons. The picture of a command is something totally visible to the user when she clicks the “Tools”, “Customize” menu, “Commands” tab, “Add-Ins” section. While it may seem not very important a lacking command picture there, it happens that with that window open VS enters in a special mode that allows the user to drag the command on a toolbar to create a button, and the button would get the picture of the command.

I saw this approach too yesterday in this post of Roy Osherove.

Fortunately these hacks won’t be necessary in VS 2010, which will get rid of satellite DLLs for add-ins “officially”.

I am now investigating why the grayscale image that Visual Studio 2005 / 2008 generates for a disabled button is so horrible/blurry for pictures of add-in commands and so crisp and precise for pictures of VS commands. VS 2005 introduced True Color bitmaps (VS.NET 2003 used 16-color bitmaps) so it should be able to generate good-looking grayscale images as it does with its own pictures (if I am correct that the disabled image is autogenerated and not provided separately through some way not available to add-ins). There are two scenarios where disabled buttons look bad:

• CommandBarButtons created from a command (via Command.AddControl). In this case the image of the button is actually the image of the command which in turn is supplied in a satellite dll in True Color (24 bit) bitmap format, so there is no much room to play…
• CommandBarButtons created on a CommandBar created by the add-in to be used as context menu somewhere, for example in the context menu of a list (New, Remove, etc.). The add-in creates a VS commandbar rather than a .NET context menu to provide the same look and feel. In this scenario, there is no command, the CommandBarButton is created via CommandBar.Controls.Add. When you cast the returned CommandBarControl to CommandBarButton you can use the Picture and Mask properties (COM IPictureDisp type) to set the image and the transparency mask, so there is much more room to play with the bitmap format, the color depth (32-bit, 24-bit, 8-bit), and how you get a COM IPictureDisp from a managed System.Drawing.Bitmap.

So far I have been unable to solve this, I will post again if I find a resolution for this issue. If someone know the solution, let me know.

According to the last notification from Microsoft, they have fixed the problem where the 6th location (%ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\AddIns) that was introduced by VS 2008 when searching for .AddIn files was broken (it’s about time):

%ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\AddIns folder is not searched for add-ins
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=466741

The fix is quite irrelevant currently because VS 2005 doesn’t support that folder and VS 2008 is broken (even with SP1), but in a few years when your add-in has only to support VS 2010 and above versions, that location will be the preferred choice because being an “all users” location:

1) It doesn’t suffer the localization problem of %ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\AddIns

2) If doesn’t force you to use separate .AddIn files for each VS version as happens with %VSCOMMONAPPDATA%\AddIns

See: INFO: Default .AddIn file locations for Visual Studio add-ins

Recently I have migrated the next version of MZ-Tools for Visual Studio .NET that I am working on from COM-based add-in to XML-based add-in (giving up Visual Studio .NET 2002/2003 support). I tried to do it many months ago but I gave up because moving to XML-based add-in meant also moving from native resource DLL to managed resource DLL, and I didn’t want to do that at that time, I just wanted to get rid of COM. But tired of the two bugs in the Visual Studio 2005/2008 Add-In Managers with COM-addins (the former one only fixed in VS 2008 and the latter one reopened and again under investigation after strong discussion with Microsoft), and tired of the problems of COM and transparent bitmaps, etc. finally I have moved to a managed satellite DLL.

AFAIK, the only official documentation from Microsoft to build a managed satellite dll for a XML add-in is the following gem in MSDN, that involves using command-line tools such as resgen.exe (Resource File Generator) or al.exe (Assembly Linker) and Windows tools such as Notepad:

How to: Display a Custom Icon on the Add-in Button
http://msdn.microsoft.com/en-us/library/ms228771(VS.80).aspx

How they can sleep well with that is beyond me ;-). I am currently trying to convince the Program Manager in charge of this to support resources in the own dll of the add-in for VS 2010 so maybe in 2014 your add-in targeting VS 2010, VS 2012 and VS 2014 can get rid of the resource dll…

Of course there is a much better way to create a resource dll that doesn’t involve command-line tools, that is, a class library project in the same solution of the add-in that provides the resources. I have updated the following article to cover this scenario:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows.
http://www.mztools.com/articles/2005/MZ2005007.aspx

I have updated also the section about toolwindow bitmaps to provide better information. I have not included yet information about VS 2010 but you have these other posts:

Solved: transparent bitmaps in add-in toolwindows of VS 2010 (Beta 1)

and

Solved: transparent bitmaps in add-in commands of VS 2010 (Beta 1)

I will update the article when the current two bugs under investigation are solved in some way or another and VS 2010 gets release candidate status.

While trying to find a workaround for the Visual Studio 2010 Beta 1 problem with command bitmaps in add-ins, and sick about the issue of transparency in Visual Studio, today I have taken a look at the Microsoft Visual Studio 2010 User Interface Guidelines that are available here:

Microsoft Visual Studio 2010 User Interface Guidelines
http://code.msdn.microsoft.com/VS2010UX/Release/ProjectReleases.aspx?ReleaseId=2743

It’s impressive the level of effort and details that Microsoft puts to get the Visual Studio interface right from point of view of “look & feel”.

But the thing that I would like to comment about is the section 11.01.01 “Creating High Color Artwork” and subsequent ones , which I have read with a mixed feeling of joy and horror: it’s incredible how many different ways to get bitmap transparency are used in Visual Studio:

• Icons (with built-in transparency)
• 24-bit bitmaps with transparent color RGB=255,0,255 (magenta)
• 24-bit bitmaps with transparent color RGB=0, 255, 0 (lime green)
• Any of the two previous at the same time
• 24-bit bitmaps with transparent color RGB=0, 254, 0 (almost lime green).
• 32-bit bitmaps with built-in transparency (alpha channel)
• The bottom-left pixel (x: 0, y: height – 1. Which sometimes needs to be magenta too!
• Code to make bitmaps transparent
• Etc.

Then, do not use Microsoft Paint, it can alter the bitmap header and color table. When using Photoshop, do not click File \ Save. Do not click File \ Export. Do click File \ Save As. And be aware of copy/paste operations… BTW, any mention to Visual Studio resource editor?

All that explained, you find this little gem: “high-color artwork integrates seamlessly into Visual Studio 80% of the time. If you’re the unfortunate developer who falls into the 20% case, this section is for you.”

The section is 11.02.04 “Debugging High-Color Artwork”, where you are provided with some images (I’m still figuring out how to extract them from a IE-only .mht file) that you can use to diagnose your transparency problem against 7 different causes (including one that can put your bitmap upside down!), that can appear combined, and that can be something new…

If this is the scenario inside Microsoft Visual Studio, it’s no wonder that add-ins (which are not part of Visual Studio on the contrary to packages) have always problems in each new version of Visual Studio for the two only things that they need transparency: command pictures and toolwindow pictures.

All this mess is caused by a problem that was solved when VS.NET 2002 was developed:

“Historically, developers only had twenty colors to work with: base 16 and four shades of gray. In Visual Studio 2002 that increased to 255 colors; however, most artwork was left at twenty colors. Because of the twenty-color limitation, early developers were forced to get creative in their use of images and palettes.”

(it seems that they were too creative…)

and then:

“Even though high-color has been around for many years now, we still need to work to remove these historic hacks and assumptions.”

To the Microsoft Visual Studio Team: how about removing all them for this very Visual Studio 2010 version? Keep it really simple: either icons, or 32-bit bitmaps (built-in transparency in both cases). No more magic colors. No more magic pixels coordinates. Given that we are forced to change our add-ins to get transparency on each VS version, you could sacrifice backwards compatibility and get this fixed for good.

If you have coded many add-ins or a complex add-in, chances are that you have encountered the dreaded System.ArgumentException “Value does not fall within the expected range.” when adding commands, buttons, commandbars, etc. Most of the AddXXX methods of the automation model receive so many parameters (many ones optional) that one little mistake and you get that exception. The problem is that you can’t know where is the little mistake because you aren’t provided the offending parameter and a hint of the problem.

I have filed a suggestion to Microsoft to make our debugging time easier:

Provide better error information in automation model (EnvDTE) for add-ins
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=469337

You can vote for it if you hate to waste your time guessing…

Although I don’t use permanent commandbars in my MZ-Tools but temporary ones, I became aware of a bug when writing the samples that use permanent user interface of the article HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in, and I mentioned it in this article and this post. The bug is that executing devenv.exe /resetaddin resets commands and CommandBarButtons, but not permanent commandbars.

Today I finally have reported it to Microsoft, just in case they want to fix it for VS 2010:

devenv.exe /resetaddin doesn’t reset permanent add-in commandbars
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=469322

If you are affected by this problem, vote for it there.

As a workaround, remove the commandbar by code in the ext_cm_UISetup phase of the OnConnection method before adding it again.

BTW, if you are curious about where VS persists information of commands, commandbars, etc., it is the file CmdUI.prf stored here (Windows XP):

C:\Documents and Settings\<user>\Application Data\Microsoft\VisualStudio\<version>\1033

where <user> is your Windows user name and <version> is:

• 7.0 (VS.NET 2002)
• 7.1 (VS.NET 2003)
• 8.0 (VS 2005)
• 9.0 (VS 2008)
• 10.0 (VS 2010)

Deleting that file removes all the commands, buttons, commandbars, etc. of add-ins or user customizations.

Since I have no much hope of getting a new EnvDTE100.Commands.AddNamedCommand3 that accepts an icon as parameter rather than a resource id, I have filed a new feature request to at least get rid of the satellite DLL just making EnvDTE80.Commands.AddNamedCommand2 to search for resources in the own add-in dll, which wouldn’t require a new method or a change in the method signature:

Make EnvDTE80.Commands.AddNamedCommand2 to search for custom pictures in the own add-in dll
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=467535

You can vote for it if you like the idea.