You should specify a meaningful name for your package, certainly if you are going to offer it for download. It is very hard for the user to find out which of the half a dozen setup.exe files she downloaded will install your application. Trying each of them is a waste of time. The best name you can choose is Setup_AppName_Version.exe. This makes it immediately clear that the file is an installation program and not a regular application, and which application and which version of it will be installed. Only if the package will be burned on CD-ROM, the ordinary setup.exe will do. Then the user can look at the disc's label to find out which application it is about.
If you added external installers on the 3rd Party tab or turned on the .NET framework requirement, you can specify two names for the final setup.exe. The first one will contain just your files and settings, including the 3rd party settings, but not the actual 3rd party installers. Your setup.exe will look for the 3rd party installers in the same folder where you or the user placed the setup.exe. If they are missing, the download URLs are displayed instead. The second setup.exe will have all the 3rd party executables integrated into it. The setup.exe will still look for external installers in the same folder, and run those if present. If they're missing, the integrated installer is extracted from the setup.exe into a temporary folder, and run them from there.
When distributing your application with 3rd party requirements as a download, you should build both the setup with and without the 3rd party installers. People who download your software for the first time can use the integrated download. People who are upgrading can use the "lite" download. Since the lite download still does the 3rd party checks, there's no big problem if first time users don't download the big package. When distributing your application on CD, you should use the installer without integrated 3rd party installers. Instead, place the installers separately on the CD along with your own setup.exe. That eliminates the step of extracting the integrated installer into a temporary folder.
If your setup doesn't reference any 3rd party packages, then it doesn't matter whether you specify the name of your setup in the first or second box. Only one setup.exe will be generated.
To create a CD-ROM that will automatically launch the installer when the user inserts the CD into the drive, turn on the option to create the autorun.inf file. Place this file together with the setup.exe in the root folder of the CD. There are no other requirements to make this work.
You can use several placeholders to insert the version number of the installer and the application's release date in the file name of the generated installer and in its output folder. The output folder will be created if it does not yet exist when you build your setup.
%VERSION% inserts the Application Version exactly as you specified it on the Project page. %VERSION09% inserts the Application Version stripped of all characters that are not digits. If the Application Version is "1.2.3 BETA" and you specify "SetupMyApp%VERSION%.exe" as the file name for the installer, then the final name of the installer will be "SetupMyApp1.2.3 BETA.exe". If you specify "SetupMyApp%VERSION09%.exe", then the final name will be "SetupMyApp123.exe".
%DATE% inserts the release date specified on the Project page, formatted using the short date format specified in the regional settings in the Windows Control Panel on your development PC. If that date format includes slashes, those will be removed, as they are not valid in file names. Other characters such as hyphens or spaces will be preserved. If your computer's default date format produces something like 18/Sep/2012 then "SetupMyApp%DATE%.exe" becomes "SetupMyApp18Sep2012.exe".
%DATE09% also inserts the release date using the date format specified in the Control Panel. If that date format uses (abbreviated) month names, DeployMaster uses month numbers instead. All characters that are not digits are stripped from the date. If the default date format produces something like 18/Sep/2012 then "SetupMyApp%DATE09%.exe" becomes "SetupMyApp18092012.exe".
%YYYYMMDD% inserts the release date in YYYYMMDD format. The benefit is that "SetupMyApp%YYYYMMDD%.exe" will always yield something like "SetupMyApp20120918.exe", which allows your installers to be displayed in the proper order when a file manager sorts them alphabetically by file name.
You can use multiple placeholders at the same time. "Setup MyApp %YYYYMMDD% %VERSION%.exe" will produce "Setup MyApp 20120918 1.2.3 BETA.exe". This is a very descriptive name for your installer. Multiple versions will be in the proper order when sorted alphabetically.
By default, DeployMaster automatically compresses all files that it puts into your setup.exe. DeployMaster uses the LZMA algorithm which achieves high compression ratios thus producing smaller setups that can be downloaded faster. But the LZMA algorithm is quite slow when compressing. While testing your installer on your own PC or local network, you can set "compression method" to "none" to significantly increase the speed at which DeployMaster builds your installers. When building the installer you will deliver to your customers via the Internet, set "compression method" to "best" to significantly reduce the size of the generated installer. If you work in an environment where the size of the generated installer does not matter much, you can choose the "average", "faster", or "minimal" compression methods to increase the build speed at the cost of a larger generated installer. The speed at which the installer decompresses the files does not change noticeably with increased compression.
If your installer includes files such as video files, music files, or image files that already use compressed file formats, you can add their file masks to the list of files that should not be compressed, e.g.: *.avi;*.mkv;*.mp?;*.jpg;*.png;*.gif. Then DeployMaster will add those files to your setup.exe without attempting to compress them. If your installer includes many such files, this will significantly increase the speed at which your installer is built if "compression method" is set to anything but "none". As long as all the file masks only match incompressible files, then the size of the generated installer will remain the same.
DeployMaster can create installers of any size and allows you to add files of any size. Files and installers larger than 4 GB are no problem for DeployMaster. But Windows itself does not support .exe files larger than 4 GB. Some file systems, such as FAT32, also do not support files larger than 4 GB. If your installer is larger than 4 GB, DeployMaster will automatically split it into multiple parts of 4095 MB. The first part will be the self-extracting executable with the name you've specified. The other parts will have the same name with numbered extensions, e.g. setup.001, setup.002, etc.
You can specify a smaller size than 4095 MB. The minimum split size is 3 MB. If you want to distribute your software on CD-ROM, set it to 650 MB so each part of your setup will fit onto a CD.
You can also specify which folder the build package should be placed in. This should be a hard drive folder, so that there is enough free room for the entire installation package. Even if you select to split the setup into pieces, the whole package must fit on the drive while building. If there is not enough free space, the build will fail.
Recent versions of Windows, Internet Explorer, and other web browsers display warnings and security prompts when the user tries to run software downloaded from the internet. These warnings are more severe for applications that are not digitally signed. Anti-virus and anti-malware tools also check digital signatures as part of their checks. Digitally signing your installer and your actual software is strongly recommended.
In order to digitally sign your installer, you need an Authenticode certificate. Authenticode is the specific name for code signing certificates for Microsoft Windows. You can purchase such a certificate from Verisign, Thawte, GlobalSign, Comodo, or GoDaddy. The only difference between these providers is how much it'll cost and how many hoops you'll have to jump through to prove your identity, which may differ depending on which country you're in. Symantec owns Verisign which owns Thawte. GlobalSign is based in Europe, while the others are in the US. GoDaddy's validation process is more automated, but only available in certain countries.
Type in the Subject name of the code signing certificate to tell DeployMaster which code signing certificate it should use. You must type in the name exactly as it is on the certificate, including any punctuation. When you check the details on your certificate, Windows indicates this name in the "Issued To" or "Subject" field. This is also the name that appears on security prompts when the user runs your installer.
Authenticode certificates are normally stored in PKCS#12 files with a .pfx or .p12 extension. If you double-click such a file in Windows Explorer, Windows will store the certificate in the registry on your PC. If you have done that, then you don't need to specify the .pfx file. DeployMaster will automatically load the correct certificate from the registry based on its name. If the certificate is not in the registry, specify the full path to the .pfx file. Even when specifying a .pfx file you still need to specify the common name of your code signing certificate.
If your .pfx file is protected with a password, DeployMaster will prompt for the password when needed. DeployMaster keeps the password in memory as it is needed several times while building an installer. You will be prompted only once for the password when building multiple installers in a single DeployMaster session using the same certificate. DeployMaster does not provide an option to store the password. There is no way to do that securely. If you want to automate the build process without a password prompt, double-click your .pfx file in Windows Explorer. Follow the wizard to import your certificate into the Windows registry. Do not turn on the option to enable strong private key protection so that no password will be required to use the certificate. Remove the reference to the PFX file in DeployMaster.
You cannot use certificates stored in PKCS#7 files with a .p7b extension. The PKCS#7 format does not include the private key, which is necessary for code signing.
Normally, when you purchase a code signing certificate, the certificate is automatically installed on the computer that you used to make the purchase. To back up this certificate or transfer it to another computer, export the certificate including the private key. In Internet Explorer you can do this by going into Internet Options, Content tab, Certificates button, Export button. In the wizard, choose to export the private key. Then choose PKCS #12 (PFX) format and tick "include all certificates in the certification path if possible". Then you will get a PFX file that includes everything that is needed for code signing.
You should sign both your setup.exe and all .exe files that it installs. If you tick also sign unsigned .exe files added to the setup, then DeployMaster will sign all .exe files that haven't been signed yet while building your setup. DeployMaster only checks whether the .exe files were signed at all. It will not replace the signature on .exe files that were signed with another certificate than the one you're using.
DeployMaster automatically uses a time stamping service to countersign your digital signature. This ensures that the signature remains valid even after the code signing certificate expires. Because of this, a working Internet connection is required for code signing to succeed. You can select any of the time stamping URLs from the drop-down list. The provider of the time stamping service does not need to be the issuer of your code signing certificate. Occasionally these time stamping services go down for maintenance or are unreachable because of network outages. When that happens, select a different URL and build your installer again. DeployMaster remembers the time stamping URL as a global setting. It is not stored in your .deploy file. This way you only need to change the time stamping URL once if your previous choice becomes unavailable.
To properly sign a setup.exe built by DeployMaster, you have to let DeployMaster do the signing while building the setup. While you could sign the setup.exe afterwards, that is not sufficient. If you sign the setup.exe afterwards, you'll only sign the installer stub. You can't sign the actual installer(s) stored inside the setup.exe after it has been built. For a combined 32-bit and 64-bit setup.exe, there will be two actual installers inside the setup.exe. The setup.exe extracts the actual installer into the temp folder and runs that to perform the installation. In order to allow user-specific installs and portable installs by non-administrators, the setup.exe does not request administrator privileges when the user runs it. The actual installer will request administrator privileges when the user clicks one of the buttons create an installation for all users. This means that Windows will check the digital signature on the actual installer that was extracted into the temp folder rather than the signature on the setup.exe. Thus, if you don't let DeployMaster sign your setup, Windows will indicate your installer is unsigned, even if you manually signed your setup.exe after DeployMaster built it.