Free Installer InstallAware for Windows Installer Header Image Windows Installer without Rocket Science

  InstallAware Blog


InstallAware Thanksgiving Special

November 20th, 2016

Happy Thanksgiving! There’s a lot we’re thankful for this year at InstallAware:

o Start Menu and Taskbar Pinning: If you’d rather not play the Windows Store/Universal Windows Platform game, InstallAware still gives your apps direct, unfettered access to prime Windows Desktop real estate!

o Native Engine Eclipses MSI: If Windows Installer is not your cup of tea, use InstallAware‘s Native Engine for faster, more resilient, and more flexible installers which work even in Windows Safe Mode.

o 64-bit Super Compression: Build the smallest setups while retaining full compatibility with 32-bit and 64-bit operating systems at the same time. Segment optional features off to optional web downloads.

o Transition FX and Aero: Support custom Aero translucent regions even on Windows 10, and make a lasting positive impression on your potential clients with app-savvy wizard transition special effects.

o Testing Automation: Spawn any number of virtual machine instances (local or remote) directly from your InstallAware IDE, and run (custom) unit tests to validate your integration engineering.

InstallAware elevates your apps to the limelight like no other!

InstallAware X5 Wins Multiple Awards in 2016

October 31st, 2016

It’s been an exciting year at InstallAware. Take a look at our latest 2016 awards:

- Visual Studio Magazine Reader’s Choice 2016 Award.
- ComponentSource Top 50 Publisher 2016 Award.

We’re also now shipping inside-the-box with Delphi, C++ Builder, and RAD Studio. InstallAware Express is available on versions XE8 through XE10.1 for free! If you’re one of the lucky users of Embarcadero compilers, help yourself using the GetIt Package Manager in your IDE.

It’s been an exciting year indeed, with everything from InstallAware X5 offering one-click Universal Windows Platform compilation for your existing Win32/Win64 apps, to latest Windows Redstone, .NET 4.6.2, SQL Server 2016 eco-system support.

Universal Windows Platform Builder

August 14th, 2016

Our launch of InstallAware X5 was a huge success two weeks ago.

InstallAware is the first – and only – installer with support for Windows 10.1 Redstone:

1) Build APPX Universal Windows Platform packages from existing (or new) setup projects.

2) Convert any existing MSI or EXE setup (even if you don’t have its source) to an APPX.

3) Target MSI, EXE, App-V, and InstallAware Virtualization formats from a single source.

New InstallAware X5 with APPX for Windows 10 Redstone

August 1st, 2016

InstallAware X5 is launching on Friday this week, with zero-day support for the latest summer hits from Microsoft:

APPX Builder: Build any InstallAware setup as a Windows 10 Redstone Universal Windows Platform application! Effortlessly carry your Win32, Win64, and .NET apps to the future.

Windows 10 Redstone: Detect and run setups on Windows 10 Redstone.

Visual Studio 15: Integrate with Visual Studio 15 and generate setup projects – and even build them – without ever leaving the Visual Studio 15 IDE.

New Runtimes: .NET Framework 4.6.2, SQL Server 2014 with Service Pack 2, [b]SQL Server 2016[/b] – you name it! If its included in the latest Redstone update cycle, InstallAware X5′s got it.

Touch Enabled and Snappy: The InstallAware X5 IDE is now touch-enabled, so feel free to fire it up on anything from handheld tablets to ultra high resolution displays (did we mention High DPI support too). Design views have been accelerated, helping you do more than before in less time.

Only InstallAware X5 generates APPX, App-V, InstallAware Virtualization, MSI Windows Installer, and EXE Native Code setups from a single source!

InstallAware 4th of July Special

July 3rd, 2016

Join us in celebrating 4th of July this year – Freedom for all setup builders worldwide!

o Independence: Past the point of your initial software and license downloads, you do NOT need to connect to any InstallAware server to install or activate your software.

o Self-Governance: Got a floating or multi-user license? You do NOT need to set up or administer a license server. Everything “just works” after your installation.

o Equal Rights Under Law: Pin your Win32, Win64, and .NET apps directly to the Windows 10 Start Menu/Taskbar! Enjoy equal rights for your Native Apps vs. Universal Windows apps.

o System Membership: Your MSI files are always logo compliant, no matter how they’ve been authored. You may even submit your Desktop installers to the Windows Store.

o Get Rid of Tyranny: Join the revolution against obsolete installers worldwide! Setups are smaller and faster, AND easier to develop and debug with InstallAware.

Claim your Freedom as a setup builder with InstallAware!

Wikipedia Censors InstallAware

May 15th, 2016

InstallAware, the only alternative to InstallShield, failed to get its Wikipedia article published despite years of trying.

Even after hiring a specialist, conducting months of revisions, and ensuring that the InstallAware article has more quantity and quality of citations than InstallShield (which does have a Wikipedia article), Wikipedia editors merely wrote “You may as well give up,” as seen on

Wikipedia first claimed InstallAware was advertising on Wikipedia. Then, InstallAware‘s citations were not good enough. The final excuse? InstallAware was not “significant enough”, failing to meet Wikipedia’s notability criteria.

InstallAware‘s significance is beyond question:

100,000+ strong user base.

12+ years in the business.

Most Advanced Installer Technology: Prompting multiple hostile takeover attempts and parasitic SEO attacks.

Faster, Smaller, More Stable Installers than InstallShield: Also a more robust build environment as illustrated in a recent acid test ( … taller.htm).

More Secure than InstallShield: Never opened up end-user systems to attack vectors, or adversely affected by Windows Security Updates ( … Shield.htm).

Tens of Awards: Including Microsoft’s Visual Studio Sim-Ship Award, ComponentSource’s Top Product and Top Publisher Awards, Visual Studio Magazine’s Reader’s Choice Awards, SD Times’s “Leader of the Software Development Industry” Awards, and the Windows IT Pro Community Award, among other recognition from the press, industry analysts, and most importantly, the testament of thousands of real-world software developers who have coined the term “InstallAware is the Convenience of Obviousness,” in comparing InstallAware to other Windows Installer solutions.

Wikipedia has been receiving increasing coverage in academia, where the double standards and unaccountable dispositions of Wikipedia editors have been demonstrated with scientific rigor. See, for example, … d_Decline/ and

All of us at InstallAware are deeply saddened that, as observed elsewhere ( … d=52114135), Wikipedia is out of touch with its original egalitarian ideals, serving as a source of disinformation for interests outside of itself.

The obstinacy of Wikipedians are even driving their own ranks to suicide:

New InstallAware Virtualization 6

May 1st, 2016

Innovation is relentless at InstallAware. We’re launching InstallAware Virtualization 6 on Friday this week, more than three years in the making:

Brand New IDE: Built from the ground up, the new InstallAware Virtualization 6 IDE is easier, faster, and more resilient than before.

Windows 10 Support: The InstallAware Virtualization 6 engine now produces bullet-proof virtualized apps for Windows 10.

Bug Fixes: Stability is key with application virtualization! Three years and tens of fixes bring you the most stable app virtualization.

Compressed Apps: You’ve asked and we’ve delivered! Compress your virtual apps and save time and space during publishing.

Splash Screen: Show a splash screen while your virtualized apps are loading, closing on a pre-set timeout interval or when your app is ready.

InstallAware X4 Support: Import the latest version InstallAware projects, and build them as virtual apps in a single click.

Virtualize Any App: You don’t even need setup sources to virtualize an app. Simply run the app installer through our sequencer, and you’re set!

InstallAware Virtualization 6‘s agentless architecture is the easiest way to virtualize any type of app for Windows today.

You could even combine InstallAware Virtualization with InstallAware X4‘s Windows Store Bridge to get your virtualized apps in the Windows Store!

InstallAware X4 Brings You Tomorrow!

April 17th, 2016

InstallAware X4 brings you tomorrow, without throwing away today:

1) Windows Store Bridge: InstallAware X4 has been the first to launch with a live, fully functional Windows Store Bridge that gets Desktop app installers in the Windows 10 Store, today; with full elevation and privileges.

2) Social Networking: InstallAware X4 has also been the first to launch with social networking plug-ins; making posts to Twitter and Facebook an optional or mandatory part of your installation.

3) SHA256: Microsoft has made it clear that installers must support SHA256 code signing; with double signing required in places. InstallAware X4 single, double, or null signs your files in automatic compliance.

4) Script Functions: InstallAware X4 is the first ever InstallAware release to allow for construction of script functions, using the enhanced Include Script and brand new Return from Include Script commands.

5) Teamwork: InstallAware X4 now integrates with Team Foundation Server 2015 Update 1, enabling global collaboration with seamless source-control integration directly inside the InstallAware X4 IDE.

New InstallAware X4 with Windows Store Bridge, Social Plug-Ins

April 3rd, 2016

InstallAware X4 is launching on Friday this week, following the conclusion of a nine month intensive R&D cycle and crowning InstallAware‘s 12th year in the business:

Windows Store Bridge: Get your Win32, Win64, and .NET apps in the Windows Store TODAY – including elevation, admin level wizardry, and full system access. Microsoft underwhelmed us a bit at Build 2016 with their progress on Project Centennial and its limitations – so skip the wait and get all your native and managed applications in the Windows Store today.

Social Plug-Ins: Tweet to Twitter and Share on Facebook at any point during your installation. InstallAware X4 automatically invokes REST APIs to authenticate your end-users on their social networks, and then completes postings on their behalf. You may even make postings mandatory before allowing your end-users to proceed.

SHA 256 Code Signing: We’ve solved Microsoft’s code signing riddles for 2016 and beyond. InstallAware X4 analyzes your files for existing signatures, their type, size, and the underlying operating system powering your build platform. Based on this information, it selects the Microsoft compliant code signing strategy, automatically.

Team Foundation Server 2015: InstallAware X4 now integrates with Team Foundation Server 2015 Update 1, enabling globally distributed project collaboration.

IDE Zoom: Zoom in and out of your script with eagle eyes to find exactly what you are looking for. Comes with quick previews to find your ideal zoom level, too!

Updated Theme Assets: Both the IDE and the setup engine have been updated with the latest Windows 10 graphic assets, ensuring a smoother look for your setups.

Script Functions: Every InstallAware programmer’s dream is here. Using the new Return from Include Script command and the enhanced Include Script command, its a snap to build your own script functions – with their own custom return values.

Get your apps in the Windows Store today, go social with your installers, and attain 100% standards compliance with InstallAware X4.

How to Comply With Microsoft’s New Code Signing Policy Using InstallAware X3’s New Build Events

February 8th, 2016

In this tutorial we are going to show you how to make your installer packages conform with Microsoft’s new code signing policy. The “Windows Enforcement of Authenticode Code Signing and Timestamping” is effective as of January 1, 2016. This new policy basically mandates the deprecation of SHA-1 code signing certificates, time stamps, and file hashes for Code Signing. The new Microsoft Policy involves SHA-2 code signing certificates, time stamps, and file hashes as part of the updated policy:

Fortunately this can be easily achieved following the few steps described with this tutorial. This is entirely based on the use of the new “Build Events” feature available with InstallAware X3.

The “Build Events” feature makes it possible to run any third party process as an integral part of a build process. A “Process” is any executable and may be invoked during the various stages of a build that InstallAware follows while packaging your apps.

In this tutorial, we will not be boring you with the details of the new Code Signing Policy. If you are interested in resolving the overt contradictions in the Microsoft documentation and fancy that sort of a wild goose chase, please enjoy the official Microsoft documentation linked above. Having suffered through the nitty gritty details at InstallAware HQ on your behalf, we will be sparing you this pain; and focus on just the steps necessary to comply with the new Code Signing Policy in order to let you to build trusted setup packages.

Let us start with an overview of the setup binaries produced by a build which need code signing. These are of course, the MSI and/or EXE binaries that comprise your setup files. Please note that if you are setting the NO_MSI compiler variable to TRUE – meaning that you are opting to build a pure Native Engine installation, without any Windows Installer (MSI) bloat – in that case, you may omit the steps for the MSI files below. Similarly, when you are building a pure Windows Installer target (no final EXE output), you may omit the steps for EXE files.

These are in summary the targets that need to comply with the new Code Signing Policy. We may now proceed to the implementation using InstallAware X3.


Requirements for This Tutorial

•     InstallAware version X3,

•     An SHA-2 code signing certificate,

•     A recent version of the Microsoft SignTool.exe that supports double signing. This tool is included with the Windows 8 SDK, Windows 8.1 SDK and Windows 10 SDK.

Once the SDK is installed, the SignTool.exe binary is generally found inside one of the following directories:

  • C:\Program Files (x86)\Windows Kits\8.0\bin\x86
  • C:\Program Files (x86)\Windows Kits\8.1\bin\x86
  • C:\Program Files (x86)\Windows Kits\10\bin\x86


Getting Started

Make sure the “Sign the package with Authenticode” checkbox in the Build | Authenticode page of your Project Options window is UNCHECKED. This step is necessary since we are replacing the default code signing process in InstallAware X3.


Defining Build Events to Sign an Uncompressed Build Layout

With this kind of build its necessary to apply the digital signature to the following files which are part of an uncompressed build layout for a setup package (such as, for a DVD/Blu-Ray distribution target). These are stored at build time under your project’s “uncompressed” output folder.

•     <PackageName>.exe

•     <PackageName>.msi

•     \data\<PackageName>.msi

1. In the Project Options dialog (“CTRL+SHIFT+F11”) select the “Post-Build” event node listed within the left tree pane control. Then in the Commands field enter the following command line sequence.

- “#IADIR#\authenticode\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Uncompressed\#TITLE#.msi”

- “#IADIR#\authenticode\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Uncompressed\Data\#TITLE#.msi”

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Uncompressed\#TITLE#.exe”

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /as /fd sha256 /tr <SHA256_timestamp_url> /td sha256 /p <cert_password> “#PROJDIR#\Release\Uncompressed\#TITLE#.exe”


a) Press CTRL+ENTER to start a new command line. Each new line above represents a new command line and a new process invocation.

b) Ensure to update paths to the folder where the SignTool.exe binary is actually located on your system. In the above example, a typical path for the Windows 10 SDK on a 64-bit operating system has been used.

c) You will need to replace these tokens with your actual desired targets:

<SHA256_timestamp_url>: Replace with the actual time stamp server URL to use, for example

<cert_password>: Replace with your code signing certificate password (we better not know what that is, right?)

<SHA2_cert>: Enter the full path to your code signing certificate file here. Ensure to enclose the entire path string inside double quotes (“”) if the path to your code signing certificate contains spaces. Those adventurous among you may also opt to use the short path name for the certificate, if you are averse to using paths with spaces in them (even when they have been double-quoted).

Notice how, in the above command line sequence, we have refrained from hard-coding any folder paths and file names, insofar as your project folder and setup name is concerned. The examples above make use of the pre-defined compiler variables #PROJECTDIR#, #IADIR# and #TITLE#, instead of hard-coding folder paths and file names. These compiler variables are automatically resolved to their final values during the build process. This helps you use the exact same commands across all of your setup projects; without having to engage in the laborious task of updating paths and file names across projects, and/or having to update them when you actually move project folders around/change setup names.

2. In the Post-Build event settings, you may want to check the “Abort build on error (if any command returns non-zero result)” checkbox. Checking this box fails the setup build process when any invoked application returns a non-zero error code as its exit code, which is typically how an error condition is indicated on the command line. You may also want to keep this box unchecked, if you don’t care to break your build process when an intermittent failure occurs with a code signing time stamp server (or if it is not otherwise critical for your code signing to succeed).

3. Finally in the Project Options dialog, select the OK button to confirm the Post-Build event settings. Then rebuild the project. You’re done!

Defining Build Events to Sign a Compressed, Web, or Patch Build Layout

With all other build targets, including a Single Compressed File (monolithic) installer, a Web Build (main setup file plus optional web media block files), or a Patch Build; we need to define either a Post-Compress Event (if your final build target is an EXE file) or a Post-Wrap event (if your final build target is an MSI file).

Note that you could also “nest” your signatures all the way in, if you wanted to. Since any compressed setup is ultimately composed of files found in an uncompressed layout (which are then packaged into a single [or a few, in the case of a web build’s web media block files] file), there’s no harm in signing all those source materials as well.

While Windows will obviously not display any additional elevation requests once you have already elevated the main entry point of your setup package, you may want to use this trick of nested package signing for reasons of improving your chances of preventing false positives with anti-virus software. Anti-viruses have indeed become a cure worse from the disease, often hindering legitimate setups from installation. It may help your installation success rates to sign your packages from top to bottom (although, to set your expectations right; some anti-virus vendors have gotten so aggressive, that your mileage may vary even with everything signed inside out).

So if you want to do the nesting, copy over/retain the Post-Build event instructions for Uncompressed Builds to your compressed build types as well. Of course, remember to replace the string “uncompressed” with the string “single”, “web”, or “patch” based on your new distribution target.

Again while nesting, when building a single MSI file target, retain the Post-Compress event instructions (normally, you would only need to implement the Post-Wrap event instructions).


So here are the Post-Compress build events for a Single File Compressed Build:

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Single\#TITLE#.exe”

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /as /fd sha256 /tr <SHA256_timestamp_url> /td sha256 /p <cert_password> “#PROJDIR#\Release\Single\#TITLE#.exe”

Here are the Post-Compress build events for a Web Compressed Build:

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Web\#TITLE#.exe”

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /as /fd sha256 /tr <SHA256_timestamp_url> /td sha256 /p <cert_password> “#PROJDIR#\Release\Web\#TITLE#.exe”

And finally, the Post-Compress build events for a Patch:

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Patch\#TITLE#.exe”

- “C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe” sign /f <SHA2_cert> /as /fd sha256 /tr <SHA256_timestamp_url> /td sha256 /p <cert_password> “#PROJDIR#\Release\Patch\#TITLE#.exe”


Now, if you are producing an MSI output instead of an EXE output, use the following build events instead. Of course, if you will be doing nested signing, then remember to retain the above Post-Compress build events as well.

For a Single File MSI Build, use these Post-Wrap build events:

- “#IADIR#\authenticode\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Single\#TITLE#.msi”

For a Web MSI Build, use these Post-Wrap build events:

- “#IADIR#\authenticode\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Web\#TITLE#.msi”

For a Patch MSI Build, use these Post-Wrap build events:

- “#IADIR#\authenticode\SignTool.exe” sign /f <SHA2_cert> /t <SHA1_timestamp_url> /p <cert_password> “#PROJDIR#\Release\Patch\#TITLE#.msi”




That’s it!

You’ve seen how easy and versatile it can be to use InstallAware X3’s new Build Events to extend the default build process in the IDE and across the entire InstallAware build toolchain.

Please feel free to use this mechanism to do anything special you like when building your own installers. Have fun!


Francesco Toscano
Your InstallAware™ Support Team.