You should also 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 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.
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.
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. 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.
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 common 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. This name is also the name that appears on security prompts when the user runs your installer.
Authenticode certificates are normally stored in files with a .pfx 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. Note that 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.
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.
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 users without administrator privileges to make portable installs, 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 to install the software onto the hard disk. 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.
DeployMaster automatically uses Verisign's time stamping service to countersign all digital signatures, even when using a code signing certificate from another provider. This ensures the signatures won't expire when your code signing certificate expires. Because of this, a working Internet connection is required for code signing to succeed.