I have created a new article that shows a whole example of an add-in creating a command and a button with a custom picture using a satellite managed (.NET) dll:

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

While I had the article HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows, it was not supplying a whole example of a working add-in. The next version of my MZ-Tools add-in will switch from being a COM-based add-in with a native satellite dll to a XML-based add-in with a managed (.NET) satellite dll, and I have found quite a few issues until it worked fine. One of them was that I wanted a single satellite dll, not one dll for each culture (“en-US”, “es-ES”, etc.) and finally I found a nice trick to accomplish that, using the AppDomain.AssemblyResolve event.

If you have followed my blog last years, you know how much I hate satellite dlls so after 4 years I finally got Microsoft to get rid of them in Visual Studio 2010 (bad luck if you want to support Visual Studio 2005 and 2008. Update: it happens that the approach also works in VS 2008). My next article will show a whole example.

A reader of my article:

HOWTO: Detect when a Visual Studio toolwindow is shown or hidden.
http://www.mztools.com/articles/2011/MZ2011010.aspx

pointed me to an inconsistent behavior of the EnvDTE80.Events2.WindowVisibilityEvents in one case, so I have investigated all the cases and I have documented all the inconsistent behaviors (which are a lot in several VS versions) in a new article:

BUG: Inconsistent behavior of EnvDTE80.Events2.WindowVisibilityEvents from a Visual Studio add-in
http://www.mztools.com/articles/2012/MZ2012001.aspx

Since VS 11 Beta exhibits the same two bugs than VS 2010, I have opened two bug reports to Microsoft:

EnvDTE80.Events2.WindowVisibilityEvents.WindowHiding event not fired when collapsing toolwindow
https://connect.microsoft.com/VisualStudio/feedback/details/729827/envdte80-events2-windowvisibilityevents-windowhiding-event-not-fired-when-collapsing-toolwindow#details

EnvDTE80.Events2.WindowVisibilityEvents.WindowShowing event fired twice
https://connect.microsoft.com/VisualStudio/feedback/details/729845/envdte80-events2-windowvisibilityevents-windowshowing-event-fired-twice#details

Another problem that can happen to an uninstaller of add-ins for the current user (not for all users) specially in Visual Studio 2005 (which require admin rights):

PRB: Uninstaller of add-in for current user fails if Visual Studio set to execute as administrator
http://www.mztools.com/articles/2011/MZ2011022.aspx

This issue affects these articles:

HOWTO: Create a setup for a Visual Studio add-in for the current user (not requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2011/MZ2011018.aspx

HOWTO: Create a setup for a Visual Studio add-in for the current user (not requiring admin rights) using using Windows Installer XML (WiX)
http://www.mztools.com/articles/2011/MZ2011020.aspx

After all these weeks creating installers and uninstallers for add-ins, either for all users or for the current user, either using InnoSetup or MSI (through WiX), I have found quite a few issues. This is one of them:

PRB: Uninstaller does not remove commands of add-in if uninstalled from another user account
http://www.mztools.com/articles/2011/MZ2011021.aspx

This issue affects these two articles:

HOWTO: Create a setup for a Visual Studio add-in for all users (requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2008/MZ2008010.aspx

HOWTO: Create a setup for a Visual Studio add-in for all users (requiring admin rights) using Windows Installer XML (WiX)
http://www.mztools.com/articles/2011/MZ2011019.aspx

If extensibility with add-ins is hard sometimes (or most of the time), creating setups for add-ins is incredibly difficult always, no matter which installer technology you use. If COM-based add-ins of VS.NET 2002/2003 (still supported in VS 2005, 2008 and 2010) were complicated (they required COM-based registration and Windows Registry-based registration), XML-based add-ins of VS 2005 and higher (which only require file-based registration) are complicated too, and they are far from XCopy deployment, because:

• You need to put an .AddIn file in one of several specific folders of choice, but they have a lot of problems (localized, different for Windows XP / Vista, new locations in new Visual Studio versions, hardcoded subfolders, locations that don’t work), etc.
• You need to modify the .AddIn file to put its Assembly tag value pointing to the actual location of the dll file of the add-in, which requires a custom action.
• And once you have your add-in installed, you are only half the way: uninstalling it is even more complicated due to the fact that you need to remove its commands, and that requires a custom action to either:
  • Create an instance of EnvDTE.DTE, iterate its commands and remove the ones of the add-in.
  • Execute the command line devenv.exe /ResetAddin <myaddin> /Command File.Exit. For some reason beyond me Microsoft decided that the /ResetAddIn should not open invisible the IDE, make its job resetting the add-in, and close it, so you need to pass the /Command File.Exit, but you have the problem that the IDE is visible (and maximized) for a second, and good luck making that custom action invisible because most installers know how to do that with console (MSDOS) command tools, but not with Windows applications such as devenv.exe.

Needless to say, I really do hate setups, and MSI the most (very complicated). So, when I learned about Windows Installer XML (Wix), a toolset that builds Windows installation packages (MSI) from XML source code, I decided to take a look. That was back in March 2010 (I remember I was on vacation at New York) and I found MSI and WiX so tricky that despite some (failed) attempts at spare time I have been procrastinating about it until this summer of 2011, when I finally succeeded (hopefully) creating a setup using WiX that works correcty in all scenarios (fresh install, change, uninstall).

Not only I have created setups for all users (requiring admin rights) but also setups for the current user (not requiring admin rights), approaches that require some discussion that will be the subject of a couple of small articles in the next days. Meantime, apart from this old article of 2008 (now renamed):

HOWTO: Create a setup for a Visual Studio add-in for all users (requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2008/MZ2008010.aspx

I am very pleased of providing the following new samples:

HOWTO: Create a setup for a Visual Studio add-in for all users (requiring admin rights) using Windows Installer XML (WiX)
http://www.mztools.com/articles/2011/MZ2011019.aspx

HOWTO: Create a setup for a Visual Studio add-in for the current user (not requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2011/MZ2011018.aspx

HOWTO: Create a setup for a Visual Studio add-in for the current user (not requiring admin rights) using Windows Installer XML (WiX)
http://www.mztools.com/articles/2011/MZ2011020.aspx

When I started the MZ-Tools articles series about developing add-ins for Visual Studio .NET some years ago, I didn’t think that its number would grow so much so I grouped them by type:

• HOWTO
• INFO
• PRB
• BUG

At this point, with 170 articles at the time of this writing, it was even difficult for me to locate the one that I was searching when answering questions in the forums, so I have grouped them now by category:

• Articles about getting started and general information
• Articles about commands, buttons and commandbars
• Articles about toolwindows
• Articles about getting information
• Articles about custom pictures
• Articles about the code model
• Articles about Windows Forms
• Articles about Web Forms
• Articles about getting events
• Articles about installing and uninstalling
• Articles about troubleshooting, bugs and issues
• Other articles

I may tweak the categories in the next weeks but for now I think it is much better now:

MZ-Tools Articles Series (about add-ins)
http://www.mztools.com/resources_vsnet_addins.aspx

In the old times of Visual Basic 5.0 / 6.0 (which used the Office commandbars), those IDEs lacked the concept of commands that Visual Studio .NET 2002 introduced, and buttons (CommandBarButton) were created calling the CommandBar.Controls.Add method with suitable parameter values. The CommandBarButton class lacked the Click event (it was introduced in newer versions of Office) so a horrible hack to get events from buttons was provided.

It happens that Visual Studio .NET 2002 and higher still allow that way of adding buttons (without a command) and its CommandBarButton class provides the Click event, so it is quite easy. I have written an article to show this approach although it is not recommended for the reasons mentioned in the article:

HOWTO: Create a CommandBarButton without a command from a Visual Studio .NET add-in
http://www.mztools.com/articles/2011/MZ2011017.aspx

The only scenario where I have had to use this approach is in the Options window of my MZ-Tools add-in, which has controls such as listviews where I want to provide a context menu with the look and feel of the Visual Studio ones (see HOWTO: Create a context menu using a Visual Studio commandbar popup from an add-in), but I don’t want a command for the buttons of the context menu (they don’t make sense in that scenario).

As for custom pictures in buttons created with that approach, they are as difficult as usual ;-). The article provides a reference to this other article HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows which has a section about “Custom pictures for add-in buttons without a command”.

Another question that I have seen several times in the forums is how to intercept some keys in a toolwindow to perform special actions. An approach is described in my latest HOWTO article:

HOWTO: Process the Esc or F1 keys in the toolwindow of a Visual Studio .NET add-in
http://www.mztools.com/articles/2011/MZ2011016.aspx

While I have written a lot of articles and posts about the commandbars of Visual Studio (the most popular is HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in), I hadn’t written about the following case yet, that I use extensively in my own MZ-Tools add-in and that was mentioned at the end of that article but no code sample was provided:

HOWTO: Create a context menu using a Visual Studio commandbar popup from an add-in
http://www.mztools.com/articles/2011/MZ2011015.aspx

Yesterday while writing the code of an add-in for a new article I was calling Form.ShowDialog() without passing the owner window and I noticed that clicking the Visual Studio button on the Windows 7 taskbar, I got the modal form hidden behind the Visual Studio window (I had to click Alt+Tab to get the it back). Today I have been unable to reproduce this problem on another computer with Windows 7, but the other computer still reproduces it. Anyway, I already knew how to fix this problem for good, so I have documented it in this new article:

HOWTO: Show a modal form from a Visual Studio .NET add-in
http://www.mztools.com/articles/2011/MZ2011014.aspx