Hand-holding for Dummies




I am an inveterate builder of addins for Excel. They are so
flexible, so easy to build, but they have a potential deployment issue. Yes I
know that for most of you installing an addin is trivial, but I create them for
corporations as well, and they either

a) cannot afford to go to every desktop and install addins
manually, or

b) cannot assume that all of their staff who might need the
addin can install it themselves (even if they have the necessary permissions) .

Of course, the solution is well known, build a
self-installing executable. There are many good products around, such as Wise,
Setup Factory. The downside of these is that there is a cost, a healthy cost,
and as well as being an inveterate addin builder, I am an inveterate
cheapskate. We also have the Windows Installer (is this free?), but I have only
ever used it to install a product, I have never built installers with this.

Which brings me to the point of this post. I have been using
a remarkable free installer for some time now, Inno Setup. Jordan Russell’s tool is superb, to
quote it’s own PR … Inno Setup is a free installer for Windows programs.
First introduced in 1997, Inno Setup today rivals and even surpasses many
commercial installers in feature set and stability…
I don’t think there is
anything to argue with there. It is even free for commercial use.

The installation details are scripted in an .iss file, basically a batch instruction file, which
is divided into various sections where you add the various installation specific details. The sections include:

[Setup] defines
the basic setup details, such as the default directory name for the application
(it has some constants, such as pf
for Program Files), license file if there is one, the images to use in the
installer and so on

runtime messages can be defined here

custom messages can be defined here, and used in the code section (see later)

[Files] a simple list of all of the files to be installed,
and where to store them

[Registry] any registry
key updates that the installer will run

[Code] where you
can add installation specific code. This code has to be written in Pascal, the
product is written in Delphi after all. Here you can use the messages mentioned
above, such as a message to shutdown all versions of Excel before continuing.
It could test if Excel is running

CurPageID = wpWelcome then




XLIsRunning do


:= MsgBox(‘Please close Excel before continuing’, mbError, mb_RETRYCANCEL);

mpRet = IDCancel then Abort;




function XLIsRunning(): Boolean;


// Note – this will not detect invisible instances of xl
running (but that should be unlikely)



            Result :=

FindWindowByClassName(‘XLMAIN’) <> 0 then Result := True;


Most interestingly for me, it can be used to automatically
update the registry so that the next time that Excel starts the addins are already
added to the addins list, and thus will build their menus, initiate and so on
when Excel starts. If you want your addin in the addins list automatically, you
have to update the registry (when you install an addin manually, the registry
is updated the next time that you close Excel, that is why it is there next

In Excel addin details are stored in HKCU\software\Microsoft\Office\n.n\Excel\Options,
where n.n is the version number. Each addin is assigned the next available key
OPEN, OPEN1, OPEN2 etc. These are simple string value keys with the full path
of the addin.

Of course, life is never that simple. If your addin could be
deployed across many Excel versions, you have to cater for them all. The key
given above is the key location for Excel 2003 (version 11.0),  is also true for Excel 2002 (version 10.0),
Excel 2000 (version (9.0), and even Excel 2007 (version 12.0), but is not true Excel
97 (version  8.0), this key is HKCU\Software\Microsoft\Office\8.0\Excel\Microsoft
. Thus any installation code needs to account for this.

My usage of the tool just scratches the surface of its full
capabilities, but even so, it has become indispensable to me. I look forward to
seeing how it fares when I start deploying .Net solutions, I am very confident.

As I said, another great tool which I use for all of my
addins. There is even an active support forum.


Because it is such a good tool, there is the usual spate of
added-value addons.

Bjørnar Henden has
created a GUI front-end for creating and editing Inno Setup Scripts, ISTool. I have used this, and it is good, but
personally I am not GUI mad, so I stick to the batch file style. After all,
most are copies and then a few updates.

Another GUI front-end for creating and editing Inno Setup
Scripts is Jonny Kwekkeboom’s ScriptMaker. I have not tried
this myself.

A new one that I haven’t tried, but looks very interesting,
is a tool that adds customizable skin support to Inno Setup installations, Codejock
’s ISSkin.

I did also find a decompiler somewhere, that saved me once
when I lost my source file, but it is not listed on the Inno site, so I will
have to look again.


12 thoughts on “Hand-holding for Dummies

  1. Bob et al,

    When I used Inno Setup back in the 2004 we had a plug-in that solved the registration process for native add-ins. At that time the only GUI around was ScriptMaker. Whenever I need to deploy native add-ins I use Visual Installer which a Swedish corporate has developed. Only two lines of script is required to fix the registrationUnregistration process.

    (As many of You probably already know; If we work with COM add-ins (unmanaged / managed) the deployment procedure is simplified compared with native add-ins.)

    Anyway, I really like Your blog so please keep up the good work.

    Thanks and all the best,

  2. Hello,

    I also think InnoSetup is a great tool. The script that I developed for my open-source addin provides complete support for registering/unregistering addins, as well as shutting down Excel and restarting it after the installation.

    If anyone is interested in the code, drop me a line at xltoolbox@gmx.net



  3. @Jon, really, this is a family blog

    @Dennis, thanks for those kind words. My code for deploying addins accross multiple versions is a little bit more than 2 lines . I assume you mean that Visual Installer is what you use now, that Inno plugin was something different? Do you recall what it was called?

    I really should get into using COM addins more. I have written quite a few, but by default I automatically turn to native addins.

  4. Albert Kallal has developed Inno scripts for distributing Access runtimes and Access MDB/ACCDEs. So I’ve been happily using Inno myself as well.

    Just curious though. If you update the addin how does the corp IT get the new addin distributed to the client PCs?

    Tony Toews, Access MVP

  5. Bob,

    Yes, I use SamLogic’s Visual Installer now and it can also make the necessary registry entries when several Excel versions are installed side by side.

    As for the plug-in the best shot would be to ask Jonny Kwekkeboom if he remember and if he knows where to get it.

    For most Excel developer managed COM add-ins are a compliment to native add-ins.
    There are a couple of reasons to, at least, start to use them;
    – Protection of intellectual property
    – Meet modern security requirements
    – Target Excel 2000 – 2010

    Kind regards,

  6. Just re-install the addin. Inno remembers the last installation directory, and no harm will come by overwriting and re-upadting the registry.

  7. @Dennis, I know the reasons for using them, and they are in the toolkit, it is just that native addins are so easy . That I fear is one of the things that MS do not properly appreciate as they wish to push us to the next generation, they have to make it as easy.

  8. I use this too, it is a great tool. I never got my head around the open1, open2, bit so, I just have a little VB app that using the object model to install the addin, I should update that really.

Leave a Reply

Your email address will not be published. Required fields are marked *