Don’t let the long lists of issues on this page make you think our products have a lot of problems. Quite to the contrary. All the bugs listed below are bugs that we have fixed. Many of these are corner cases reported by only one or perhaps a handful of our customers. Other software companies often don’t spend any effort addressing such issues, much less list them publicly. We take pride in producing high quality software, and often release free updates to ensure you won’t have any problems with our software.
Your purchase also comes with one year of free major upgrades. So don’t worry if there might be a new major upgrade around the corner just because it’s been a while since the last major upgrade. If there is one around the corner, you’ll get it free, without having to ask. (But you can keep the old version if you prefer.)
If you ever hit a snag with DeployMaster, check here whether you have the latest version. If you do, simply report the issue on the forum and we’ll help you out as soon as we can.
This release adds support for Windows 11 version 24H2 otherwise known as the 2024 Update. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 11 versions.
This release also brings significant improvements to DeployMaster to find and use code signing certificates to apply a digital signature to your installer. In most cases you now only need to tick the sign the installer checkbox on the Media page. You no longer need to specify a subject name, PFX file, or command line. If you don’t then DeployMaster automatically picks a non-expired code signing certificate from your computer’s certificate store. This works with certificates stored on USB tokens and in the cloud too as long as you have unlocked the token or are logged onto the cloud service. Instructions you received for using the certificate with signtool.exe will also work with DeployMaster, without needing to download or run signtool.exe.
You can still specify the subject name of the certificate to select between multiple certificates with different names, or simply to ensure that the correct certificate is used. If there are multiple certificates with the same name then DeployMaster now picks the first one that is already valid and not yet expired. So you can leave old certificates installed and install new certificates before they become valid. If they have the same subject name then DeployMaster will automatically switch between the certificates when one expires and another becomes valid.
If you want DeployMaster to use a specific certificate then you can now specify the certificate’s thumbprint instead of its subject name. The thumbprint is a sequence of 40 hexadecimal digits that uniquely identifies each certificate. A renewed or reissued certificate will have a different thumbprint. If you have multiple certificates with the same name with overlapping validity periods then you can specify the thumbprint to sign with a specific certificate.
DeployMaster 7.1.0 through 7.3.0 allowed you to specify the full path to signtool.exe in case DeployMaster’s built-in code signing was unable find the certificate on your USB token. This functionality remains. You can still specify the full path to signtool.exe without any parameters as the custom command line for code signing. DeployMaster 7.4.0 will then run signtool.exe and provide the parameters it needs like DeployMaster 7.1.0 through 7.3.0 did. But this should no longer be necessary. If you make the custom command line for code signing empty then DeployMaster 7.4.0’s built-in code signing should be able to automatically find the certificate on your USB token just as well as signtool does, even if signtool is not installed.
If you have a code signing certificate that can’t be used by signtool.exe then DeployMaster’s built-in code signing won’t be able to use it either. For those situations you will need to continue using a custom command line for code signing with %FILE% and other placeholders as introduced in DeployMaster 7.3.0.
One bug was fixed. When building from the command line you can specify the \q parameter to run DeployMaster silently and the \l parameter to write the log that would appear on the Build tab into a file. The log is now written correctly when you specify both these parameters. Previously, only the first line was written to the file.
See also: DeployMaster 7.4.0 version history
This release adds support for Windows 11 version 23H2 otherwise known as the 2023 Update. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 11 versions.
DeployMaster 7.1.0 added the option to specify the full path to signtool.exe on the Media page to have DeployMaster run signtool.exe to sign the installer. We added this because DeployMaster’s built-in code signing (which calls the code singing functions in the Windows API) is unable to find Extended Validation (EV) code signing certificates stored on certain USB tokens such as the SafeNet USB token. But DeployMaster’s built-in code signing does work with EV certificates stored on certain other USB tokens such as the Sectigo eToken. We’ve updated the documentation to explain that to sign with an EV certificate stored on a USB token, you can first try to specify only the subject name of the certificate on the Media page. If that works it’ll save you the hassle of installing the Windows SDK just to get signtool.exe.
Version 7.3.0 now allows you to use a code signing application other than signtool.exe. To do so, specify a full command line (full path to the .exe plus command line parameters) to run that code signing application instead of the path to signtool.exe. You have to use the placeholder %FILE% on the command line to represent the file to be signed. DeployMaster checks whether you added %FILE% to the command line to distinguish between a full path to signtool.exe and a full command line to another code signing application. If you omit %FILE% then DeployMaster assumes the path points to signtool.exe and adds the command line parameters that signtool.exe expects. When you add %FILE% to the command line DeployMaster does not add any command line parameters. It only replaced the %FILE% placeholder plus six optional placeholders. %DESCRIPTION% represents the name and version number of the application specified on the Project page. %URL% is the application URL specified on the Project page. %SUBJECT% is the subject name of the code signing certificate specified on the Media page. %PFX% is the path to the PFX file specified on the Media page. %TSURL% is the time stamping service URL selected on the Media page. %PWD% tells DeployMaster to ask for a password. It will do so the first time it needs to run a specific command line to sign a file. DeployMaster will remember the password until it needs to sign with a different command line.
The list of time stamping service URLs on the Media page has been updated and expanded. The services higher in the list were faster and/or more reliable in our tests that those lower in the list. Your experience may vary depending on your location and the time of day you build your installers. DeployMaster remembers the time stamping URL that you select as a global preference. If you select a new URL then that is used for all future builds until you change it again.
See also: DeployMaster 7.3.0 version history
On the Platform page you can now select a specific range of Windows 11 updates that your installer is compatible with. Presently the options are “21H2 (Original Release)“, “22H2 (2022 Update)“, and “all future updates“. The default range is from “original release” to “all future updates” which makes your installer run on Windows 11 without checking the specific Windows 11 version the user has. If your application depends on new features made available in a Windows 11 update then you can set that update as the minimum version. If you make an older version of your application available for users who haven’t updated their Windows 11 (yet) then you can restrict your installer to older builds of Windows 11 so that people who did update their Windows 11 don’t accidentally install the older version.
In addition, you can still select the specific range of Windows 10 updates that your installer is compatible with, independently of the Windows 11 setting. So you can make a single installer that will run on Windows 10 and Windows 11 but requires specific updates for Windows 10 and/or Windows 11. “22H2 (2022 Update)” is now also an option for Windows 10. Microsoft has given the latest updates for Windows 10 and 11 the same label. But DeployMaster is aware that the internal build numbers are different and correctly checks those. So you could choose to support Windows 11 22H2 but not Windows 10 22H2, for example.
DeployMaster itself uses the Windows 10 and 11 version restrictions when you use the options on the 3rd party page to make your application require a specific version of the (classic) .NET Framework. .NET 4.6 and later require specific updates to work on Windows 10. .NET 4.8.1 is now also supported.
DeployMaster itself now includes the following additional languages that you can select as such on the Language page: “Français“, “Português-BR“, “Deutsch“, and “Español“. If you had previously added a language with exactly one of these names then DeployMaster’s installer will not overwrite your custom translation. The new language files are also available in the DeployMaster Language Pack which you can download separately from DeployMaster’s web site. You can use the latest language pack with DeployMaster 6.x.x and 7.x.x.
See also: DeployMaster 7.2.0 version history
An installer built with DeployMaster contains a number of core files that the installer needs to be able to show itself, before the actual installation begins. This includes the installation program itself plus the files that you specify on the Project and Appearance pages. On the Project page you can add an icon, readme file, license agreement, and support DLLs. On the Appearance page you can specify a background bitmap. The total allowed size of these files has been increased from 3 MB to 10 MB. This gives you space for larger images or DLLs. If you chose a compression method on the Media page, then it’s the total size after compression that matters.
As a consequence, on the Media page, the option to split the setup files into multiple files of a certain size now has 10 MB as the minimum split limit. This ensures that the first piece of the installer contains all the core files. These days 10 MB is a small download. So a 10 MB minimum size should still be below any file size limitations of any file transfer sites that you may want to use to send your installer to your users.
Windows 11 has been added as an option on the Platform page. This lets you indicate whether your installer should allow your application to be installed on Windows 11. If you restrict your installer to specific Windows 10 versions you can now select Windows 10 version 21H1 otherwise known as the May 2021 Update.
Installers built with previous versions of DeployMaster detect Windows 11 as well as Windows 10 21H1 as if they were Windows 10 2009. 2009 is the release number of the October 2020 Update (20H2). Windows 10 21H1 and Windows 11 also use this release number. If you built your installer with DeployMaster 7.0.0 or prior allowing installation on Windows 10 20H2 or on “all future updates” of Windows 10 then your installer will allow installation on Windows 10 21H1 and on Windows 11.
Installers built with DeployMaster 7.1.0 correctly distinguish between Windows 10 20H2, Windows 10 21H1, and Windows 11.
If you have an EV code signing certificate stored on a USB token then you can now have DeployMaster sign your installers by specifying the full path to signtool.exe on the Media page. Signtool is included with the Windows 10 SDK which is a free download from Microsoft and is also included with development tools such as Visual Studio. Do not specify a PFX file. You don’t need to specify the subject name of the code signing certificate unless your USB token contains more than one certificate and you want to select a specific one.
Godaddy has stopped selling code signing certificates. They have also shut down their tsa.startfieldtech.com timestamping service. This means there are no longer any time stamping services left that are compatible with Windows XP SP3 and Windows Vista. You will need to upgrade to DeployMaster 7 if you want to build an installer with a proper digital signature. DeployMaster 7 can sign installers for Windows XP SP3 and Windows Vista. But it won’t timestamp them. This means the signature will expire when the code signing certificate expires. Installers targeting Windows 7 or later will be signed and timestamped so that the signature remains valid after the certificate expires.
If you have a certificate issued by Godaddy then you can continue using that certificate until it expires. You can select any of the other timestamping URLs on the Media page.
DeployMaster 7.0.0 is a free minor update. We’ve numbered it as a major upgrade because it brings one key change. When you tell DeployMaster to digitally sign an installer targeting Windows XP or Vista, DeployMaster 7 no longer applies a time stamp to the signature. This means that the signature is only valid for as long as your code signing certificate remains valid.
The reason for this is that the SHA-1 time stamps supported by Windows XP and Vista are being phased out. This is part of a longer trend in the industry to phase out everything based on SHA-1. Applying an SHA-256 time stamp to an SHA-1 signature makes Windows XP and Vista treat the whole signature as invalid because they can’t verify the time stamp. An SHA-1 signature without a time stamp is treated as valid by Windows XP SP3 and Vista during the time period that your code signing certificate is valid for.
If you tell DeployMaster to digitally sign an installer targeting Windows 7 or later then DeployMaster 7 now requires you to build your installer on Windows 7. That is needed to apply an SHA-256 signature with an SHA-256 time stamp.
The list of time stamping service URLs on the Media page has been updated and expanded. Several providers have changed their URLs and several new ones have been added. The services higher in the list were faster and/or more reliable in our tests that those lower in the list. Your experience may vary depending on your location and the time of day you build your installers.
The Media page now has a new checkbox to sign any unsigned .dll and .ocx files that you added to your installer. This allows your users or any security software they may use to verify that your .dll and .ocx files were not tampered with. It doesn’t affect the security warnings shown by Windows.
If you are not yet ready to upgrade to DeployMaster 7 then you can continue using DeployMaster 4.2.2 through 6.6.0 by selecting tsa.startfieldtech.com as the time stamping service on the Media page. This is the last remaining service that still produces time stamps compatible with Windows XP SP3 and Windows Vista. Comodo’s URL still works but it actually applies a SHA-384 time stamp. This time stamp is only recognized by Windows 7 and later. The other URLs that you could select in previous versions of DeployMaster no longer work.
DeployMaster remembers the time stamping URL that you select as a global preference. It is not saved into the .deploy file. This way you only need to select a different URL once if your previous choice stops working. The new URL will be used for all future builds until you change it again. If your previously selected URL is one that is no longer available in DeployMaster 7 then DeployMaster automatically selects the first URL in the new list.
See also: DeployMaster 7.0.0 version history
This release adds support for Windows 10 version 20H2 otherwise known as the October 2020 Update. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions.
When the uninstaller deletes files, it also tries to delete the parent folders so as not to leave behind any empty folders. If an application was installed into the root of a virtual drive, or in an empty subfolder of a virtual drive, this caused the uninstaller to unmount the virtual drive. Now the uninstaller checks whether a folder is a reparse point. If it is, the folder is not deleted. This ensures the uninstaller does not unmount virtual drives. It also stops the uninstaller from deleting symbolic directory links.
On the Update page in DeployMaster, you can configure your installer to delete files that were installed as part of a previous version of your installer but no longer included in the current version. This also makes the installer try to folders when deleting files to avoid leaving empty folders behind. The installer too now checks whether a folder is a reparse point and won’t delete folders that are.
Windows 8.1 and Windows 10 support per-monitor DPI scaling. If you have FHD (2K) and UHD (4K) monitors of the same physical size connected to your computer, you could set the FHD monitor to 100% scaling and the UHD monitor to 200% scaling so everything appears at the same size on both monitors. The DeployMaster Builder (which you use to create your installers) now supports per-monitors scaling too. It starts on the monitor where you double-clicked DeployMaster’s icon and scales itself to that monitor. It adjusts its scaling when you drag it to another monitor with a different scaling percentage. This adjustment causes DeployMaster to flicker for a second or so. But when the adjustment is done, everything will be sized correctly and text will be perfectly crisp.
There is no change to the scaling of installers built with DeployMaster. The installer places itself in the center of the primary monitor and scales itself to the primary monitor. Text is perfectly crisp on the primary monitor. If the user drags the installer to another monitor, then the installer remains crisp if the other monitor uses the same scaling percentage as the primary monitor. If the scaling percentage is different, then Windows scales the installer to the secondary monitor. Everything will be sized correctly and all text will be readable. But the installer may appear a bit blurry while it’s on a secondary monitor with a different DPI setting.
This release adds support for Windows 10 version 2004 otherwise known as the May 2020 Update. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions.
This release adds support for Windows 10 version 1909 otherwise known as the November 2019 Update. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions.
Installers built with previous versions of DeployMaster would fail to run if the installer’s name or the name of one of its parent folders contained a character that cannot be represented in the computer’s default code page. They would claim the installer was damaged. If you deselect Windows 98 and ME on the Platform page rebuild your installer with 6.5.2 then it will correctly run from a path that contains characters not supported by the computer’s code page. If you keep Windows 98 or ME selected, then your installer will not be able to run from such paths on any version of Windows. But it will now detect this situation and ask the user to rename the installer or the folder it is in.
DeployMaster 6.0.0 introduced the ability to create installers that can install your application for the current user only without needing administrator privileges. If you allowed the user to choose between an installation for all users (which always needs admin privileges) and an installation for the current user without admin privileges, then running the installer with the /silent parameter always chose to install for all users. If it was run from a command prompt without admin privileges, the installer would trigger an elevation prompt.
DeployMaster 6.2.0 broke silent installs if the installer allowed the user to choose and the installer was run from a command prompt without admin privileges. The installer simply didn’t do anything. There was no problem when running from an elevated command prompt. Then the installer installed for all users using the admin privileges it inherited from the elevated command prompt.
DeployMaster 6.5.1 fixes this. Silent installs run from a command prompt without admin privileges now install for the current user without triggering an elevation prompt if your installer allows that option and the application was not previously installed for all users. If it was previously installed for all users, then a silent install started without admin privileges requests elevation so that it can update the installation for all users. Silent installs run from an elevated command prompt continue to install for all users using the admin privileges it inherited from the elevated command prompt.
Users can pass the /userall or the /usercurrent parameter on the command line to the installer to choose between an installation for all users or for the current user only if your installer allows that choice. These can be used with or without the /silent parameter. These parameters were introduced in DeployMaster 6.0.0.
Passing both /usercurrent and /silent works around the bug in installers built with DeployMaster 6.2.0 through 6.5.0 allowing the installer to proceed without admin privileges. Passing /userall does not make such installers request elevation. The user needs to provide that by running the command prompt as administrator.
See also: DeployMaster 6.5.1 version history
This release adds support for Windows 10 version 1903 otherwise known as the May 2019 Update. This update started rolling out to computers around the world a couple of days ago. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions. The server version, Windows Server 2019, is also supported. On the 3rd party page, you can now select to require .NET 4.8 which ships with the May 2019 Update.
The Today checkbox on the Project page now affects the copyright string too. 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.
See also: DeployMaster 6.5.0 version history
This release adds support for Windows 10 version 1809 otherwise known as the October 2018 Update. This update started rolling out to computers around the world a couple of days ago. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions. The server version, Windows Server 2019, is also supported.
DeployMaster.exe and DeployMasterCmd.exe now accept two additional command line parameters. You can use them if you specify the path to a .deploy file on the command line. With /ver you can override the application version number on the Project page. With /lang you can override the language selected on the Language page. Specify the version or language after the parameter, separated from it with a space. If the version or language includes spaces, enclose it with double quotes.
See also: DeployMaster 6.4.0 version history
Installers built with DeployMaster now run correctly on Windows Server 2012 Core, Windows Server 2012 R2 Core, and Windows Server 2016. These editions of Windows Server do not include the desktop. They have limited support for running GUI applications. But that support is sufficient to fully support installers built with DeployMaster 6.3.1 both in GUI mode and in silent mode. Installers built with previous versions of DeployMaster failed with a “class not registered” error if the Windows desktop was not available, even when run in silent mode.
With the DeployMasterCmd helper application you can integrate DeployMaster into automated build systems that rely on command line tools and standard I/O. Pass it the path to a .deploy file and the /b /q parameters to build an installer. This now works correctly on installations of Windows Server without the desktop.
The GUI of DeployMaster itself is not fully functional without the Windows desktop. Most significantly, the Open and Save dialogs do not work. You can work around this by passing the path to a .deploy file on the command line.
This release adds support for Windows 10 version 1803, otherwise known as the April 2018 Update, which will be rolling out to computers around the world this May. You can now select this version on the Platform page if you want to restrict your installer to specific Windows 10 versions. On the 3rd party page, you can now select to require .NET 4.7.2 which ships with the April 2018 Update.
Windows 10 version 1709 (Fall Creators Update) added a new feature to Windows Defender called Controlled Folder Access. DeployMaster 6.2.0 added four new options on the Platform page to allow your installers to appropriately deal with this.
The April 2018 Update retains the Controlled Folder Access feature with some changes to how it’s presented in Windows Defender. The option can now be found in a new section labeled Ransomware Protection. The wording that “most apps” would automatically be considered “friendly” and thus not be blocked has been removed. This makes it obvious that software developers will have to continue to deal with Controlled Folder Access and not expect their applications to be allowed through automatically.
DeployMaster 6.3.0 brings further refinements in how the installers it builds deal with Controlled Folder Access. The most important change is that if you enable any of the options DeployMaster offers for this on the Platform page, your installer now checks whether Windows Defender is actually operational on the user’s PC. If it is not, Controlled Folder Access can’t be active. Your installer then ignores the options for dealing with it. The most likely reason for Windows Defender being disabled is that the user has installed another anti-virus solution.
Allowing an executable through Controlled Folder Access requires the execution of a PowerShell command. At least one anti-virus tool, namely BitDefender, treats any application that invokes PowerShell for any reason as malicious. This made BitDefender kill installers built with DeployMaster 6.2.x in the middle of the installation process if they were ran on Windows 10 1709 or 1803 and they were built with the option to add installed executables to the list of applications allowed through Controlled Folder Access. Because BitDefender also disables Windows Defender, its heavy-handed approach no longer affects installers built with DeployMaster 6.3.0.
Testing whether the installer is blocked by Controlled Folder Access is now done by checking registry keys. This avoids a warning in the notification area if it is being blocked.
Adding installed executables to the list of applications allowed through Controlled Folder Access is still done regardless of whether the user turned on Controlled Folder Access. But now it’s only done if Windows Defender is operational. Your installer now also checks whether each executable is already on the list. If it is, the installer does not try to add it again. This saves a few seconds per executable.
On the Registry page, selecting a value reveals a new checkbox labeled keep existing value. If you tick this, that value is not written to the registry if a value with the same name already exists when your installer is run. In that case, the value is also not removed from the registry by the uninstaller. If you tick “keep existing value” for a “dummy” value, then that value is not removed by the uninstaller either. If you don’t tick “keep existing value” then the value is always written (if it’s not a dummy) to the registry by the installer and is always removed (dummy or not) by the uninstaller.
An Advanced Installation allows the user to change installation folders and select which file types should be created. You could add more folders (through a Support DLL) or add more file types (on the File Types page) than fit the height of the installer window. Now the installer will make itself taller when prompting for folders and file types, if needed.
Microsoft has backpedaled most of their plans to deprecate SHA-1. Code signing certificates are now indicated as “unaffected“. Back in 2015 the plan was for Windows 10 to gradually stop trusting signatures using SHA-1 digests. Windows 10 did distrust signatures based on an SHA-1 certificate for a period of time in 2016.
DeployMaster 5.0.0 and later have the ability to apply signatures using SHA-256 digests when you build your installer on Windows 7 or later. They can apply dual SHA-1 and SHA-256 signatures when you build your installer on Windows 8 or later. Windows XP and Vista do not recognize SHA-256 timestamps. DeployMaster 5.0.0 and later would also add errors to the build log if an SHA-256 signature could not be applied because you were building on an older version of Windows and requested support for Windows 10 on the Platform page.
Because Windows 10 once again accepts SHA-1 digital signatures, DeployMaster 6.3.0 no longer adds errors to the build log if it cannot apply an SHA-256 signature. It will simply fall back to a applying single SHA-1 signature. But if SHA-256 or dual signatures are possible and you are targeting Windows 7 or later with your installer, then DeployMaster will still apply them. This ensures your installer gets the strongest possible signature, which may be helpful in the future if Microsoft change their mind again.
Windows 10 version 1709 (Fall Creators Update) added a new feature to Windows Defender called Controlled Folder Access. DeployMaster 6.2.0 added four new options on the Platform page to allow your installers to appropriately deal with this. This release brings further improvements and a few fixes.
If you turn on the option to test for Controlled Folder Access as well as the option to temporarily allow the installer through Controlled Folder Access, then the installer now performs the test first. If the test succeeds, it proceeds with the installation without adding itself to the allowed applications. When the installer does add itself, it now shows a progress meter. The whole process can easily take five seconds.
Installers built with DeployMaster 4.0.0 and later can extract multiple files in parallel to speed up the installation. If multiple files could not be extracted, the installer could show multiple error messages at the same time in separate message boxes that all needed to be acknowledged. One situation when this happened is if the installer tried to install multiple files into a folder protected by Controlled Folder Access, and the installer isn’t allowed through. Installers built with DeployMaster 6.2.1 now bundle errors. The user will never get more than one message box at the same time. If multiple errors occur at the same time, those are all shown by the same message box, which requires only one click to be acknowledged. Additional messages boxes may appear later in the installation if the user chooses to continue with the installation and further errors occur. But never more than one message box at a time.
This release also fixes two bugs that only affected 64-bit installers. 32-bit installers running on 64-bit Windows were not affected. The bitness of your installer is the bitness of your application that you specify on the Platform page. 64-bit installers replaced %DESKTOP%, %MYDOCUMENTS%, and %COMMONDOCUMENTS% with empty strings if these folders were being blocked by Controlled Folder Access and the installer was not allowed through. This caused shortcuts, files, and folders that should have been installed into these folders to be installed into the root of the drive. As a consequence, 64-bit installers did not correctly handle the option to check whether the installer was allowed through Controlled Folder Access. They never showed the warning. They did correctly add themselves to the list of allowed applications if you enabled that option.
On the 3rd Party page, you can now select .NET 4.7.1 as the minimum required .NET version.
On the Platform page, you can now select the earliest and latest version of Windows 10 that your application supports. If your application depends on .NET 4.7.1, for example, you need to select 1607 Anniversary Update as the earliest version. You can select versions 1507 and 9999 if you want your installer to accept any past and future version of Windows 10 like installers built with previous versions of DeployMaster did.
Windows 10 version 1709 (Fall Creators Update) added a new feature to Windows Defender called Controlled Folder Access. If enabled, it prevents applications from writing to folders that are normally used to store personal files. That includes the Desktop and Documents folders. Even installers that run with Administrator privileges are be blocked.
On the Platform page, DeployMaster now provides four new options to deal with this. You can turn those on and off independently to suit your installer’s need.
DeployMaster’s own installer is now built with the first two options turned off and the last two turned on. This means it no longer complains if it can’t create the desktop shortcut and that you’ll have no issues saving or building installers in personal data folders.
DeployMaster 4.0.0 added the ability to install fonts and make them available to all applications. All you need to do is to put the font’s .ttf or .otf file under %FONTS% on the Files page in DeployMaster.
Unfortunately, DeployMaster 6.0.0 introduced a bug that broke this. The installer still copied font files to the correct folder. But it did not register any fonts. So the installed fonts would not actually be visible to other applications.
DeployMaster 6.1.2 fixes this. Fonts are once again correctly installed and registered. They are available immediately to other applications. No reboot is required. But most applications only retrieve the list of fonts once when they start. So applications that were running while the font was installed may need to be restarted for them to see the newly installed font.
On the Project page, you can specify a readme file, a license agreement, and support DLLs. All these files are optional. Previously, DeployMaster ignored these file paths if they were invalid. Now, non-existent files on the Project page are treated as non-fatal errors. This way you don’t accidentally build an installer with reduced functionality when a file goes missing. It’s also consistent with how non-existent files are treated on the Files page.
DeployMaster 6.0.0 introduced the ability to build installers that install for the current user without administrator rights. To implement this, a second set of default installation folders was added on the Project page. Additional checks were added to the build process to ensure that the default installation folders are valid and appropriate for installations for all users or the current user.
These new checks broke the ability to specify absolute paths for installations for all users. DeployMaster 6.0.0 through 6.1.0 would show an error as if you hadn’t specified a default installation folder at all when you specified an absolute path. This has been fixed so that absolute paths are accepted as default folders for all users.
Using absolute paths is not recommended, however. If the path’s drive does not exist and the user does not change the installation folder then the installation will fail. You can use the %SYSTEMDRIVE% placeholder instead of C: if you want to install onto the drive that Windows is installed on. There were no issues with this placeholder in DeployMaster 6.0.0 through 6.1.0.
You can only use absolute paths or %SYSTEMDRIVE% for default installation folders for the current user if you turn on “require admin rights” for current user installs. If the user does not have administrator rights they are likely not able to write to the root of the C: drive.
If for any reason your installer is not able to create a file or folder it shows an error message to the user that mentions this file or folder. If this file or folder had a percentage sign in its name then the error message would complain about the percentage sign instead of saying the file or folder could not be created. Percentage signs are allowed as literal characters in file and folder names. They only have a special meaning in DeployMaster when used as part of a placeholder at the start of a path.
On the 3rd Party page, you can now specify .NET 4.7 as the minimum required .NET version.
The Windows 10 Anniversary update includes .NET 4.6.2 but it’s a different build than the .NET 4.6.2 that you can download separately other versions of Windows. Your installer now correctly detects this as .NET 4.6.2 if you specify .NET 4.6.2 as the minimum required .NET version.
On the Media page you can use the placeholders %VERSION09% and %DATE09% in the file name for the generated setup to insert the applications’s version number and release date stripped of all non-digits. These have been supported since DeployMaster 4.1.0. But they were broken in DeployMaster 5.0.0 through 6.0.1 when these stripped the digits instead of retaining only the digits.
DeployMaster is now able to automatically check for updates and other news. You can also make it check on request by selecting Help|News and Updates in the menu. When DeployMaster shows news or when the check on request tells you there is no news you can click the Settings button to choose which news items you want to see. By default, DeployMaster automatically shows news and updates for itself and any of our products that you’ve used in the past 30 days. Though for RegexBuddy and RegexMagic that will only start working once they gain the ability to automatically show news.
News settings and history are shared between all our products so you won’t see the same news more than once. Each product automatically shows at most one news item per day and at most one news item on request. So you don’t need to worry about ever being bombarded with news if you haven’t used our software for a while. You won’t see the news item announcing DeployMaster 6.1.0 either because that is considered to be old news already when you’ve upgraded to DeployMaster 6.1.0.
See also: DeployMaster 6.1.0 version history
This release fixes a few issues that we missed in 6.0.0 earlier this week. Most importantly, turning on the option to completely cover the screen background no longer results in an error saying “cannot focus a disabled or invisible window” when first starting the installer and after passing an elevation prompt.
While building the installer you will no longer get an error if the registry key you specified on the Identity page starts with HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER and you turn on only “install for all users” or only “install for current user” on the Project page. DeployMaster 5.4.0 and earlier insisted on a registry key starting with one of these root keys. DeployMaster 6 requires you to omit the root key if you turn on both “install for all users” and “install for current user”. It automatically chooses between HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER depending on whether the user chooses to install for all users or only for the current user.
If the user starts an installer for an application that is already installed, and the installer supports portable installations, then the installer no longer makes the Portable Installation button (which replaces the Custom Installation button) the default button. Immediate Installation is now the default. If the installer does not support portable installations, then the Custom Installation button is the default button, like before.
DeployMaster 6 is a free minor update. We’ve numbered it as a major upgrade because it brings some fundamental changes. You should back up your existing installation before upgrading.
The most apparent change in DeployMaster 6 are the new icons. DeployMaster’s application icon now scales to all sizes that Windows Explorer can display icons at. The folders and files tree on the Files page in DeployMaster and in the component selection screen in the installer now retrieves folder and file icons from Windows, so they will scale correctly and match the icons the user is used to seeing in Windows Explorer. The toolbar icons have a new flat look of the icons better matches the flat look of Windows 10. DeployMaster includes them in 10 different sizes that cover all the scaling increments from 100% to 400% available in the basic display settings in Windows. DeployMaster can now perfectly scale itself and the installers it generates on all PC and laptop displays, including small laptops with 4K screens.
The icon that you specify on the Project page is now used to replace the icon of the setup.exe. When the user sees your installer in Windows Explorer, they will see this icon. It also appears on the window caption and taskbar button when your installer runs. The icon is no longer displayed it in the lower left and upper right corners of the installer.
Another apparent change is that some of the default labels in the installer have changed. The No-Questions-Asked Installation and Advanced Options Installation buttons, for example, are now labeled Immediate Installation and Advanced Installation. You can still edit all labels on the Language page in DeployMaster. The Print button for the readme file and license agreement now has a text label that you can translate.
The most important change is that DeployMaster 6 can now create user-specific installs without administrator privileges. On the Project page, you can choose whether you want to allow installations for all users, installations for the current user, or both types of installations. There are now 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. All of DeployMaster’s features are available for user-specific installs without administrator privileges.
If you enable both types of installations, then an Advanced Installation has a new initial step that shows two buttons labeled install for current user and install for all users to choose the type of installation. The rest of the installation process is unchanged. An Immediate Installation chooses the type of installation automatically. If the installer was forcibly run with administrator privileges or if the user has an account that allows elevation to administrator privileges then the application is installed for all users. Otherwise, the application is installed for the current user only. This way an immediate installation makes use of admin privileges when available, but does not prompt for elevation when the user probably doesn’t have the password to an admin account.
If your application is already installed, then both Immediate Installation and Advanced Installation automatically choose the same type of installation. If the existing installation is for all users then administrator rights will be needed. Installations made by installers created with DeployMaster 5.4.0 or earlier are treated as installs for all users.
If one user creates a user-specific installation and then another user runs the installer, then the installer will act as if your application is not installed yet. The second user will then be able to install for themselves as well as install for all users. If the second user installs for all users, the first user will still be able to update or uninstall their user-specific installation.
Because DeployMaster now differentiates between all-user and user-specific installs, it imposes some new restrictions on the folders that you can use. The folders %MYDOCUMENTS%, %APPDATAROOT%, and %LOCALAPPDATAROOT% cannot be used as default folders for all users, and cannot be used on the Files page if you enable the option to install for all users. These folders are user-specific folders and are not (easily) accessible to other users on the same PC. The folders %COMMONDOCUMENTS% and %COMMONAPPDATAROOT% cannot be used as default folders for user-specific installs and cannot be used on the Files page if you enable the option to install for all users. These folders are shared between all users.
The folders %PROGRAMFILES%, %COMMONFILES%, %WINDOWS%, %FONTS%, %SYSTEM%, and %SYSTEMDRIVE% are system folders. They are shared between all users and require admin rights to write to. So you shouldn’t use these folders for user-specific installs. DeployMaster will permit you to use them for user-specific installs, however, if you turn on the option to require admin rights for installations for the current user. Doing so is not recommended as it mostly defeats the purpose of allowing user-specific installs. This option is mainly provided to allow you to deal with poor decisions made in the past. If management decides that applications should be installed into %PROGRAMFILES% and that data files should go into %MYDOCUMENTS% because that’s the easiest place for the user to find them, then you can accommodate this with DeployMaster 6 by turning off the option to install for all users and turning on the options to install for the current user with admin rights. This combination of options will also allow installations made with DeployMaster 5.4.0 or prior to be upgraded correctly.
There are also new restrictions on registry keys. If you enable installations for all users, then you cannot create registry keys under HKEY_CURRENT_USER because those are only visible to the user performing the installation. If you enable installations for the current user, then you shouldn’t create registry keys under HKEY_LOCAL_MACHINE. If you must then you’ll need to the option to require admin rights for user-specific installs.
If you enable both types of installations, you can’t use either of these root keys. In that situation, create your registry keys under HKEY_AUTO. This is not an actual registry key but a placeholder in DeployMaster that represents HKEY_LOCAL_MACHINE for all-user installs and HKEY_CURRENT_USER for user-specific installs. When your application needs to read keys written by the installer, it should first try to read from HKEY_CURRENT_USER. If that succeeds, it is running from a user-specific install. If that fails, it should read from HKEY_LOCAL_MACHINE. To determine installation folders, create a registry value using placeholders such as %APPFOLDER% or %USERDATA% under HKEY_AUTO.
If your application needs to be installed for all users and also needs keys under HKEY_CURRENT_USER, then you can create those keys under HKEY_USERS. Keys you place there are created for all user accounts. Your application will be able to read them from HKEY_CURRENT_USER regardless of which user is running it. You can also add dummy keys and values under HKEY_USERS if your application creates registry keys when it runs. This will allow the uninstaller to clean up those registry keys for all users.
Keys you add under HKEY_CLASSES_ROOT are created there for installations for all users. They’re created under HKEY_CURRENT_USER\Software\Classes for user-specific installs.
If you just want upgrade to DeployMaster 6 and keep your installer working the way it always has, just open your .deploy file in DeployMaster 6 and click the Build button. If you didn’t use any user-specific folders or registry keys, you’ll be good to go. If you did, switch to the Project page. Turn off “install for all users” and turn on both “install for current user” and “require admin rights”. Cut and paste the default installation folders from the left hand side to the right hand side. Then rebuild. Either way, your new installer will correctly upgrade existing installations. If you had to switch to “install for current user”, then new installs will create shortcut icons and file associations for the current user only. Since you had to switch because you were using user-specific folders or registry keys, your installation was never really correct for all users anyway. On a PC used by a single person with a single account, that person will not see any difference between an install for all users or an install for the current user with admin rights.
DeployMaster itself can now be installed for the current user without admin privileges. It can still be installed for all users like before. The Advanced Installation now allows you to choose in which folder DeployMaster should place the .language files that are shared between all your installation scripts.
On the Update page, you can now have your installer expire on a specific date or a certain number of days after the release date. This can be useful to prevent prospective customers from making a decision based on an outdated trial version. If you sell software on a subscription basis, you can prevent accidental installs of outdated versions. You can customize the message shown by an expired installer to explain where the user can get the latest version. This feature is intended to prevent the user from wasting their time installing obsolete software. It can be easily bypassed by fiddling with the system clock. If you really need your software to stop working after a certain date, you need to add such protection to the application itself.
See also: DeployMaster 6.0.0 version history
The installer now displays the readme file and the license agreement using the same font as the rest of the installer if they are plain text. You can specify this font on the Appearance page. The progress meter in the installer no longer updates itself for each and every file when very small files are being installed as this needlessly slowed down the installation.
On the 3rd Party page, you can now specify .NET 4.6.1 and 4.6.2 as the minimum required .NET version. On the Registry page you can now use placeholders such as %VERSION% and %DATE% in key and value names and in string values. These are documented in the topic about the Media page where you can use the same placeholders in file and folder names.
See also: DeployMaster 5.4.0 version history
Building installers that contain thousands of small files (a few kilobytes each) is now significantly faster, particularly when selecting “Faster”, “Minimal”, or “None” as the compression method on the Media page.
The checkboxes for selecting file associations during an advanced options installation now scale correctly on high DPI systems.
See also: DeployMaster 5.3.0 version history
If you build your installer on Windows 7 and on the platform page you selected only Windows 7 or later versions, then DeployMaster now applies a digital signature using SHA-256 instead of an SHA-1 as well as a timestamp using RFC 3161. This means that if your installers no longer need to support XP or Vista, then you can continue using Windows 7 to build installers with digital signatures that will be accepted by Windows 10 after January 1st, 2017. We previously believed Windows 7 could not apply RFC 3161 timestamps. It can, but the function needed for that on Windows 7 is documented incorrectly by Microsoft, causing a crash when called as documented.
Windows 10 will require SHA-256 time stamps for downloaded files on January 1st, 2017. This means Windows 10 will consider the download unsigned when the certificate used to apply the signature expires. So you won’t notice this problem on January 1st, but when your certificate expires after 1/1/17. DeployMaster now shows a warning while building if it cannot apply an SHA-256 timestamp that will be needed by 1/1/17. You will never get this warning if you build your installer on Windows 8 or later, as Windows 8 and later can apply dual signatures if needed. If you build on Windows 7, you will get this warning if you select Windows 10 as well as XP or Vista on the Platform page. XP and Vista don’t support SHA-256 timestamps, and Windows 7 cannot apply dual signatures. If you build on XP or Vista, then you will always get this warning if you select Windows 10 on the Platform page, because XP and Vista cannot apply SHA-256 timestamps. On 1/1/17 this warning will turn into a non-fatal error. The installer will still be built successfully and will still be signed and timestamped with SHA-1 when this warning or error appears.
See also: DeployMaster 5.2.0 version history
Microsoft is deprecating the SHA-1 message digest algorithm. As of January 1st, 2016, you need an Authenticode certificate based on SHA-256 to build installers with digital signatures that will be accepted by Windows 7 and later. If you purchased your certificate in 2014 or 2015, then you likely already have a SHA-256 certificate. Older certificates are likely still based on SHA-1. To check this, open Windows Explorer and right-click on an .exe file that you have previously signed with your certificate. Click on the Digital Signatures tab. The “digest algorithm” column indicates the digest of the signature itself, which can be “sha1” or “sha256” as explained in the next paragraph. To check your certificate, click the Details button. Then click the View Certificate button. Then click the Details tab. The “signature algorithm” should be “sha265RSA” and the “signature hash algorithm” should be “sha256”. If instead you see “sha1RSA” and “sha1” then your certificate is obsolete since January 1st, 2016. In that case, you need to obtain a new certificate. If the “valid to” date on your certificate is some time in the future, you should be able to have a new SHA-256 certificate issued for the remaining validity period at no cost and no paperwork. Log onto the website of the company that sold you your certificate and follow their instructions to have the same certificate “replaced” or “reissued”. The replacement certificate will automatically use SHA-256. SHA-1 certificates are no longer issued.
Windows XP SP3 is the oldest version of Windows that supports SHA-256 certificates (but not SHA-256 signatures). So once you’ve replaced your certificate with an SHA-256 certificate, you won’t be able to create digital signatures for Windows XP SP2 or prior. Since Windows 2000 and prior do not display any warnings based on digital signatures and only support versions of Internet Explorer that do not display such warnings, this is not really a problem. So DeployMaster can still generate a single installer that works on Windows 98 through Windows 10. DeployMaster itself now requires Windows XP or later to run. Windows 2000 is no longer supported.
Once you have an SHA-256 certificate, you can use any DeployMaster 4.x.x or 5.x.x release to build installers with signatures that are accepted by Windows XP SP3, Vista, 7, 8, 8.1, and 10. DeployMaster 4.x.x always applies SHA-1 signatures. It can do so using an SHA-256 certificate. Like many others, we previously believed that SHA-1 signatures would not be accepted by Windows 7 and later unless timestamped prior to January 1st, 2016. But this is incorrect. Windows 7 and later continue to accept SHA-1 signatures. Even MD5 signatures are still accepted. MD5 is considered broken and was never used by DeployMaster.
Because we believed SHA-1 signatures would no longer be accepted by Windows 7 and later, DeployMaster 5.0.0 applied SHA-256 signatures to installers targeting Windows 7 or later. This made DeployMaster require Windows 7 or later when building installers, as XP and Vista don’t support SHA-256 signatures. DeployMaster 5.0.0 applied dual SHA-1 and SHA-256 signatures to installers targeting XP or Vista as well as Windows 7 or later. This made DeployMaster itself require Windows 8 or later, as Windows 7 and prior cannot apply dual signatures.
Since we now know SHA-1 signatures are still accepted, DeployMaster 5.1.0 no longer requires Windows 7 or 8 to build signed installers targeting Windows 7 or later. If you build your installers on Windows Vista or XP, then DeployMaster 5.1.0 applies an SHA-1 signature regardless of your choices on the Platform page. If you build on Windows 7 then DeployMaster 5.1.0 applies an SHA-256 signature if you target only Windows 7 and later or an SHA-1 signature if you target XP or Vista. If you build on Windows 8 or later then DeployMaster applies dual signatures to installers targeting XP or Vista as well as Windows 7 or later and a single SHA-1 or SHA-256 signature otherwise. In other words, DeployMaster 5.1.0 applies SHA-256 signatures when possible and desirable but reverts to SHA-1 otherwise. So you get the strongest possible signature, without requiring you to upgrade your development system to a newer version of Windows.
RFC 3161 timestamps are now applied to digital signatures for Windows 7 and later if you build your installer on Windows 8 or later. DeployMaster requests SHA-256 to be used for the timestamp. Timestamp services are required to support SHA-256 as of January 1st, 2016. In our tests, all timestamping services selectable on the Media page do this. The only exception right now is Geotrust which provides an SHA-1 timestamp. We expect Geotrust to update their timestamping service in the near future.
Authenticode timestamps using SHA-1 are still applied to digital signatures for Vista and prior, as they do not recognize RFC 3161 timestamps. Authenticode timestamps are also applied when building your installer on Windows 7. Though Windows 7 supports RFC 3161 timestamps, the function for applying such timestamps appears to be unavailable, contrary to Microsoft’s documentation.
SHA-1 timestamps are still accepted by all versions of Windows. Windows 10 will require SHA-256 time stamps for downloaded files on January 1st, 2017 (next year). DeployMaster 5.1.0 is ready for this, as long as you’re building your installers on Windows 8 or later. If you are still running Windows 7 and want to provide signed downloads to Windows 10 users, you should get your free upgrade to Windows 10 prior to 29 July 2016.
See also: DeployMaster 5.1.0 version history
The release notes for DeployMaster 5.0.0 and 5.0.1 indicated SHA-1 signatures would not be accepted by Windows 7 or later unless timestamped prior to January 1st, 2016. This was widely believed but turned out to be incorrect. We removed these release notes to avoid further confusion. The version history keeps a full record of all the changes that were made. The release notes for 5.1.0 explain the whole situation with the benefit of hindsight.
If you don’t apply digital signatures to your installer, then nothing changes for you. Upgrading to DeployMaster 5.0.0 still gains you one thing. On the Build page, there is now an Abort button that allows you to abort the build. The Build button is now disabled during a build, so you can no longer accidentally cause the build to fail by clicking the Build button twice.
This release brings full support for Windows 10. The only real change is that the Platform page now has a separate checkbox for Windows 10. The actual installation process didn’t need any changes. Installers created with DeployMaster 4.2.2 and 4.2.3 work correctly on Windows 10 as long as you ticked “future versions of Windows” on the platform page. Installers created with earlier DeployMaster 4.x.x releases work correctly if the latest Windows version supported by your version of DeployMaster is ticked on the Platform page. Like Windows 8.1, Windows 10 lies when an application asks which version it is unless that application indicates specific support for Windows 10. DeployMaster 4.2.1 and prior therefore misidentify Windows 10 as Windows 8 or 8.1. Installers created with DeployMaster 3.x.x also work correctly on Windows 10. Installers created with even older versions of DeployMaster (released between the years 2000 and 2006) will have the same issues on Windows 10 as they had on Windows Vista, as they predate Windows Vista and its tighter security system.
On the Project page, there is a new checkbox to skip the license agreement. An installer built with this option does not show its license agreement if the same application is already installed. It doesn’t matter if that is the same or a different version of that application. If your license agreement doesn’t change between releases, you can save your users the click to agree to it once more when installing new versions of your application. The installer for DeployMaster itself uses this option too.
Several new command line parameters were added to the installer. The /appfolder, /appcommonfolder, /appmenu, and /userdata command line parameters can be used to change the actual folders used for files placed under %APPFOLDER%, %APPCOMMONFOLDER%, %APPMENU%, and %USERDATA% on the Files page. If your installer uses a support DLL to define additional installation folders, then those folders can also be changed by using the name of the folder as a command line parameter. The purpose of these parameters is to allow the installation folder to be changed when using the /silent command line parameter. If the software was previously installed, using these command line parameters changes the installation folder, just like the Advanced Options Installation button can be used to change the folders of an existing installation. These command line parameters can be used without /silent. In that case, when using the Advanced Options Installation button, the default folders will be those specified on the command line. Selecting different folders via Advanced Options Installation overrides the command line parameters.
The /silent parameter can now be abbreviated as /s when passed to the installer or the uninstaller.
The setup.exe that DeployMaster generates is a stub with the installer and the files to be installed as its payload. When the stub runs, it extracts the actual installer into the temporary files folder and executes it. Only then does the installer appear on the screen. Running from the temp folder is a legitimate technique that has been used for a long time by installers and self-updating software. But recently some companies have implemented a Software Restriction Policy that blocks executables in the temporary files folder in the belief that this can block malware. In this situation, installers built with previous releases in DeployMaster fail to run without showing an error message. Installers built with DeployMaster 4.3.0 show an error message indicating that the temp folder is restricted and that the user should run the installer with the /temp command line parameter followed by the full path to a folder that the user can write to and run applications from.
See also: DeployMaster 4.3.0 version history
DeployMaster now supports .NET 4.6. If your application requires .NET 4.6 then you can tick the “4.x” checkbox and select “4.6” from the adjacent drop-down list on the 3rd Party page.
If you specify that your application requires .NET 3.0 or later (and doesn’t support .NET 1.x or 2.0), then DeployMaster will force you to deselect older Windows versions on the Platform page. Windows XP2 or later is required for installing .NET 3.x. Windows XP3 or later is required for installing .NET 4.0. Windows Vista SP2 or later is required for installing .NET 4.5 or 4.6.
A few bugs were fixed. Turning on the option to completely cover the screen background and selecting a bitmap file to be shown on the background caused the installer to crash upon startup if it was run with the /silent command line parameter. 64-bit installers crashed when showing the readme file or license agreement if the AllocationPreference registry key forces memory to be allocated from the top down. Iinstallers built with DeployMaster never use more than a few hundred MB of RAM. Without this registry key there are never any issues with pointers beyond 4 GB.
See also: DeployMaster 4.2.3 version history
DeployMaster can now differentiate between .NET 4.5, 4.5.1, and 4.5.2. On the 3rd Party page, the 4.0 and 4.5 checkboxes were replaced with a 4.x checkbox and a drop-down list giving a choice between 4.0, 4.5, 4.5.1, and 4.5.2. This better reflects that only one 4.x release of .NET can be present on a PC, and that any application that is compatible with a specific 4.x release of .NET is also compatible with all later 4.x releases. This is not necessarily the case with .NET 3.5 and prior, which retain their separate checkboxes. If your application needs .NET 4.x you should tick the 4.x checkbox on the 3rd party tab and then select the minimum version of .NET 4.x that your application requires from the drop-down list. The generated installer will then require this version or any later version to be installed on the user’s PC.
Microsoft released the Windows 10 Technical Preview at the end of last month. Like Windows 8.1, Windows 10 lies when an application asks which version it is unless that application indicates specific support for Windows 10, which was not possible prior to the release of the technical preview. Installers built with DeployMaster 4.2.2 now indicate this support so that they can detect Windows 10 as being Windows 10. Windows 10 pretends to be Windows 8.1 to installers built with 4.2.0 and 4.2.1. Windows 10 pretends to be Windows 8 to installers built with DeployMaster 4.1.2 and prior.
On the Media page, you can now select the time stamping URL that DeployMaster uses to countersign the digital signature on your installer. Previously, DeployMaster always used the Verisign time stamping service. Now you can choose several other services in case Verisign’s URL is inaccessible. This happens occasionally due to maintenance and network outages. DeployMaster remembers the URL as a global preference. It is not saved into the .deploy file. This way you only need to select a different URL once if your previous choice stops working. The new URL will be used for all future builds until you change it again.
A couple of bugs were also fixed. Values returned by LoadIdentity() or LoadIdentityA() in the support DLL were not used if Windows 98 and Windows ME were deselected on the Project tab (in which case DeployMaster generates a Unicode installer). Splitting the installer into chunks of a certain size resulted in chunks files without file names if you did not specify a file name for the installer without 3rd-party installers.
This release brings a handful of small fixes and improvements. On the 3rd Party page, you can specify whether your installer should install the .NET framework. Versions 1.0 through 4.5 are all supported. The build of the .NET framework that is included with Windows 8.1 is now correctly detected as .NET 4.5. This build is more recent than the .NET 4.5 build that is included with Windows 8. Previously DeployMaster incorrectly detected the new .NET 4.5 build as being .NET 4.0.
On the Media page, you can use the placeholders %VERSION%, %DATE%, %VERSION09%, %DATE09%, and %YYYYMMDD% to insert version and date numbers into the file name and folder for the generated installer. Now, you can use those same placeholders in the background labels that you can specify on the Appearance tab.
On the Update page, you can specify window captions that your installer should look for to detect whether your application is still running or not. You can specify multiple captions by delimiting them with semicolons. Previously, DeployMaster incorrectly treated spaces as delimiters between captions. Now, spaces are treated as literal characters so captions that consist of multiple words can be detected.
See also: DeployMaster 4.2.1 version history
Headline feature of this release is full support for Windows 8.1. Since Windows 8.1 is more like a glorified service pack for Windows 8 than a real new version of Windows, no changes had to be made to DeployMaster to make it compatible with Windows 8.1. The only change is that the Platform page now has a separate checkbox for Windows 8.1 and Server 2012 R2. You can use this checkbox to control whether your installer should allow your software to be installed on Windows 8.1 or not. If you don’t, and the user is running Windows 8.1, then the %USER% placeholder in the message for mismatched Windows versions will be substituted with “Windows 8”. If you created an installation script with a previous 4.x.x release and load that script into DeployMaster 4.2.0, then Windows 8.1 will automatically be selected or deselected depending on whether you had Windows 8 selected or deselected in the previous 4.x.x release. Whether “future versions of Windows” was selected or deselected does not matter.
Installers built with previous 4.x.x releases of DeployMaster cannot differentiate between Windows 8 and Windows 8.1. If Windows 8 was checked on the Platform page then the installer will work on Windows 8.1. If Windows 8 was not checked on the Platform page, then the installer will not allow installation on Windows 8.1. Whether “future versions of Windows” was checked or not does not matter. The %USER% placeholder in the message for mismatched Windows versions will be substituted with “Windows 8”.
The reason for all this is that Windows 8.1 pretends to be Windows 8 unless an application specifically indicates that is supports Windows 8.1. Installers build with DeployMaster 4.2.0 indicate that they support Windows 8.1. Installers built with previous versions do not.
The best way to get technical support for DeployMaster is via its built-in forum. You can access it by selecting Help|Forum in the menu in DeployMaster. Previously, DeployMaster could connect to the Internet (and to the forum) if your PC had a direct internet connection or if it could connect through an HTTP proxy that either required no authentication or allowed basic authentication. You can configure the proxy server via the Proxy button on the login screen to the forum. Now DeployMaster supports additional authentication methods for HTTP proxies. It will automatically negotiate a supported authentication method with the proxy server, so there’s no need to select the authentication method when you configure your HTTP proxy in DeployMaster. DeployMaster can now also connect to the Internet via proxy servers using versions 4, 4A, or 5 of the SOCKS protocol. You’ll need to select the correct version when configuring your SOCKS proxy in DeployMaster. If your SOCKS proxy needs a password, then it will be running SOCKS version 5.
See also: DeployMaster 4.2.0 version history
This release fixes several bugs. If you’ve added 3rd party installers on the 3rd Party page, those will now have their command line parameters passed correctly to them. 3rd party MSI installers are now run silently when your installer is run silently. On the Identity page, some combinations of identity settings were not handled correctly while building the installer, causing the installer to skip asking for identity information if no support DLL with identity routines was provided, or to ask for all information if it was. If you’ve configured certain DLLs to be registered on the Files page, the uninstaller will no longer make a command prompt window briefly flash on the screen when unregistering the DLL.
This release fixes a serious bug. The option on the Update page to delete files that were part of a previous version but aren’t part of the current version should not delete shared files that are still used by other applications. Shared files are files installed into the %WINDOWS%, %SYSTEM%, and %APPCOMMONFOLDER% folders. This bug has existed since DeployMaster 1.0.0. It went unnoticed because it is rare for a newer version of an application to have fewer shared files than a previous version, and the option on the Update page to delete such files is off by default.
The bug is acute in DeployMaster 4.1.0 because this is the first version that puts the uninstaller into %APPFOLDER% instead of %WINDOWS%. If build an installer with DeployMaster 4.1.0 with the option on the Update page to delete files not part of the current version, and the user already has multiple applications installed that were packaged with older versions of DeployMaster, then your installer will delete the uninstaller in %WINDOWS%, even if those other applications still need it. This makes it impossible to uninstall those other applications. The workaround is for the user to manually copy the uninstaller from your application’s %APPFOLDER% into c:\Windows.
If you did not turn on the option on the Update page to delete old files, then there is no problem. Then the uninstaller will remain in the %WINDOWS% folder, and will be correctly removed by the uninstaller when the last application needing the uninstaller is uninstalled, regardless of whether that is your application or another application. The installer for DeployMaster itself had the option to delete files from previous installations on the Update page turned off, so there are no problems with the uninstaller when upgrading DeployMaster itself to version 4.1.0.
So if you have released installers built with DeployMaster 4.1.0 with the option on the Update page to delete files that were part of a previous version but aren’t part of the current version turned on, then you should rebuild and rerelease those installers with DeployMaster 4.1.1 as soon as you can. If your installers are built with older versions of DeployMaster, then there is no rush to upgrade (though you may still want to do so for the improved Windows 8 support). If you built installers with DeployMaster 4.1.0 but turned off the “delete files...” option on the Update page, which is off by default, then there is also no need to rebuild those installers with DeployMaster 4.1.1.
DeployMaster 4.1.1 also fixes and improves some placeholders. The %SETUPFOLDER% and %SETUPDRIVE% placeholders that represent the folder and the drive from which your installer was launched are now correctly substituted in values you add to the Registry page. The %VERSION% placeholder can now be used in the messages for mismatched bitness and mismatched Windows versions on the Platform page. It will be replaced with the Application Version Number specified on the Project page. Including the version number in these messages is useful if you have different versions of an application that target different versions of Windows.
See also: DeployMaster 4.1.1 version history
The headline features for DeployMaster 4.1.0 are full support for Windows 8 and .NET 4.5. Basically, there’s a new “Windows 8” checkbox on the Platform page that you can use to indicate whether your installer should support Windows 8 or not. On the 3rd Party page, there’s a new checkbox to have your installer check whether .NET 4.5 is available, and install it as needed.
The most obvious change in Windows 8 is that the Start Menu that was introduced with Windows 95 has been replaced with a Start Screen. The Start Screen is populated in the same way as the Start menu was, by adding shortcuts under %APPMENU% on the Files page in DeployMaster. By default, Windows 8 will pin shortcuts to executable files to the Start Screen, while other shortcuts can be accessed by right-clicking and selecting “All apps”. This is what happens on Windows 8 to shortcuts created by installers built with DeployMaster 4.0.7 and prior.
If you select a shortcut under %APPMENU% or %PROGRAMSMENU% on the Files page in DeployMaster 4.1.0, a new “Windows 8” option appears at the bottom of the window. This option allows you to tell Windows 8 what to do with the shortcut when your application is first installed. You can choose the default behavior, or you can choose not to pin the shortcut by default, or you can force the shortcut to be pinned. If your installer adds shortcuts for utility applications, you may want to choose not to pin those. If your installer installs only document files, meaning nothing would get pinned by default, you may want to force the main document to be pinned. Windows 8 only respects this option upon first installation. If you want to test this feature, you need to do so on a copy of Windows 8 on which your software was never installed. A virtual machine is probably the best way to do this. If you turn on the option to create a shortcut to the uninstaller on the Finished page, then DeployMaster will automatically tell Windows 8 not to pin that shortcut.
The uninstaller is now placed into %APPFOLDER% rather than in the Windows folder. This allows each application to have its own copy of the uninstaller, with a digital signature that belongs to each application’s vendor. If multiple applications are installed into the same folder, they will share a single copy of the uninstaller.
On the Media page, you can now choose between faster or stronger compression, or no compression at all. The “best” method is what DeployMaster 4.0.x used. You may want to disable compression to increase build speed while testing your installer, and change it back to “best” when making your final release. You can now use %VERSION% and %DATE% placeholders for the version and release date in the file name and output folder for the generated Setup.exe. Use %VERSION09% and %DATE09% for the same with only the digits 0 to 9, or use %YYYYMMDD% for this format instead of the system default short date format.
See also: DeployMaster 4.1.0 version history
This release fixes one bug that we missed in version 4.0.6. Version 4.0.6 fixed several bugs related to silent installations, but unfortunately also introduced a new bug. Silent installs of installers built with version 4.0.6 did not properly substitute built-in placeholder folders such as %PROGRAMFILES% causing files and folders to be installed into the root of the drive that the setup was run from. Rebuilding your installer with version 4.0.7 will make silent installs use the proper folders again.
This release fixes two bugs in the installers that DeployMaster 4.0.x generates when running them with the /silent command line parameter to perform a silent installation. If you turned on the option on the Appearance page to cover the whole screen’s background, then the installer would crash upon startup when run with /silent. If you specified a Support DLL on the Project page, the installer did not use the DLL at all when running it with /silent. Because of the latter bug, the installer for the licensed version of DeployMaster 4.0.x itself did not install the license key when installed silently, causing DeployMaster to ask for your user ID the first time you ran it. If you created installers with DeployMaster 4.0.x that use the option to cover the screen background or that need a support DLL, then you should rebuild those installers with DeployMaster 4.0.6 to make sure your customers don’t run into trouble when they use the /silent command line parameter.
On the 3rd Party tab, if you selected one of the .NET versions and you specified a .NET installer file but you did not specify a .NET download URL was specified then the generated installer crashed upon startup. If your installer needs .NET and you don’t have your own download page for the .NET framework, you can use /dotnetfx.html as the URL for the .NET framework. If you click this link in your browser, it will list all .NET versions that DeployMaster supports. But when this link is launched from your installer, it will list only the .NET version that your installer needs.
Also on the 3rd Party tab, selecting one of the .NET options without specifying a .NET installer no longer causes an error about the file name of the generated setup being the same as that of a 3rd party setup when one of the file names for the setups to generate on the Media tab is blank.
See also: DeployMaster 4.0.6 version history
On the Media page you can specify a code signing certificate that DeployMaster should use to sign your installer, along with an option to also sign all .exe files that you added to your installer. If any of those .exe files cannot be signed, DeployMaster now adds them to the installer unsigned. The Build tab will still display an error message, but the error is no longer treated as fatal Not signing .exe files to be installed by the setup does not affect the security warnings that occur during installation at all.
If you select a conversation or message in DeployMaster’s built-in user forum and press Ctrl+C, an URL pointing to that conversation or message is copied to the clipboard. If you paste that link into a message on the forum, it will now be highlighted as a link. Double-clicking the link will activate the message. The discussion links at the bottom of each help file topic now also open DeployMaster’s forum.
DeployMaster uses a .chm file to provide context-sensitive help. This is the standard help system for modern Windows applications. Due to a bug in Internet Explorer 9, if a 64-bit application requests context-sensitive help using a .chm file, and you click on a link in that help file, the calling application will crash. To work around this, we’ve disabled context-sensitive help in the 64-bit version of DeployMaster if you have Internet Explorer 9 installed on your PC. Pressing F1 will still open the help file, but it will show the first page in the help file, rather than the page that describes the part of DeployMaster you’re using.
On the Update page you can configure your installer to require a previous version of your application to be installed. This is useful for building “patch” installers that do not include the entire application, but only files that have changed since a given previous version. If you used this option in previous DeployMaster 4.0.x releases, the generated installer would crash upon startup. Version 4.0.5 restores this feature.
If you turn on the option to allow portable installations and the user clicks the Create Portable Installation button in the installer, then your installer will show a list of removable drives and a field to type in the name of the installation folder. Installers built with previous versions of DeployMaster ignored any drive letters the user added to the installation folder, always using the drive selected in the list. Installers built with DeployMaster 4.0.5 will select the drive in the list when the user types in an installation folder with a drive letter.
See also: DeployMaster 4.0.5 version history
On the Media page you can specify a code signing certificate that DeployMaster should use to sign your installer. Due to the way DeployMaster 4 builds its installer, you need to let DeployMaster sign your setup.exe while building it instead of signing it by yourself afterward to make sure all security warnings indicate that your installer is fully signed. Unfortunately, previous releases of DeployMaster 4.0.x failed to correctly use your code signing settings, causing it to report that the code signing certificate could not be found. DeployMaster 4.0.4 should correctly use all code signing certificates, whether they’re stored in the registry or in a PFX file.
On the 3rd Party page you can specify whether the 3rd party installers are for 32-bit Windows, 64-bit Windows, or both. If you choose to create an installer for a 32-bit-only application or a 64-bit-only application on the Platform page, then 3rd party installers for the opposite bitness are completely excluded from your installer. This worked correctly. But if you selected the combined 32-bit and 64-bit application option on the Platform page, then an installer with integrated 3rd party installers would fail to start on 32-bit Windows if certain integrated installers were 64-bit-only, and vice versa.
If your installer cannot replace certain files, perhaps because they are in use by another application, then it will schedule those files to be replaced upon reboot. Due to a bug in DeployMaster, those files sometimes had their names shortened to 8.3 file names when they were updated upon reboot. If your installer may need to replace files with long names upon reboot, then you should rebuild it with DeployMaster 4.0.4.
See also: DeployMaster 4.0.4 version history
This release fixes a few more issues we missed in DeployMaster 4.0.x. If User Account Control (UAC) is enabled and the user was logged on as an actual Administrator, the buttons for starting the installation would still attempt to request elevation. Since the Administrator account doesn’t require elevation even when UAC is enabled, the installer was stuck at the welcome screen. This situation is unlikely on Windows Vista and Windows 7, because there is no Administrator account by default. Users with administrator privileges require elevation to perform administrative tasks, which the installer requested correctly. This situation is more likely on Windows Server 2008 which has UAC enabled by default and also has a full Administrator account by default. If your customers may want to install your software on Windows Server 2008, you should use DeployMaster 4.0.3 to rebuild any installers that you previously built with DeployMaster 4.0.x.
On the Registry page you can create string values that contain folder placeholders such as %APPFOLDER%. When your installer writes the value to the registry, the placeholders are substituted with the folders the installer actually used. DeployMaster has had this feature since version 1.0.1 but we broke it in version 4.0.0. Installers built with DeployMaster 4.0.3 once again correctly expand folder placeholders in registry values.
See also: DeployMaster 4.0.3 version history
This release fixes two issues we missed in DeployMaster 4.0.0 and 4.0.1. If you configure your installer to cover the screen with a gradient background, then DeployMaster shows a preview of this background when the Appearance page is active. When running DeployMaster 4.0.0 and 4.0.1 on Windows 7, the background also covered DeployMaster itself, making it impossible to interact with DeployMaster with the mouse. Installers built with DeployMaster 4.0.1 did not have this problem. But if the installer needed elevation on Windows Vista or Windows 7, then covering the screen background caused a (harmless) error about not being able to focus a window.
On the Media page, you can specify that DeployMaster should generate an installer with integrated 3rd party setups and an installer without integrated 3rd party setups. If you specified file names for both, then the setup with integrated 3rd party setups was built incorrectly by DeployMaster 4.0.0 and 4.0.1. The setup would claimed to be damaged when you tried to run it. If you specified a file name for the installer with integrated 3rd party setups only, then it was built correctly. Thus, if your installers built with version 4.0.1 don’t claim to be damaged, there’s no need to rebuild them with version 4.0.2.
This release fixes one serious issue and one small issue that we missed in DeployMaster 4.0.0. If User Account Control (UAC) was turned off in Windows Vista or 7, the buttons for starting the installation would still attempt to request elevation. Since that doesn’t work when UAC is off, the installer was stuck at the welcome screen. If you rebuild your installer with version 4.0.1, it will correctly detect that UAC is off, and not request elevation. It will correctly detect whether the user has administrator privileges or not, as it does on Windows XP and earlier versions of Windows (which don’t have UAC).
The other issue was that when your setup detected that an older version of your application was already installed, the message saying so indicated the version of the new setup being run rather than the version that was already installed. E.g. DeployMaster’s own installer (which is built with DeployMaster itself) would say that you already had 4.0.0 installed when in reality you had 3.3.4 installed. This bug did not affect the actual installation, but may have confused the user.
On the Files page, the new option for running executables as part of the installation now has an additional option to make waiting for those executables optional.
The language files that DeployMaster saves for any translations you’ve made on the Language page or now saved as Unicode. This makes sure characters in all scripts are properly preserved. DeployMaster will still read non-Unicode language files saved by previous versions of DeployMaster as well as UTF-8 and UTF-16 files that start with a Unicode signature (BOM).
The big new feature in this major upgrade is full support for installing 64-bit applications. On the new Platform page, you can indicate whether your application is 32-bit, 64-bit, or both. On the Files and 3rd Party pages, you can specify for each file whether it is 32-bit, 64-bit, or both (neutral). This allows you to build a single installer that can deploy both the 32-bit and 64-bit versions of your software. It also allows you to use a single DeployMaster script to create separate 32-bit-only and 64-bit-only installers for your application.
The new Platform page also allows you to specify which versions of Windows you want to allow your installer to run on. If your application does not support certain versions of Windows, you can make your installer show a message explaining that and prevent installation. Installers built with DeployMaster 4 can support Windows 98 and later. DeployMaster itself now requires Windows 2000 or later.
The Project and Files pages support a new app-specific folder %USERDATA% that defaults to %APPDATAROOT%\AppName for installing data files that the user is likely to modify after installation. On the Files page you can set your installer to grant write access to all users to the %USERDATA% folder or to any other app-specific folder. The new %FONTS% folder on the Files page allows you to install fonts that DeployMaster will automatically register to make them available to all applications.
Setups built with DeployMaster no longer show the black screen security prompt on Windows Vista and 7 when you first run them. This prompt now appears when the user clicks one of the buttons in the installer that starts the installation. This allows people without administrative rights to view the readme file and to create portable installations. The application to be run after installation as specified on the Finished page is now also run without administrator privileges. This option is intended to run the actual application after installation is complete. If you used the Finished page to run an executable or batch file that performed installation tasks, you will need to change your installer to use the new facility on the Files page to run executables. Those are run with administrator privileges (unless a portable install is created). Because the security prompt is now shown at a later stage, it is no longer sufficient to sign the final setup.exe. The actual installer embedded in the final setup.exe needs to be signed as well. DeployMaster can now automatically sign your installer and all executables in it using the Authenticode certificate that you specify on the Media page.
DeployMaster can now generate installers that are larger than 4 GB. Individual files that you add to the installer can also be larger than 4 GB. The new (theoretical) limit is 9 billion GB (2^63 bytes).
When including DeployMaster in an automated build, you can use the /q parameter in combination with /b to stop DeployMaster’s GUI from appearing during the build. If your build tool collects tool output via standard I/O, you can use the new DeployMasterCmd.exe console application to invoke DeployMaster and have the build log output to the console or standard output.
If you have any comments or questions about all these new features, select Forum in the Help menu in DeployMaster to connect to the new user forum.
As you can see, this release brings significant changes. That’s why it’s numbered as a major upgrade. But the number of new features is closer to what you’d expect of a free minor upgrade from Just Great Software. That’s why DeployMaster 4 is a free upgrade for all DeployMaster 3 users. Simply download and install it as you would any free minor upgrade.
See also: DeployMaster 4.0.0 version history