Skip to content

Commit 8f8da71

Browse files
GrantMeStrengthCopilot
GrantMeStrength
and
Copilot
authored
P1: Add distribution path decision, SmartScreen explainer, and feature status pages (#6651)
* P1: Add distribution path decision page, SmartScreen explainer, and feature status page - choose-distribution-path.md: Store-first persona-scoped decision matrix - smartscreen-reputation.md: Hash-based reputation, EV cert changes 2024, Azure Trusted Signing - distribution-feature-status.md: ms-appinstaller disabled, .appinstaller schema, SmartScreen EV changes, Win10 vs Win11 MSIX gaps - toc.yml: Wire all three new pages into package-and-deploy TOC Part of ADO #570426 (Windows app distribution docs gap) Co-authored-by: Copilot <[email protected]> * Fix punctuation in choose-distribution-path.md * Remove warning icons from status messages * Fix build warnings and address Copilot feedback in P1 pages Build fixes: - distribution-feature-status.md: remove 'en-us' locale from learn.microsoft.com link - choose-distribution-path.md: fix broken link app-certification-requirements → app-package-requirements - choose-distribution-path.md: fix broken MSIX publish index link → create-app-submission Copilot feedback: - smartscreen-reputation.md: unsigned/self-signed rows: 'hard block' → accurate description with bypass path ('More info → Run anyway'); enterprise policy caveat added - smartscreen-reputation.md: bullet list: clarify unsigned warning vs block distinction; clarify that cert identity affects publisher trust signal (not file hash reputation) Co-authored-by: Copilot <[email protected]> * Update package-and-deploy index to surface new P1 distribution pages Add links to choose-distribution-path.md and distribution-feature-status.md in the overview prose so the new content is discoverable from the hub page. Co-authored-by: Copilot <[email protected]> * Address Copilot feedback and build suggestions in P1 pages smartscreen-reputation.md: - Table: rephrase unsigned/self-signed row to neutral description; avoid instructing users to bypass security prompts - Bullet: 'safe to proceed' → 'verify publisher and trust the source' choose-distribution-path.md: - Rename 'Store-eligible' column to 'Distributed via Store' — MSIX is always the Store-accepted format; the column intent was whether this path uses the Store distribution-feature-status.md: - Remove absolute learn.microsoft.com Q&A link (docs-link-absolute suggestion); internal App Installer security features link is more authoritative Co-authored-by: Copilot <[email protected]> * Address Copilot feedback: Store for Business retired, OV cert SmartScreen wording choose-distribution-path.md: - Store MDM column: 'Intune/Store for Business' → 'Intune with Company Portal' (Microsoft Store for Business was retired March 2023) smartscreen-reputation.md: - OV cert table row: 'Unknown publisher' → 'app flagged as unrecognized'; OV certs display publisher name as verified — 'unknown publisher' is a different SmartScreen state for unsigned/untrusted files - First-download numbered step: same correction; signed app prompt shows publisher name with low-reputation warning, not 'unknown publisher' Co-authored-by: Copilot <[email protected]> --------- Co-authored-by: Copilot <[email protected]>
1 parent 7c0b061 commit 8f8da71

5 files changed

Lines changed: 350 additions & 0 deletions

File tree

‎hub/apps/package-and-deploy/choose-distribution-path.md‎

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
title: Choose a distribution path for your Windows app
3+
description: Compare the available Windows app distribution paths — Microsoft Store, MSIX sideloading, and direct download — to find the right fit for your app and audience.
4+
ms.topic: concept-article
5+
ms.date: 04/17/2026
6+
ms.localizationpriority: medium
7+
---
8+
9+
# Choose a distribution path for your Windows app
10+
11+
How you distribute your Windows app affects code signing costs, update mechanics, enterprise manageability, and how easily customers discover and install it. This article compares the main paths to help you make the right choice.
12+
13+
> [!TIP]
14+
> **For most developers, the Microsoft Store is the recommended path.** It provides free code signing, built-in update delivery, broad discoverability, and a trusted install experience — with no infrastructure to manage.
15+
16+
## Distribution paths at a glance
17+
18+
| Path | Best for | Code signing cost | Auto-update | Enterprise MDM | Distributed via Store |
19+
|---|---|---|---|---|---|
20+
| **Microsoft Store** | Consumer and business apps, broad reach | ✅ Free (Store signs for you) | ✅ Built-in | ✅ Via Intune with Company Portal | ✅ Yes |
21+
| **MSIX sideload (enterprise)** | Internal LOB apps via Intune/ConfigMgr | 💲 Azure Trusted Signing (~$10/mo) or self-signed + Intune cert profile | ✅ Via App Installer file or MDM | ✅ Native | ❌ No |
22+
| **MSIX direct download (ISV)** | Commercial apps sold from your own site | 💲 CA-trusted cert required ([Azure Trusted Signing](/azure/trusted-signing/) recommended) | ✅ Via `.appinstaller` file | ⚠️ Limited | ❌ No |
23+
| **Packaging with external location** | Existing apps with own installer needing Windows features | 💲 Same as MSIX direct download | ✅ Your existing mechanism | ⚠️ Limited | ❌ No |
24+
25+
## Microsoft Store (recommended)
26+
27+
Publishing to the Microsoft Store is the most complete distribution solution for Windows apps.
28+
29+
**What you get:**
30+
- Code signing handled automatically — no certificate purchase needed
31+
- Built-in update delivery with staged rollout support
32+
- Discovery through the Store's search and curated collections
33+
- Trusted install UX with no SmartScreen warnings
34+
- Revenue processing, refunds, and analytics included
35+
36+
**Requirements:**
37+
- App must be packaged as MSIX (WinUI 3 apps are packaged by default)
38+
- App must pass [Store certification requirements](/windows/apps/publish/publish-your-app/msix/app-package-requirements)
39+
- Developer account required ([Partner Center](https://partner.microsoft.com/dashboard))
40+
41+
**When to choose this:**
42+
- Your app targets consumers or business users broadly
43+
- You want the simplest possible distribution infrastructure
44+
- You're building a new WinUI 3 app (you're already packaged — just submit)
45+
46+
→ [Publish to the Microsoft Store](/windows/apps/publish/publish-your-app/msix/create-app-submission)
47+
48+
## MSIX sideloading — enterprise LOB distribution
49+
50+
For internal line-of-business apps that will be deployed to managed devices via Microsoft Intune or Configuration Manager, MSIX sideloading is the recommended path.
51+
52+
**What you get:**
53+
- Silent install and update via MDM policies
54+
- Integration with enterprise device management (Intune, ConfigMgr)
55+
- Full package identity and access to Windows features (notifications, background tasks, etc.)
56+
57+
**Code signing:**
58+
- Use [Azure Trusted Signing](/azure/trusted-signing/) (~$10/month) for a CA-trusted certificate, or
59+
- Use a self-signed certificate deployed to endpoints via Intune Trusted Certificate profiles
60+
61+
**Requirements:**
62+
- Target devices must trust the signing certificate (either via MDM or Group Policy)
63+
- Sideloading must be allowed on target devices (enabled by default on Windows 10 version 2004+ and all Windows 11 devices)
64+
65+
**When to choose this:**
66+
- Distributing an internal app to company-managed devices
67+
- You have an IT team who can configure certificate trust via Intune or Group Policy
68+
69+
→ [Deploy MSIX apps with Intune](/windows/msix/desktop/managing-your-msix-deployment-intune)
70+
→ [Deploy MSIX apps with Configuration Manager](/windows/msix/desktop/managing-your-msix-deployment-configmgr)
71+
72+
## MSIX direct download — ISV and commercial apps
73+
74+
For commercial apps sold directly from your website (not through the Store), you can distribute MSIX packages with an `.appinstaller` file for auto-update support.
75+
76+
**What you get:**
77+
- Familiar install experience via App Installer
78+
- Auto-update support via `.appinstaller` file (hosted on your server)
79+
- Full package identity and Windows feature access
80+
- Control over your own distribution channel and pricing
81+
82+
**Code signing:**
83+
- A CA-trusted code signing certificate is required — users cannot install unsigned or self-signed MSIX packages without trusting the cert manually
84+
- [Azure Trusted Signing](/azure/trusted-signing/) (~$10/month) is Microsoft's recommended option: no hardware token required, integrates with CI/CD pipelines
85+
- Traditional OV certificates are also accepted (typically $150–300/year from a CA)
86+
87+
**SmartScreen:** New certificates accumulate SmartScreen reputation over time based on download volume. Expect some SmartScreen prompts for new releases. See [SmartScreen reputation for Windows app developers](smartscreen-reputation.md).
88+
89+
> [!IMPORTANT]
90+
> The `ms-appinstaller:` URI protocol (one-click browser install) is disabled by default since December 2023. Link to the `.appinstaller` file directly for download, or consider publishing to the Store for broader reach. See [Current status of Windows app distribution features](distribution-feature-status.md).
91+
92+
**When to choose this:**
93+
- You're an ISV selling software directly from your website
94+
- You need control over installer UX, pricing, or licensing that the Store doesn't support
95+
- Your customers are businesses that procure software outside the Store
96+
97+
→ [App Installer file overview](/windows/msix/app-installer/app-installer-file-overview)
98+
→ [Auto-update and repair apps](/windows/msix/app-installer/auto-update-and-repair--overview)
99+
100+
## Packaging with external location (sparse package)
101+
102+
If you have an existing app with its own installer (WiX, NSIS, InstallShield) and want to add Windows features that require package identity - without replacing your installer with MSIX - use packaging with external location.
103+
104+
**What you get:**
105+
- Package identity without changing your installer or binary locations
106+
- Access to Windows features: notifications, background tasks, file type associations, protocol handlers
107+
- Your existing install and update mechanism stays in place
108+
109+
**What you don't get:**
110+
- Store eligibility
111+
- The clean install/uninstall model of full MSIX
112+
113+
**When to choose this:**
114+
- You have an existing Win32/WPF/WinForms app with an established installer
115+
- You want specific Windows API features that require package identity
116+
- Migrating fully to MSIX is not feasible right now
117+
118+
→ [Grant package identity by packaging with external location](../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md)
119+
120+
## What about other installer formats?
121+
122+
Many Windows apps are distributed using MSI, WiX, Inno Setup, ClickOnce, or similar technologies. These are established and supported options, especially for existing apps. However, they may not provide MSIX's package identity, clean uninstall model, or Store eligibility.
123+
124+
## Related content
125+
126+
- [Packaging overview](packaging/index.md)
127+
- [SmartScreen reputation for Windows app developers](smartscreen-reputation.md)
128+
- [Current status of Windows app distribution features](distribution-feature-status.md)
129+
- [Publish to the Microsoft Store](/windows/apps/publish/)
130+
- [Azure Trusted Signing](/azure/trusted-signing/)

‎hub/apps/package-and-deploy/distribution-feature-status.md‎

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
---
2+
title: Current status of Windows app distribution features
3+
description: Up-to-date status of Windows app distribution features, including ms-appinstaller protocol status, .appinstaller schema versions, and platform support differences between Windows 10 and Windows 11.
4+
ms.topic: concept-article
5+
ms.date: 04/17/2026
6+
ms.localizationpriority: medium
7+
---
8+
9+
# Current status of Windows app distribution features
10+
11+
This page documents the current status of Windows app distribution features that have changed, are known to have limitations, or behave differently than their documentation may suggest. It is updated as the platform evolves.
12+
13+
**Last reviewed:** April 2026
14+
15+
---
16+
17+
## ms-appinstaller URI protocol
18+
19+
**Status: Disabled by default (since December 2023)**
20+
21+
The `ms-appinstaller:?source=` URI protocol handler allows a web page to trigger a one-click App Installer install without the user downloading the file first. This feature was **disabled by default** in App Installer version 1.21.3421.0, released December 12, 2023, in response to its abuse by the Emotet malware campaign (CVE-2021-43890 exploitation pattern).
22+
23+
| Context | Status |
24+
|---|---|
25+
| Consumer devices (default) | ❌ Disabled |
26+
| Enterprise devices (IT-managed) | ✅ Can be re-enabled via Group Policy |
27+
28+
**Impact:** Tutorial pages on Microsoft Learn that demonstrate `<a href="ms-appinstaller:?source=...">Install</a>` web links no longer work for most users.
29+
30+
**Workarounds:**
31+
- **Link directly to the `.appinstaller` file** — users download and double-click it. This still works and is the recommended approach for non-enterprise scenarios.
32+
- **Publish to the Microsoft Store** — provides a superior one-click install experience with no protocol dependency.
33+
- **Enterprise re-enablement:** Set the Group Policy `EnableMSAppInstallerProtocol` to **Enabled** via the [DesktopAppInstaller CSP](/windows/client-management/mdm/policy-csp-desktopappinstaller#enablemsappinstallerprotocol). Note: the policy value `Disabled` means "the setting is not configured" (double-negative); set to `Enabled` to re-enable the protocol.
34+
35+
**References:** [App Installer security features](/windows/msix/app-installer/app-installer-security-features)
36+
37+
---
38+
39+
## .appinstaller file schema versions
40+
41+
**Status: Visual Studio generates outdated schema by default**
42+
43+
The `.appinstaller` XML file supports multiple schema versions, each with different capabilities. Visual Studio generates files using the **2017/2 schema** by default, which does not support several important update configuration attributes.
44+
45+
| Attribute | 2017/2 schema | 2021 schema |
46+
|---|---|---|
47+
| `ShowPrompt` | ❌ Not supported | ✅ Supported |
48+
| `UpdateBlocksActivation` | ❌ Not supported | ✅ Supported |
49+
| `HoursBetweenUpdateChecks` | ❌ Not supported | ✅ Supported |
50+
| Basic update on launch | ✅ Supported | ✅ Supported |
51+
52+
**Impact:** Developers who rely on Visual Studio to generate `.appinstaller` files and then configure `ShowPrompt` or `UpdateBlocksActivation` will find those settings are silently ignored at runtime.
53+
54+
**Fix:** Manually update the `xmlns` attribute in your `.appinstaller` file:
55+
56+
```xml
57+
<!-- Change this: -->
58+
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2" ...>
59+
60+
<!-- To this: -->
61+
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2021" ...>
62+
```
63+
64+
**References:** [Auto-update and repair apps](/windows/msix/app-installer/auto-update-and-repair--overview) · [WindowsAppSDK Discussion #5125](https://github.com/microsoft/WindowsAppSDK/discussions/5125)
65+
66+
---
67+
68+
## SmartScreen reputation: EV certificates no longer grant instant bypass
69+
70+
**Status: Behavior changed in 2024**
71+
72+
Prior to 2024, Extended Validation (EV) code signing certificates granted immediate SmartScreen reputation — a newly-signed binary would show no download warning. Microsoft updated the Trusted Root Program requirements in 2024, removing EV-specific OIDs. SmartScreen reputation is now exclusively **hash-based and accumulates over time**, regardless of certificate type (OV or EV).
73+
74+
**Impact:** Developers who purchased EV certificates specifically to bypass SmartScreen warnings for new releases will find that EV certificates no longer provide this benefit.
75+
76+
**Current behavior:** All non-Store, non-Microsoft-signed binaries show a SmartScreen prompt on first download until sufficient download history is accumulated for that file hash.
77+
78+
See [SmartScreen reputation for Windows app developers](smartscreen-reputation.md) for full details on expected behavior and recommendations.
79+
80+
---
81+
82+
## MSIX on Windows 10 vs Windows 11
83+
84+
**Status: Several MSIX features are Windows 11-only**
85+
86+
MSIX was introduced on Windows 10, but many improvements and bug fixes since then have only been made available on Windows 11. If your app targets Windows 10 users, be aware of the following limitations.
87+
88+
| Feature / scenario | Windows 10 | Windows 11 |
89+
|---|---|---|
90+
| MSIX sideloading (non-Store) | ✅ Supported (requires policy) | ✅ Supported (enabled by default) |
91+
| Registry virtualization fixes | ⚠️ Known issues | ✅ Fixed |
92+
| App container improvements | ⚠️ Some fixes not backported | ✅ Latest behavior |
93+
| MSIX packaging tool stability | ⚠️ Some scenarios require workarounds | ✅ Better supported |
94+
| App Installer reliability | ⚠️ More known issues | ✅ Improved |
95+
| Sideloading without Developer Mode | ✅ Via `AllowAllTrustedApps` policy | ✅ Enabled by default |
96+
97+
> [!IMPORTANT]
98+
> Several platform-level MSIX bugs reported in the `microsoft/msix-packaging` repository affect Windows 10 and have not been backported to Windows 10. If you are seeing MSIX issues specifically on Windows 10 that do not reproduce on Windows 11, this may be a known unbackported issue.
99+
100+
**Recommendation:** If you need to support MSIX on Windows 10 reliably in complex scenarios, test thoroughly on Windows 10 specifically and review open issues in [microsoft/msix-packaging](https://github.com/microsoft/msix-packaging/issues).
101+
102+
---
103+
104+
## MsixPackaging@1 Azure DevOps task
105+
106+
**Status: Uses outdated dependencies**
107+
108+
The `MsixPackaging@1` task in Azure DevOps pipelines uses MSBuild 4.8.4161.0 (instead of MSBuild 16+) and was built against Node 16 (which reached end-of-life in September 2023). This can cause build failures in modern pipeline configurations.
109+
110+
**Workaround:** Use MSBuild directly in your pipeline rather than the `MsixPackaging@1` task, or use GitHub Actions with the `microsoft/setup-msbuild` action.
111+
112+
**References:** [GitHub Issue #518](https://github.com/microsoft/msix-packaging/issues/518) · [GitHub Issue #679](https://github.com/microsoft/msix-packaging/issues/679)
113+
114+
---
115+
116+
## Related content
117+
118+
- [Choose a distribution path for your Windows app](choose-distribution-path.md)
119+
- [SmartScreen reputation for Windows app developers](smartscreen-reputation.md)
120+
- [App Installer file overview](/windows/msix/app-installer/app-installer-file-overview)
121+
- [Auto-update and repair apps](/windows/msix/app-installer/auto-update-and-repair--overview)
122+
- [Azure Trusted Signing](/azure/trusted-signing/)

‎hub/apps/package-and-deploy/index.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,8 @@ App packaging provides your application with a predictable installation, update,
1616

1717
Not sure which packaging model is right for your app? See [Packaging overview](packaging/index.md).
1818

19+
Choosing how to distribute your app — through the Microsoft Store, enterprise sideloading, or direct download? See [Choose a distribution path](choose-distribution-path.md) for a side-by-side comparison of signing costs, update mechanics, and enterprise management per path. For the current status of distribution features (including the ms-appinstaller protocol change), see [Current status of Windows app distribution features](distribution-feature-status.md).
20+
1921
When deploying apps that use the Windows App SDK, you can choose between framework-dependent and self-contained deployment models. Framework-dependent apps rely on the Windows App SDK runtime and/or framework package being installed on the user’s machine. In contrast, self-contained apps bundle the Windows App SDK dependencies directly with the application, ensuring the app carries everything it needs to run. The right model depends on your distribution scenario, update strategy, and how much control you want over the app’s footprint and dependencies.
2022

2123
---

0 commit comments

Comments
 (0)