DeployMaster Release Notes
Software Quality at Just Great Software
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 via email and we'll help you out as soon as we can.
Subscribe to the Just Great Software email newsletter or the Just Great Software RSS newsfeed if you'd like us to notify you of any product updates and other developments.
DeployMaster 5.4.0 – 9 January 2017
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
DeployMaster 5.3.0 – 23 September 2016
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
DeployMaster 5.2.0 – 12 February 2016
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
DeployMaster 5.1.0 – 4 January 2016
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
DeployMaster 5.0.0 – 21 December 2015
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.
DeployMaster 4.3.0 – 19 August 2015
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 4.2.3 – 6 May 2015
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 4.2.2 – 9 October 2014
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.
DeployMaster 4.2.1 – 20 February 2014
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
DeployMaster 4.2.0 – 8 August 2013
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
DeployMaster 4.1.2 – 23 January 2013
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.
DeployMaster 4.1.1 – 15 October 2012
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
DeployMaster 4.1.0 – 24 September 2012
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
DeployMaster 4.0.7 – 19 March 2012
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.
DeployMaster 4.0.6 – 12 March 2012
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 http://www.deploymaster.com/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
DeployMaster 4.0.5 – 2 January 2012
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
DeployMaster 4.0.4 – 5 December 2011
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
DeployMaster 4.0.3 – 1 December 2011
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
DeployMaster 4.0.2 – 8 November 2011
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.
DeployMaster 4.0.1 – 4 November 2011
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).
DeployMaster 4.0.0 – 1 November 2011
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