How to create a Windows installer for your app

What does a Windows installer actually do?

A Windows installer takes the folder your build produces and turns it into a working program on someone else’s PC. At minimum it copies the files to a sensible folder, creates shortcuts, registers an entry in Apps & features so the user can remove it, and leaves a way to install the next version over the current one.

Most developers underestimate the list. Here is what users and Windows expect from a decent setup program:

• Copy the files to a stable location. A per-user install goes under the user’s local app data folder and needs no administrator prompt. A machine-wide install goes under Program Files and needs elevation.
• Create shortcuts in the Start menu, and on the desktop if the user wants one.
• Register an uninstall entry under the Windows uninstall registry key, with a display name, an icon and the command that removes the app.
• Remove cleanly. Uninstall should delete what the installer wrote, its shortcuts and any start-up entry, and nothing the user created.
• Start the app when installation finishes, if that is what the user expects.
• Provide an upgrade path. Version two has to install over version one without leaving stale files or a second copy behind.

The last point is the one that hurts later. An installer that only knows how to do a fresh install leaves you with a support problem the day you ship a fix.

What are the usual ways to build a Windows installer?

There are four common routes. Script-based installer builders compile a setup.exe from a script you write. Windows Installer (MSI) toolsets produce a database-driven package that IT departments know how to deploy. MSIX is the newer packaged format. Many app frameworks ship their own packager that wraps one of these.

None of these is wrong. The choice depends on who installs your app (individual users or an IT department), how much control you want over the screens, and how much time you are willing to spend on packaging rather than on the app.

Why is an installer alone not enough?

An installer gets version one onto the PC. Every later version has to get there too, and users rarely download a new setup file on their own. Without an update mechanism, most of your users stay on whatever they first installed, including its bugs.

So teams that start with an installer usually end up building a second system: a server that knows the latest version, a client that asks it, a way to download and replace files safely, and a way to prove the files came from you. That second system is often more work than the installer. The auto-update guide walks through it step by step, and desktop app update strategies compares the common approaches.

If you plan both from the start, the installer and the updater can share one code path: the first install is simply the first update. That removes a whole class of "works on a fresh install, breaks on upgrade" bugs.

Do you need a code-signing certificate?

Not to make an installer work, but you need one to avoid warnings. Windows SmartScreen shows "Windows protected your PC" for downloaded programs it has no reputation for, and unsigned programs get that warning most often. A code-signing certificate from a certificate authority ties the file to your name and lets reputation build over time.

Certificates cost money and take identity checks, so many developers ship unsigned at first and tell early users to choose More info, then Run anyway. The trade-offs are covered in the SmartScreen "Unknown publisher" guide.

How to create a Windows installer with Omnihorn

Omnihorn builds the installer and the updater as one product. You upload the folder your build produces, design the install window in Installer Studio, and press Build installer. You get a single setup.exe that installs your app and keeps it updated. You do not write an installer script, and you do not need a certificate to start.

1. 1

   Create an account and an app

   Sign in at /login with your email; the same link signs you up. Choose New app and give it a name. Omnihorn creates the app’s signing keys, a production channel and a default installer design right away.

2. 2

   Upload your build folder

   On the app’s Builds tab choose New build and drop the folder that runs on a clean PC: the .exe plus its DLLs and data files. A .zip, .7z, .rar or .tar archive of it works too. Enter a version such as 1.0.0. Details are in Upload builds.

3. 3

   Check the channel points at the build

   Once the build shows active, open the Channels tab. A build reaches users only when a channel points at it. The new-app wizard assigns your first build to production; for later builds, open the channel and use Assign build.

4. 4

   Design the window in Installer Studio

   Open the Installer tab and edit the design: colours, corners and background, what starts after installation (pick your .exe, or leave it on automatic), and whether to offer Start menu and desktop shortcuts and starting with Windows. See Installer Studio.

5. 5

   Press Build installer

   Press Build installer (or Create installer for a channel that has never had one). The row shows the progress and becomes Ready when setup.exe is built.

6. 6

   Download setup.exe and try it

   Download the installer from the row; for a public channel you can also share its download page. Run it on a Windows PC. Without a certificate the row says Unsigned, and SmartScreen warns; choose More info, then Run anyway.

What the generated setup.exe does on a user’s PC

The download is one standalone file with nothing to unzip. When the user runs it, it installs per user under the local app data folder, with no administrator prompt. Your app’s files are not packed inside the installer. It fetches them from Omnihorn, verifies each one against the signed manifest, and then applies them.

• It adds an entry to Apps & features, so Windows’ own uninstall works.
• It creates the Start menu and desktop shortcuts the user agreed to, plus a Start menu entry that opens the updater window.
• It registers a small start-up check that looks for updates once per Windows start-up, so later versions arrive without a new download. See Updates on user machines.
• It starts the program you chose as the launch target.
• Uninstall removes the files the installer wrote, its shortcuts and its start-up entry, and leaves other files in the folder alone.

Because your files are fetched at install time, you do not rebuild the installer for every release. Upload a new build, point the channel at it, and both new installs and existing copies get it. Rebuild the installer when you change its design.

Installer checklist before you ship

1. Install on a clean Windows PC or virtual machine that has never had your app or its runtime dependencies.
2. Confirm the app starts from the Start menu shortcut, not only from the installer’s last screen.
3. Install version two over version one and check that nothing from version one is left behind.
4. Uninstall from Apps & features and check the folder, shortcuts and start-up entries are gone.
5. Read the SmartScreen prompt your users will see, and decide whether you need a certificate yet.
6. Write down where the installer puts files, for the support questions that will come.

If you need screens or steps Installer Studio does not offer, there is a custom installer service. Plans and limits are on the pricing page; there is a free plan. To get going, follow the quickstart.