On the Project page, you can specify general information about the application your setup package will install.
The information in the top part of the Project page will be shown to the user when the installation program is executed. Filling out these fields is the first thing you should do when creating a new DeployMaster package. When you have specified the name of your company and the name of the application, you will see that several other fields automatically receive a value (which you can, of course, change if you want to).
Company: The name of the company that produced the application or the brand name it is sold under. Type in your own name if this is not a company project. Leaving this field blank is permitted, but not recommended.
Company URL: URL of the web site of the company or brand specified earlier. If a URL is specified, the company name shown in the setup program will become clickable. If clicked, the user’s default browser will be launched to visit the company web site.
Application name: The full name of the application the setup package will install. If you are not packaging an application but a collection of documents, enter a general title for these documents. Naming your project is mandatory. Each project must have a unique name. This name is what DeployMaster uses to determine whether the application that is about to be installed is already installed or not. If a previous install with the same application name already exists, DeployMaster will replace that installation with the new install. If you want two (major) versions of your product to co-exist side by side, you have to change the application name between releases, e.g. by indicating the (major) version number.
Application URL: Should point to the web page containing more information about this specific product. If specified, the application name will become clickable.
Application version number: Version number of the application, usually something in the form of 1.0.0. Leave blank if you do not use a meaningful version numbering scheme. The version number is displayed to the user, but is not used by the setup application itself. You can type in anything you like and that your users will understand. On the Appearance and Media pages, you can use the %VERSION% and %VERSION09% placeholders to display the version number or to include it in the file name of your installer. The section explaining the Media page has more details.
Application release date: It is very important to specify an accurate release date. It should increase whenever the version number increases, and be identical when the version number is identical. The setup program uses this information to find out—in case another copy of the application has already been installed—whether the user is trying to install the same, an older or a newer version. On the Appearance and Media pages, you can use the %DATEN%, %DATE09%, and %YYYYMMDD% placeholders to display the release date or to include it in the file name of your installer. The section explaining the Media page has more details.
If you tick the Today checkbox then DeployMaster automatically sets the release date to today’s date whenever you build your installer. When today’s date is in a different year than the previous release date and the copyright string contains the year number of the old release date then that number is replaced with the number of the present year.
Icon: Icon that identifies the installer. The generated setup.exe will be identified by this icon when it is listed in Windows Explorer or other file managers. You can only supply an .ico file. If you want to use the icon of another .exe file or one stored in a .dll, you’ll need to use a resource manager or icon editor to extract the icon into an .ico file first. If you don’t supply an icon, the installer will use DeployMaster’s icon. Using DeployMaster’s icon is perfectly fine. It identifiers your setup.exe as a user-friendly installer.
Then you can specify which file should be used as the Readme document. This document should contain any information that might be useful for the user before he installs the application. It should also contain a quick overview of what the setup package will actually install, so the user can make a good decision whether he wants to go through with the installation or not. Click on the Readme button to locate the appropriate file with an open file common dialog.
If you have specified a readme file, the setup program will present a button to the user labeled “More Information”. When clicked, the document will be extracted from the compressed setup archive into a temporary folder and displayed. It is recommended to specify a .txt or .rtf file. These files are displayed inside the installation program. If you specify another type of file, the file will be shown to the user by extracting it into a temporary folder and running the default program to open it. If you know your users’ computers support them, you can use .html, .chm or .pdf files. Using a .txt or .rtf file has the advantage that you can be 100% sure the user will be able to properly read the readme file. The other file types, certainly PDF, allow you to create a much nicer readme document to further improve the first impression.
Also, DeployMaster offers to show the readme file before the installation process starts, and not when it is finished, at which point installation tips and system requirements are no longer of any use. You will probably also want to add the readme file to the application’s main component on the Files page, so the user can read it again later.
The license agreement, on the other hand, must be a plain text or a .rtf file. This is because it will be shown inside the DeployMaster installer, so the user cannot bypass it. As not to bloat the installer, only plain text files and basic .rtf files are supported. Basic means whatever you can create in the WordPad applet that comes with Windows. The WordPad viewer (the RichEdit common control) is embedded in Windows and can be easily accessed by applications such as DeployMaster. The license agreement is shown when the user clicks the Install button. When the user clicks Yes to accept the agreement, the installation will continue. If the user clicks No, the installation will be aborted.
You will probably also want to add the license agreement file to the application’s main component on the Files page, so the user can read it again later. Not specifying any license agreement is perfectly okay for DeployMaster, though your lawyer may have a different opinion.
If you add a license agreement, you can tick “skip the license agreement when the application is already installed” to show the license agreement only the first time your is installed. The license agreement won’t be shown when the same application is installed again (regardless of whether it is the same or a different version of that application). If you don’t tick this checkbox, then the license agreement is shown before every installation.
Providing a Support DLL is optional. You can use a support DLL to add functionality to your installer that DeployMaster does not provide. The sample Support DLL source code includes comments that explain what you can do with a Support DLL.
DeployMaster can generate installers that install for all users, install for the current user, or give the user the choice of either type of installation. Current user installs can be done with or without admin rights. Installing for all users is the most common way to install software. But that requires administrator rights. Offering the option to install for the current user without admin rights allows the software to be installed by people who don’t have admin rights on their company PC.
Which of the two options you should choose or whether you can choose both depends on the installation requirements that your application has. Installing into protected folders like c:\Program Files or creating registry keys under HKEY_LOCAL_MACHINE requires admin rights. Placing data files into a user-specific folder such as “My Documents” or creating registry keys under HKEY_CURRENT_USER makes the installation specific to a user. If you want to support both types of installations, then your application will need to be adaptable to different installation folders (see below) and different registry branches (as explained for the Registry page).
If you do enable both types of installations, the user will be able to make their choice via the Advanced Installation button the first time they install your application. If they instead click the Immediate Installation or the Custom Installation button, then the installer chooses automatically. If the user has admin rights or is using an account that can be elevated to admin rights then the installation is done for all users. If your installer requires admin rights for a per-user install then the automatic choice is also to install for all users. So a per-user install without admin rights is only done automatically if the user does not have admin rights and their account does not support elevation. Basically, the installer will take full advantage of admin rights when they are available or when they are always required by your installer. It falls back to a user-specific install only to avoid a black screen security prompt for which the user may not have the password when their own Windows account cannot be used to pass this prompt.
Your installer can have two sets of default installation folders. The left hand set is used for installations for all users. The right hand set is used for installations for the current user. The user can change the actual installation folders via the Advanced Installation button. If you don’t put files in any of these folders on the Files page then you should leave the default for that folder blank so that the user won’t be prompted to select an unused folder during an advanced installation.
See the standard folder names topic for more information about the placeholders used in the default installation folders. You can add values on the Registry page if your application needs to determine the actual installation folders.
Default Application Folder is the folder that will be represented by %APPFOLDER% in the Files tab. This is the main installation folder where you place your application’s executable and related non-data files. This is normally a subfolder of %PROGRAMFILES% for all-user installs and a subfolder of %LOCALAPPDATAROOT% for user-specific installs.
Default Common Files Folder is the default for %APPCOMMONFOLDER%. This folder can be used to install DLLs and other files that are shared between your applications. Sharing such files can save disk space but can also lead to versioning conflicts. This is normally a subfolder of %COMMONFILES% for all-user installs and a subfolder of %LOCALAPPDATAROOT% for user-specific installs.
Default Start Menu Folder is the default for %APPMENU%. This is where you put the shortcuts that you want to appear in the Start menu. It should be set to %PROGRAMSMENU% or a subfolder thereof for both all-user and user-specific installs.
Default User Data Folder is the default for %USERDATA%. This is where you put data files and settings files that the user may want to modify while using your application. This should be a subfolder of %COMMONAPPDATAROOT% or %COMMONDOCUMENTS% for all-user installs. Make it a subfolder of %APPDATAROOT% or %MYDOCUMENTS% for user-specific installs. The AppData folder is more appropriate for files like configuration files that the user doesn’t deal with directly. The documents folder is more appropriate for files that store the user’s work or results.