MZ-Tools Articles Series: new articles about setups using Inno Setup and WiX

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

Visual Studio Extensibility (VSX) Forum FAQs about add-in development

There is a sticky VSX FAQ post in the Visual Studio Extensibility (VSX) Forum since more than one year ago that is intended to collect the FAQs about development of Visual Studio extensions (packages, add-ins, templates, isolated shell, etc.). Unfortunately there aren’t many FAQ entries in each category, which is a pity. Today I have added tons of them in the “Add-ins” category, my area of expertise, pointing to the most useful HOWTO articles of my MZTools Articles Series. Hopefully they are useful for people before posting in the forum:

VSX FAQ
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/0be62d3d-84b2-4e17-a306-bcc460621192

“The system administrator has set policies to prevent this installation” on Windows Server

I am these days creating setups of add-ins for Visual Studio using MSI and today when executing a setup intended for the current user (not for all users), not requiring admin rights, on Windows 2008 Server with a standard user account I have got the following error:

“The system administrator has set policies to prevent this installation”

I was not familiar with Windows Server and those policies but I needed a clean machine to test several setups and it happens that I had a clean virtual machine with Windows Server, SharePoint 2007 and Visual Studio 2010 so I used that. After searching the web I have learned that this problem is caused by the value DisableMSI (or lack of it) in the registry entry:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

See:

DisableMSI (Windows)
http://msdn.microsoft.com/en-us/library/aa368304.aspx

Creating that registry entry and name and setting its value to 0 solves the problem and a standard user can install a MSI setup that doesn’t require administrator privileges on Windows Server. Client Windows have a different behavior as explained in that article.

MZ-Tools Articles grouped by category

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

MZ-Tools Articles Series: HOWTO: Create a CommandBarButton without a command from a Visual Studio .NET add-in

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”.

MZ-Tools Articles Series: HOWTO: Process the Esc or F1 keys in the toolwindow of a Visual Studio .NET add-in

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

MZ-Tools Articles Series: HOWTO: Create a context menu using a Visual Studio commandbar popup from an add-in

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

MZ-Tools Articles Series: HOWTO: Show a modal form from a Visual Studio .NET add-in

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

MZ-Tools Articles Series: PRB: FullName and Name properties of EnvDTE.CodeElement return exceptions for using/Imports statements of C# and VB.NET

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.

MZ-Tools Articles Series: HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.

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