InstallAware

Using V9R2. I have a collection of about 15 installers for our various programs, all built as single-file EXEs. I also have a "master" installer which at the top of the "Define Setup Globals" region, right after all the variables are set up, looks in its $EXEDIR$ for the various other installer EXEs by filename and, for each one it finds, it creates a component. It then will run-program the selected components' EXEs after the offline content is installed in the Main region.

None of this can be done as web content - our software often goes into places that, due to government security requirements, cannot see beyond the plant's firewall. If I build the master installer as uncompressed, everything works fine; if I build it single-file, it fails because $EXEDIR$ then holds the temp decompress dir. But I really need to be able to build this as single-file, as our field-service people will sometimes copy the latest version of everything to their thumb drive via VPN from their hotel room before going into the customer's plant, and they have a tendency to forget the DATA directory or otherwise screw up downloading the set of files for an uncompressed installer.

So I need a way in the script to get the folder containing the original compressed EXE. I have not found a way to do this. Is this possible? If not, is there a technique for building this sort of "master" installer that gets around this limitation?

Thanks!

Steve Sneed

Dear Steve,

I would suggest adding your installers to the Support Dir of your main exe (accessible from the MSIcode tab under the Support Files caption). Then, you would be able to access these files by using the path $SUPPORTDIR$\yourinstallers.exe.

Does that make sense?

Makes sense - I'll try it. Thanks!

Steve

Follow-up: The supportdir idea won't work because it pulls all the child-installer EXEs into the master installer archive. Besides making the master installer impossibly huge, it means that the master installer will need to be rebuilt each time there's a new release of any one of the child installers, both of which defeats the purpose of having the child installers. Sorry.

Before I took over this shop, they had used InstallShield with that sort of all-in-one structure that they had to edit the script and rebuild the master installer each time they put a build together for a given customer. In our environment, different customers get different combinations of programs - some only get 1 or 2, some get as many as 7 or 8, and some have one or more additional custom programs specific to their needs - so the constant rebuilds are a real problem (not to mention impossible to keep track of in our ISO paperwork.) My hope here was to have an installer system such that the field-service people only have to copy a list of child installer EXE files by filename for a given customer, and the master will handle whatever combination of child installers that it finds.

Any other ideas? Thanks!

Steve

Dear Steve,

How are your people "compiling" these installers?
Another idea:
Create a script (in python, e.g.) / program / DLL / whatever else that works for you that your field-service people can use.
This script will receive an input of the child installers that are to be used. The script will then create a 7ZIP archive that contains those child installers.
Your main installer will look for this archive in its directory (or wherever else you wish), extract it, and install whatever EXE that was found in this archive.
This way, your field-service people can use your script to create different "data" archives (like in your 1-2 or 7-8 example). This archive, when put together with your main installer, will constitute your installation.
What do you think?

Aviv -

Thanks. And sorry if I wasn't clear: I am the only one that builds the installers. Each program of ours has its own V9R2 script and builds to a single-file installer; these can then be used to individually update a given program as needed at a customer's site. The master installer is used only when installing multiple programs the first time at a customer; it not only calls the other installers, but itself installs a set of small utility programs like a firmware updater and an application startup sequencer (some of our programs that control process hardware are sensitive to startup order.) As the master installer calls the child installers, it also creates the appropriate entries in the config for the startup sequencer.

At this point, I am going to build the master uncompressed, 7ZIP up its files, and write a batch file to do the housekeeping. Please consider for future versions a predefined var that contains the path to the original installer EXE that's correct even when built as single-file.

Thanks again,

Steve

Dear Steve,

Let me see if I got this straight - you are saying that in single file deployment, the $EXEDIR$ points to the temp folder to which your installer was decompressed and therefore you don't know where your actual single file installer was run from?

Aviv -

That's the problem exactly. If I knew the folder where the original single-file EXE for the master installer was, I could do what I'm trying to do.

Steve

Dear Steve,

Now I get it! Here is what you need - instead of reading the EXEDIR variable, check out the SETUPPATH variable. This variable is exactly what you are looking for since it provides a convenient mechanism to detect the outermost folder containing the executable program or setup database that initiated the installation. In other words, this variable will contain the path from which your singe-file installer was run.
Was that helpful?