MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup

4 Comments

This is another of those articles long overdue that I kept in a list and that I wanted to write. Back in 2004 I finished the first commercial version of my MZ-Tools add-in for .NET and despite my hate for setups (I much prefer XCOPY deployment to be confident that my computer remains uncorrupted) I knew I had to create one because my customers would expect it (the free versions of MZ-Tools for VB6/VBA/VB5 didn’t have a setup until many years after its origin back in the year 2000) and alas, add-ins in VS.NET are much more complicated to deploy (you needed an ActiveX/COM shim control to create toolwindows in VS.NET 2002/2003, for example).

So, my first choice was, of course, the MSI-based setup project that VS.NET 2002 created for each add-in project. The result was that, if I already hated setups, I hate MSI-based setups even more since then. I found several problems:

  • The setup used a progress bar that when reached 100%, it started again for a second phase. Being a perfectionist, I prefer a single pass from 0% to 100%, and if for some reason the setup can’t go from 0% to 50% in the first phase and from 50% to 100% in the second phase, I much prefer no progressbar at all (alas, my current uninstaller has the same problem that I have been unable to solve yet although I am close). Anyway, this is a minor detail.
  • For some customizations you couldn’t use the setup project properties, but you needed a tool named Orca MSI editor, or something like that.
  • If you want a multilanguage setup (not a different setup for each language) I think that it was not possible.
  • I needed slightly different setups for the trial version and the full version, and the setup project didn’t allow that easily.
  • And finally there was a nasty bug (or “by design” issue) that I documented and reported to Microsoft: BUG: Visual Studio .NET Setup Projects Execute Custom Action of Previous Version when Upgrading.

Finally I gave up MSI and searching alternatives, I found Inno Setup, a free script based setup. It allows multilanguage setups in a single .exe, it has preprocessor capabilities (conditional compilation that I use for the Trial/Full version) and despite being script-based it has a companion ISTool to create the setup more user-friendly. Furthermore it has great forums, 3rd party tools and web sites devoted to provide useful scripts for some tasks. And guess what? Its progress bar goes a single time from 0% to 100% and very fast :-).

So, despite being now a Microsoft MVP and being aware that Microsoft greatly recommends MSI for setups due to its transaction capabilities, if you need a setup for an add-in (not for a VS SDK package) which uses XML registration and no COM registration is involved, you are quite safe using a non MSI-based setup (FWIW my add-in uses COM registration for historical reasons and I have had no problems with my customers using Inno Setup).

Since InnoSetup is script-based and it uses Pascal as language for the custom code, I wrote a ready-to-use Inno Setup script that you can customize easily and use. The details are in the following article:

HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup
http://www.mztools.com/articles/2008/MZ2008010.aspx

4 thoughts on “MZ-Tools Articles Series: HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup”

  2. Thanks for the info. Does Inno setup check user privileges before starting the installer? Few days back, I used MSI based installation for one of my addin and it failed to create entry in registry (Lookin folder). I want user with minimum privileges also to install my addin through setup. Hope this will be possible through Inno setup.

  3. You can customize whether admin rights are required or not.

    If you register the add-in using per-user registry (HKEY_CURRENT_USER) or per-user folders, it will work fine, but notice that on Windows Vista, without admin rights the user won’t be able to install on C:Program Files, which is the default folder for installations, he will need to use one of its own folders (C:Users) which is weird for an installation.

Comments are closed.