Send a Windows app to testers: .msix, .msi and SmartScreen

Getting a Windows build to testers is mostly about two things: the package format and the signature. Windows treats files downloaded from the internet with suspicion, and what a tester sees depends on both. This guide covers signing, MSIX and App Installer, .msi packages, the SmartScreen and unsigned package messages, and how to share the build with a link.

Signing comes first

Windows packages are signed with a code signing certificate, usually with signtool sign from the Windows SDK. The certificate can come from a public certificate authority, from Microsoft's own cloud signing service, or, for internal testing, from your company's own certificate authority or a self signed certificate.

• A certificate from a public authority is trusted by every Windows PC.
• A self signed or company certificate is only trusted on PCs where it was installed. For an .msix, the tester (or IT) adds it to the Trusted People store of the local machine before installing, which needs admin rights.
• Whatever you use, time stamp the signature so it stays valid after the certificate expires.

.msix and App Installer

MSIX is Windows' modern package format. It installs cleanly, uninstalls cleanly and can update in place. Every .msix must be signed, and the Publisher in the package manifest must match the subject of the signing certificate exactly, or signing fails.

• Sideloading (installing outside the Microsoft Store) is on by default on current Windows 10 and Windows 11.
• App Installer opens .msix and .msixbundle files when the tester double clicks them, shows the publisher and capabilities, and installs.
• Microsoft turned off the ms-appinstaller: web protocol by default after it was abused, so a link that installs directly from the browser no longer works on most PCs. Testers download the file, then open it.
• An .msix that is unsigned, or signed with a certificate the PC does not trust, will not install. App Installer tells the tester to ask the developer for a new app package because it is not signed with a trusted certificate.

.appx and .appxbundle are the older form of the same thing and behave the same way.

.msi packages

An .msi is a Windows Installer package: familiar to IT teams, good for apps that need drivers, services or per machine settings. It does not have to be signed to run, but an unsigned .msi shows "Unknown publisher" in the admin prompt, and SmartScreen is much more likely to stop it. Sign it with the same signtool and certificate.

SmartScreen and other messages

• "Windows protected your PC": Microsoft Defender SmartScreen stopped a downloaded file it does not recognize. The tester clicks More info, checks the publisher, then Run anyway. Signed files build reputation as more people run them; a new certificate or a rarely downloaded file can still show the message for a while, so warn testers in the release notes.
• Smart App Control on Windows 11 can block unsigned or unknown apps outright, with no Run anyway button. Signed packages are the way through.
• Admin prompts: a per machine .msi asks for admin rights. Testers on managed company PCs may need IT to approve it.

Signing does not guarantee that SmartScreen stays quiet, but an unsigned package will almost always meet a warning.

A short checklist before you send the link

1. The package is signed, the signature is time stamped, and for an .msix the manifest Publisher matches the certificate.
2. If the certificate is self signed or from your company, testers have it installed, or IT has pushed it to their PCs.
3. The version number went up since the last build, so an .msix updates in place instead of failing.
4. The release notes say which messages testers may see and what to click.
5. You tried the download on a clean PC or a fresh user account, not only on the machine that built it.

Why AppForShare takes no .exe

AppForShare accepts .msix, .msixbundle, .appx, .appxbundle and .msi files, and refuses .exe uploads with a hint to package the app as .msix or .msi. A package carries its name, publisher and version in a form the page can read and show to testers. A bare .exe can be anything, and it is the file type most often abused on file links. AppForShare is for app builds, not general file sharing.

Sharing the build on AppForShare

On Pro and Team, desktop builds upload the same ways as mobile builds: the web, the CLI, CI or an AI tool through MCP. You get the same link, QR code, release notes, channels, password, link controls and install analytics. On a computer the page shows a download button, the size and the SHA-256; a phone that opens the link is told to open it on a Windows computer.

The page also lists what AppForShare read from the package on its own servers: package name, publisher, version, and whether a signature is present. An unsigned package gets a signing check line on the build page so you notice before testers do. Every desktop file goes through the malware check, like mobile builds.

AppForShare does not sign your package, and it cannot promise that SmartScreen or App Installer will accept it on a given PC; that depends on your certificate and the tester's settings.

Common questions

Can I share an .exe installer?

Not on AppForShare. Package it as .msix or .msi first; most installer tools can produce one.

Do testers need a Microsoft account?

No. They download the file from the link and open it.

Which plan takes Windows builds?

Pro and Team, with files up to 2 GB on Pro and 4 GB on Team.

More: desktop builds and the desktop builds docs. Shipping a Mac app too? See send a Mac app to testers.