Hand-holding for Dummies



Normal
0


false
false
false







MicrosoftInternetExplorer4










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


[Messages] runtime messages can be defined here


[CustomMessages] 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


            if CurPageID = wpWelcome then


 


                        begin


 


                                    while XLIsRunning do


                                                begin


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


                                                            if mpRet = IDCancel then Abort;


                                                end;


                        end;



//—————————————————————————————————–


function XLIsRunning(): Boolean;


//—————————————————————————————————–


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


//—————————————————————————————————–


begin


            Result := False;


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


end;


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 time).


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 Excel. 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 Software’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,
    Dennis

  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

    Best

    Daniel

  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,
    Dennis

  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 *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>