Shipping a Windows app safely takes three things: an installer that fits your users (MSI, MSIX or EXE), a code signature made with a trusted certificate and an auto-update mechanism that verifies every file it downloads. Miss one of them and users either hit a security warning or get stuck on an old version.
Writing the app is half the job. Getting it onto users' computers smoothly and keeping it current for years is the other half. That is why, on desktop app development projects, we set up the release pipeline before the first version ships. This article covers installer formats, code signing, SmartScreen, update channels and the Microsoft Store, in that order.
MSI, MSIX or EXE: which installer format should you choose?
Windows has three common installer formats, and each serves a different audience best:
- MSI: the Windows Installer package format. Installation steps are defined in a database inside the package, and the installation rolls back if something fails. Corporate IT teams like MSI because silent, large-scale deployment is easy with tools such as Group Policy and Microsoft Intune. WiX Toolset is a widely used open-source tool for building MSI packages.
- MSIX: Microsoft's modern package format. The app installs in an isolated structure, leaves nothing behind when removed and downloads only the changed parts on updates. Packages must be signed. Some deep system work, such as installing drivers, falls outside what MSIX allows.
- EXE setup wizard: the classic installer built with tools such as Inno Setup or NSIS. It is the most flexible option: it can install prerequisites, offer a language choice and add custom steps. The price of that flexibility is that getting install and uninstall right is entirely up to you.
- Portable version: a build shipped in a compressed folder that needs no installation. It is handy for quick trials, but updating and removing it are left entirely to the user.
Install scope matters too. A per-machine install writes to Program Files and needs administrator rights. A per-user install writes to the user's own profile folder and does not. Per-user installs are more common for tools aimed at individuals, per-machine installs in corporate environments.
If you have corporate customers, document the silent install options; for MSI, that is the /quiet switch of the msiexec command. Make sure uninstalling also cleans up settings and temporary files.
What is code signing and why do you need it?
Code signing adds a digital signature to your app's files that proves who published them and shows they have not been changed since signing. Windows verifies this signature through Authenticode. With a signed installer, the permission prompt shows your company's name instead of "Unknown publisher."
- Certificate: a code signing certificate comes from a recognized certificate authority, which verifies your company's identity. There are organization validation (OV) and extended validation (EV) types.
- Private key: industry rules now require the certificate's private key to live on hardware, either a USB token or a cloud-based hardware security module (HSM). Plan for this early when you connect signing to your build pipeline.
- Timestamp: sign with a timestamp server. That way, files signed before the certificate expires stay valid after it does.
- What to sign: not just the installer, but the app's own EXE and DLL files too. Security software and corporate policies may inspect each file separately.
Wiring signing into the build and release pipeline, rather than signing by hand, reduces both mistakes and the risk of the key ending up in the wrong hands. We cover the principles of an automated pipeline in DevOps Without the Drama.
Why does the SmartScreen warning appear, and how is reputation built?
Microsoft Defender SmartScreen shows a "Windows protected your PC" warning for files downloaded from the internet that it does not yet recognize. Users can continue through More info and then Run anyway, but many give up at this point.
- SmartScreen decides based on the reputation a file and its signing certificate build up over time. Unsigned files cannot build that reputation.
- A warning on the first release with a new certificate or a new product is normal. It fades as downloads grow and time passes.
- How much the certificate type affects reputation depends on Microsoft's policy, which can change over time. Check the current situation before you buy a certificate.
- On Windows 11 devices with Smart App Control turned on, unsigned and unrecognized apps can be blocked outright.
Be upfront with users: note on the download page that early versions may show a warning, and show how to proceed. That keeps the warning from turning into a trust problem.
How do you build auto-updates safely?
A safe update flow usually has these five steps. Off-the-shelf update libraries handle most of them for you, but check that each step actually happens.
- Get version information from a trusted source. At startup or at set intervals, the app checks a version file over HTTPS. That file lists the latest version number, the download URL, the file hash and the release notes.
- Download in the background. Do not interrupt the user's work, and resume the download if the connection drops.
- Verify integrity. Compute a hash of the downloaded file, such as SHA-256 or SHA-512, and compare it with the value in the version file. Then check the file's code signature and confirm the signer is your certificate. The hash shows the file arrived intact; the signature shows it came from you.
- Install at the right moment. Do not close the app while the user is working. Install when the app exits or on the next launch.
- Leave a way back. If a new version will not start, you should be able to return to the previous one. At the very least, keep older installers available.
Our own Next Notify follows this pattern: it downloads the new version in the background, verifies its SHA-512 hash and installs it quietly when the settings window closes.
How should you manage update channels?
Sending every new version to everyone at once means a bug also reaches everyone at once. Channels and staged rollouts reduce that risk:
- Stable and beta channels: open new features to volunteers or your internal team first, then move them to stable if nothing breaks.
- Staged rollout: offer the new version to a small share of users first, watch error and crash reports, then widen the share.
- Mandatory updates: mark versions that fix security holes as non-deferrable, and let users postpone the rest.
- Release notes: describe what changed in each version, briefly and clearly. Users trust an update more when they know what it does.
- Version numbering: use a meaningful versioning scheme. Knowing which user is on which version speeds up support.
Is the Microsoft Store an option?
Yes, especially for apps aimed at individual users. The Microsoft Store now accepts classic MSI and EXE installers as well as MSIX packages.
- MSIX packages distributed through the Store are signed by Microsoft. You do not need your own code signing certificate, and users do not see a SmartScreen warning.
- For MSIX packages, the Store delivers updates. For MSI and EXE submissions, the installer stays on your server, you manage updates yourself and those files are expected to be signed.
- Being searchable in the Store helps discovery. In corporate environments, though, Store access may be blocked by policy.
- Every submission goes through a certification review, so plan your release schedule around it.
- Prepare the store listing details, such as the description, screenshots and age rating, in advance.
Besides the Store, the Windows Package Manager (winget) is a distribution channel that developers and IT teams use often. Your choice of framework also affects your distribution tools; we compare the options in Electron, Tauri or .NET.
Users never see your code; they see the installer, the warning and the update.
Frequently asked questions
Can you ship an app without a code signing certificate?
Technically, yes. But users will see a SmartScreen warning, devices with Smart App Control may block the app and many corporate policies do not allow unsigned software. For a serious product, signing is effectively mandatory.
Which is better: EXE, MSI or MSIX?
It depends on your audience. MSI stands out for corporate deployment, MSIX for clean installs and the Store, and EXE for maximum flexibility. Some products offer more than one format.
Should users be able to turn off auto-updates?
Offering a postpone option is good practice for individual tools, but security updates should not be deferrable. In corporate environments, IT teams usually want to control update timing.
Is hash verification enough on its own?
No. A hash shows the file was not corrupted in transit, but if the hash and the file come from the same server, both can be swapped together. Use hash verification together with a code signature check.
Where to start?
First, define your user: an individual, a corporate IT team or both? That answer largely decides the installer format, the signing needs and the update policy. Then, before the first release, run the signing and update pipeline end to end with a small test version. Your short checklist: a signed installer, signed app files, a timestamp, updates verified by hash and signature, and a working way back.
If you want to set up the installer, signing and update pipeline for your Windows app together, get in touch.