Chapter 9: Dependencies
There are countless software creation tools available to developers today, a number rivaled only by the amount of software dependencies that exist. Whether it's the Visual Basic runtime files, or a complex, proprietary set of database libraries, software created to use various technologies will not function without them, and are thus dependant on these technologies.
Enter Setup Factory's dependency modules. These self-contained wonders of programming science seamlessly integrate with Setup Factory, allowing any developer to ensure that their end users have the required dependencies. If they don't, Setup Factory's dependency modules will make sure the technologies are installed before the setup is allowed to continue.
In this chapter, you'll learn about:
• Dependency modules
• Why you should always read the dependency module information
• Detection scripts and installation scripts
• Special early-extracted dependency files
Many applications created with development tools such as Visual Basic require certain technologies to be present on the system in order for the application to run. These technologies are usually files that must be installed alongside the application in order for the application to function. Dependencies range in scope from including small runtime files to requiring the presence of a properly configured local database server. Basically, anything outside of your actual application that your application depends on is a dependency.
Note: Dependencies as they relate to Setup Factory are sometimes referred to as runtime modules.
Setup Factory was built with application dependencies in mind, and includes support for dependency detection and installation in the form of dependency modules. Dependency modules are self-contained modules for installing technologies needed by the main application being installed. They consist of a script that detects whether the technology is already installed, and a script (and optional files) that will install the technology if it isn't already installed or needs to be updated. This detection and installation occurs at the beginning of the installation process, before the installation of the main product takes place.
Adding a dependency module to your installer is as easy as clicking your left mouse button five times. First, choose Resources > Dependencies (that's 2 clicks). Now, click on Add. Lastly, click the dependency module you want to add, and click OK. You have just added a dependency module to your setup, which will be installed before your actual application files are.
Note: When adding dependency modules you should keep in mind the platform(s) you intend to distribute to (32-bit or 64-bit) and the target operating system(s) (e.g. 64-bit setups will not run on 32-bit operating systems). There may be different versions available that are specific for these targets.
Removing a dependency module is even easier than adding one! Instead of five left clicks, this task requires only four. First, choose Resources > Dependencies, as you did to add the module you now wish to remove. Second, click on the dependency module to be eliminated, and click Remove. Yes, it's that easy!
Note: Because Setup Factory's dependency modules are self-contained, they can be added and removed as described. There are no files to worry about, nor actions to create. Simply point, choose, and click.
While most dependencies are completely standalone, some dependencies may have dependencies of their own, and will not function unless another dependency is already installed. If this is the case, you will want to adjust the order of the dependency modules within your Setup Factory project to ensure that the modules are installed in the correct order. In other words, if dependency A requires dependency B, you will want to make sure that Setup Factory checks for dependency B first.
Tip: Dependency modules are detected and installed in the order they are listed in on the Dependencies tab of the Resources dialog. You can adjust this order by selecting a dependency module in the list and clicking the Up or Down button to move it up or down.
A plethora of dependency modules come with Setup Factory, but if you require a dependency that was not included with Setup Factory, give the More Modules button a try. Clicking the More Modules button will open the Indigo Rose website in your default browser and take you directly to the Setup Factory dependency module page. As more dependency modules are developed, they will be posted there.
Note: It is possible to create your own dependency modules, too. To start a new module, click the Advanced button and choose Create New Module. Name the new module accordingly, and edit its properties to configure the scripts and files that the module will use to detect and install the technology.
Once you have added a dependency module to your project, you can view and change its settings through the Dependency Module Properties dialog. You can get to this dialog by selecting a module in your project and clicking the Edit button, or by double-clicking on a dependency module within your project.
The Dependency Module Properties dialog has five tabs:
The Information tab contains information about the current dependency module and often contains important instructions that you need to follow in order for the module to function as expected. If there are any related articles and documents that you should review they will be referenced here as well.
Note: Some dependency modules make use of files or settings that you must acquire or configure in order for the module to work. Be sure to read all of the information on this tab whenever you add a dependency module to your project!
The Detection tab is home to the detection script. This script is written in Lua, and is designed to determine whether the required technology already exists on the user's system. Only if the technology does not exist (or is determined to be an older version that should be updated) will the installation of the dependency continue.
The detection script must include at least one function that will be called by the installer. This detection function will determine what version (if any) of the required technology is installed, and return either true or false: true if the technology is "detected" (i.e. it is already installed and of a sufficient version) and false if the technology is "not detected" (it is either too old or missing altogether).
You can specify which function will be used by typing its name into the edit field at the top of the Detection tab. Some detection scripts may come with multiple versions of a detection function that you can choose from in this way, for instance to perform the detection using alternate methods.
Tip: You can have more than one function in the detection script. This is useful if, for example, you wanted to run different scripts based on a certain condition, such as the user’s operating system. In this case, you would create one function that is called by the installer, which would then decide which specific dependency function to run.
The value that the detection function returns is what determines whether the dependency module's installation script is performed. The installation script will only be performed if the detection function returns false, indicating that the required technology was not detected. If the function returns true, the installer will proceed to the next dependency module in the list and run its dependency script.
Detection Happens Early
The detection script is run at the beginning of the installation, before the actual installation of your product takes place. At this stage of the installation, the only files that are available to the installer are the files that already exist on the user's system, any external files that were distributed alongside the setup, and any files that were included as primer files (which get extracted at the very beginning of the installation). None of the files that are in the Archive file list are available yet, since they are still packed inside the setup archive waiting to be installed.
When modifying or creating a detection script, it’s important to remember what files will be available at that stage of the installation.
The Installation tab contains the script that will be executed if (and only if) the detection function returns false—in other words, if the detection script determines that the required technology is not installed on the user's system.
If the detection script is the brains of the operation, the installation script is the brawn. Once given the green light by the detection script, the installation script charges ahead, performing all the tasks that are required in order to get the missing technology installed on the user's system.
Often this will consist of simply launching another self-packaged installer that will handle the installation of the dependency files. Of course, you can also use any of Setup Factory's built-in actions to perform whatever tasks you choose.
Like the detection script, when the dependency module's installation script runs, it runs at the beginning of the installation, before the actual installation of your product takes place…long before any of the files in the Archive file list are installed. For this reason, most dependency modules are designed to include their own "dependency files" that will be extracted before the installation script is run. These dependency files are listed on the Files tab of the Dependency Module Properties dialog.
The Files tab contains a list of files that are required by the installation script. These files will be extracted if (and only if) the detection script determines that the required technology is not installed. This essentially allows the dependency module to bring its own files along for installation script to use.
The files listed on the Files tab typically consist of a setup executable that will install the required technology and any additional files needed by the installation script.
Note: If the detection script determines that the technology is already installed on the user's system, the files listed on the Files tab will not be extracted.
Files on the Files tab are extracted to the user's temp folder in a uniquely named subfolder. This is a subfolder within the installer's own unique folder in the user's temp folder. (Each installer creates a uniquely-named subfolder in the user's temp folder if it needs a place to extract temporary files. This is done to avoid overwriting existing files that the user may have stored in the temp folder, or that might have been left behind by a previous installation.)
For example, if the unique run-time folder name was vb6sp6, the path that the files would be extracted to would be something similar to:
Constants in Dependency File Paths
The paths in the list of dependency files often contain constants like #SUFDIR#. #SUFDIR# is a built-in constant that gets replaced at build time with the path to the Setup Factory program folder on your development system—i.e., where the Setup Factory design environment is running from. This allows the built-in dependency modules to reference files that are located in the Setup Factory application folder, without knowing the exact location that you chose to install Setup Factory to.
The Build tab contains the build configurations you want the dependency module to be a part of. You can check or uncheck the boxes in the build configurations tree to include or exclude it from the distribution. For further information about build configurations, see Chapter 11: Building and Distributing.
Note: When adding dependency modules you should keep in mind the platform(s) you intend to distribute to (32-bit or 64-bit) and the target operating system(s) (e.g. 64-bit setups will not run on 32-bit operating systems). There may be different versions available that are specific for these targets. Build configurations may assist in some of these cases.