Recently I was working on a project and it required the Sage Data Objects to be installed for the application to work correctly. Already packaged setups, I had to come up with a strategy to install them with my application package – built as a Basic MSI project. After finding out the Sage packages were built as a InstallScript MSI package I knew they would collide unless I nested them (deprecated) or ran them as Immediate Custom Actions – which I detest because the client may cancel the install during the dialogs, but the Sage was forced on their workstations.
Finally I decided to “repackage” them as Setup Prerequisites, so after completing this I decided to create a simple tutorial to guide others in this task. Hope it helps!
Note: All dialog screens are from InstallShield v2009.
First, look at the Redistributables selection – the middle panel shows you the final results of our created prerequisite. In this case I had to create three (3) separate one, for each applicable version that was to be distributed. Note the names are somewhat wordy – I initially used “SDObj15” but when it was installing, it was so cryptically it was unusable. So write it out so the customer knows what is being installed.
The setup prerequisites will end up being stored in the sub-directory “SetupPrerequisites” under the location where InstallShield was installed. In my case it’s “C:\Program Files\InstallShield\2009\SetupPrerequisites”. They will be stored as PRQ files (my example would be “Sage Data Object Engine v15.prq”) – so be sure to stage them into your Source Repository afterwards before you misplace them!
To get started, we need to open the Prerequisites Editor – accessible from the “Tool\Prerequisites Editor” dropdown menu choice. You will be presented with this blank panel:
Go ahead and save this using your new name (example: Sage Data Object Engine v15)
Now select the first tab “Properties” and let’s review:
Prereq Properties
Note the pre-generated “unique identifier” that is associated with this Prereq – it’s used to stage the separate file in the Windows Temp directory during extraction and execution. Preserve its value. Add a description for clarity.
If the file is of considerable size, you may want to consider hosting the file on a website. This will work if you are certain that every customer will be installing on a network connected workstation. Remember there are some installations that are secure networks and are not allowed internet capability – this should be your guide as to where to host it or incorporate it within the setup. An example of the web site would be http://www.InstallSolutionsInc.com/prereq
Prereq Conditions
The next tab is “Conditions” which we can modify to see what conditions this EXE will run under:
There is a condition that we want to occur before the prereq for Sage Data Object v13 needs to meet before we consider installing it. Select the button Add to create the first condition.
For this Prereq, I am looking for the existence of the file “sg50SdoEngine150.dll” that would have been installed into the Windows System32 file. In addition I am checking that the version number is at least the one delivered with the EXE itself. Obviously I would have to have installed the Sage setup to gather this information. I just could have easily looked in the registry for the GUID under “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” and set to condition to install the Prereq if that registry did not exist.
Remember you can chain the conditions together. For example if I was installing the Microsoft Office 2007 Primary Interop Assembly to support a MS Word plug-in, I would want to check for both:
- Office 2007 was installed
- Office 2007 Word was installed
- Office 2007 Primary Interop Assembly was not installed
Prereq “Files to Include”
The next tab is the “Files to Include”, which allows us to lock down the files that are to be installed.
Here, I include both the EXE and its associated Setup.ISS file – which is critical to run silently.
Note that the files are hard-coded! You must change it depending on where you stashed the EXE/ISS files.
To be honest I did not evaluate whether It was possible to use a InstallShield path reference, such as <ISProductFolder> – but under the time constraints I did not evaluate that. I remember that IS 12 finally allows a path reference for storing the setup after a build – quite a few releases after incorporating that technique.
Now the nice thing about the unique GUID Identifier we saw in the first panel, is that it segregates the files for this Prereq from other Prereq’s that are with the project. In this situation, the ISS file is a silent parameter file used to provide dialog sequence for the InstallScript MSI Sage project. Each Prereq that we will create (v13, v14 and v15) will have a similar named “Setup.ISS” – so we don’t have to worry about clashing the files.
Prereq “Application to Run”
The next tab “Application to run” allows me to point to the EXE with the simple “/s” parm to run it silently.
A simple drop down menu allows you to set the correct file amongst the files you included.
Prereq “Behavior”
The next tab “Behavior” offers some basic criteria on what to do if it requires reboot.
The available selections are geared towards supporting the “Chained MSI’s” capable with Windows Installer 4.5. Since I know the Sage DO does not require a reboot, I was not worried about which I put here.
Prereq “Dependencies”
The final tab “Dependencies” allows you to have one run before the other.
In our case, we want this Prereq to run AFTER the “Sage Data Object v14.prq” – which itself will run after “Sage Data Object v13”! – Ok, we haven’t built those yet – so save this one, go build the other two and return to this panel to set the execution order!
Final Edits
Now that the setup prerequisites have been created, we need to go back and make some final edits to them.
Within the InstallShield project, you should be able to see your new prerequites listed in the Redistributables/Setup Prerequisites panel:
1) Select the checkbox on each one to inject it into the project.
2) Right-click each one and select properties. Ensure each is set to “Extract from the Setup.exe”
3) Right-click and verify “set prerequisite order” – as shown here.
Now, to my initial confusion, this panel seems to duplicate the Prereq “dependencies” we used earlier, that panel dealt only with sequencing the prerequisites – this one deals with the other non-related prerequisites.
Make the Sage objects come after the .NET setup’s, and before the SQL Server (Not really important re: SQL Server since that one runs after the dialogs are selcted.) Ensure that v14 follows v13 and v15 is the final one!
Final item – go to the Releases panel and ensure that the element for your release media (7.00.0001/Release in the example) has “InstallShield Prerequisites Location” value set to either “Extract from Setup.exe” or “Follow individual selections”.
Otherwise, you will lose your religion trying to determine why the Sage EXE file are written to sub-dir under the Setup.exe file! :->}
