Store And Signing
For most new public WinUI 3 apps in this lab, use Microsoft Store MSIX. The owner already has a Store account, and Store MSIX avoids most public code-signing infrastructure.
Distribution And Signing Matrix
| Path | Signing burden | Updates | Good for |
|---|---|---|---|
| Microsoft Store MSIX | Store re-signs after certification | Store-managed | New public WinUI apps |
| Microsoft Store MSI/EXE | Publisher signs installer and PE files | App/installer handles updates | Existing installer apps |
| MSIX sideload enterprise | Enterprise-trusted cert or Azure Artifact Signing | MDM/App Installer path | Managed devices |
| MSIX direct download | CA-trusted signing expected | .appinstaller or custom | ISVs outside Store |
| Unpackaged EXE/zip | Signing recommended for SmartScreen | Manual | Internal tools and developer utilities |
Store MSIX Dry Run
1. Reserve or confirm app identity.
2. Build the Store package artifact.
3. Run Windows App Certification Kit.
4. Prepare screenshots, logos, age ratings, privacy policy, support info, and certification notes.
5. Confirm restricted capabilities and declarations.
6. Upload package only when the user explicitly asks for authenticated Partner Center work.Privacy Policy Trigger
If the app collects or transmits personal information, prepare a privacy policy URL before Store submission. Do not wait until the upload screen blocks you.
Signing Rules
- Store MSIX: no CA-trusted cert purchase needed for the submitted package because the Store re-signs it after certification.
- Store MSI/EXE: publisher signs the installer and relevant binaries.
- Non-Store MSIX: publisher signs the package.
- Self-signed: local testing or managed enterprise trust only.
- Never commit signing material.
Gotcha: A Store account lowers friction, but it does not prove certification, listing completeness, restricted capability approval, or release readiness.