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

This is one of those rare cases where both the Name and FullName properties of an EnvDTE.CodeElement can return an exception “by design”!:

PRB: FullName and Name properties of EnvDTE.CodeElement return exceptions for using/Imports statements of C# and VB.NET
http://www.mztools.com/articles/2011/MZ2011013.aspx

Fortunately, there is an easy workaround.

Another question that is asked from time to time in the forums and whose answer requires some ellaboration and references to other articles:

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