Merge pull request #6680 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-21 20:52 UTC

Author: learn-build-service-prod[bot]

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

@@ -11,7 +11,7 @@ ms.localizationpriority: medium
 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.
 
 > [!TIP]
-> **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.
+> **For most developers, the Microsoft Store is the recommended path.** It provides broad discoverability, a trusted install experience, and no infrastructure to manage for MSIX submissions (Microsoft re-signs and hosts the package). Win32 MSI/EXE installer submissions are also accepted — the publisher must host a versioned HTTPS installer URL — see [MSI/EXE app submission](/windows/apps/publish/publish-your-app/msi/create-app-submission). MSIX submissions get free code signing and built-in update delivery.
 
 > [!NOTE]
 > **If your app is built on web technologies** (HTML, JavaScript, CSS), a [Progressive Web App (PWA)](#progressive-web-app-pwa) is the fastest path to the Microsoft Store — no native packaging tools required.
@@ -20,27 +20,30 @@ How you distribute your Windows app affects code signing costs, update mechanics
 
 | Path | Best for | Code signing cost | Auto-update | Enterprise MDM | Distributed via Store |
 |---|---|---|---|---|---|
-| **Microsoft Store** | Consumer and business apps, broad reach | ✅ Free (Store signs for you) | ✅ Built-in | ✅ Via Intune with Company Portal | ✅ Yes |
+| **Microsoft Store (MSIX)** | Consumer and business apps, broad reach | ✅ Free (Store re-signs your package) | ✅ Built-in | ✅ Via Intune with Company Portal | ✅ Yes |
+| **Microsoft Store (MSI/EXE installer)** | Existing Win32 apps with own installer | 💲 Publisher must sign the installer and all PE files with a cert chaining to the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) | ❌ Manual (app or installer handles updates) | ✅ Via Intune with Company Portal | ✅ Yes |
 | **PWA (Progressive Web App)** | Web apps and web-based experiences | ✅ Free (Store signs for you) | ✅ Via Store or browser | ✅ Via Intune with Company Portal | ✅ Yes |
 | **MSIX sideload (enterprise)** | Internal LOB apps via Intune/ConfigMgr | 💲 Azure Artifact Signing (formerly Trusted Signing) (~$10/mo) or self-signed + Intune cert profile | ✅ Via App Installer file or MDM | ✅ Native | ❌ No |
 | **MSIX direct download (ISV)** | Commercial apps sold from your own site | 💲 CA-trusted cert required ([Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) recommended) | ✅ Via `.appinstaller` file | ⚠️ Limited | ❌ No |
-| **Packaging with external location** | Existing apps with own installer needing Windows features | 💲 Same as MSIX direct download | ✅ Your existing mechanism | ⚠️ Limited | ❌ No |
-| **Unpackaged WinUI 3** | Niche: enterprise without MSIX capability, or max install simplicity | 💲 Cert recommended for SmartScreen | ❌ Manual only | ⚠️ Limited (via Intune/ConfigMgr Win32 deployment) | ⚠️ Limited (Store-listed installer submission) |
+| **Packaging with external location** | Existing apps with own installer needing Windows features | 💲 Same as MSIX direct download | ✅ Your existing mechanism | ⚠️ Limited | ⚠️ Via MSI/EXE Store submission (publisher signing required) |
+| **Unpackaged WinUI 3** | Niche: enterprise without MSIX capability, or max install simplicity | 💲 Cert recommended for SmartScreen | ❌ Manual only | ⚠️ Limited (via Intune/ConfigMgr Win32 deployment) | ⚠️ Via MSI/EXE Store submission (publisher signing required) |
 
 ## Microsoft Store (recommended)
 
-Publishing to the Microsoft Store is the most complete distribution solution for Windows apps.
+Publishing to the Microsoft Store is the most complete distribution solution for Windows apps. Two submission paths are available:
 
-**What you get:**
-- Code signing handled automatically — no certificate purchase needed
-- Built-in update delivery with staged rollout support
+- **MSIX submission** — recommended for new apps and WinUI 3 apps. Microsoft re-signs the package; no cert purchase needed. Includes Store-managed updates, staged rollouts, and differential downloads.
+- **MSI/EXE installer submission** — for existing Win32 apps with their own installer. Publisher submits a versioned HTTPS URL to the installer hosted on the publisher's own CDN; the Store downloads and runs the installer from that URL as part of the Store install flow. Publisher must sign the installer with a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list). Updates are the app's responsibility.
+
+**What you get (both paths):**
 - Discovery through the Store's search and curated collections
-- Trusted install UX with no SmartScreen warnings
+- Trusted install UX
 - Revenue processing, refunds, and analytics included
+- Enterprise deployment via Intune with Company Portal
 
 **Requirements:**
-- App must be packaged as MSIX (WinUI 3 apps are packaged by default)
-- App must pass [Store certification requirements](/windows/apps/publish/publish-your-app/msix/app-package-requirements)
+- MSIX is the recommended package format — WinUI 3 apps are packaged by default. Win32 apps with an existing MSI or EXE installer can also submit via the [MSI/EXE installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission) (note: MSI/EXE submissions require a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) — self-signed is not accepted; Store-managed updates are not available for this path)
+- App must pass Store certification requirements: [MSIX requirements](/windows/apps/publish/publish-your-app/msix/app-package-requirements) | [MSI/EXE requirements](/windows/apps/publish/publish-your-app/msi/app-package-requirements)
 - Developer account required ([Partner Center](https://partner.microsoft.com/dashboard))
 
 **When to choose this:**
@@ -141,7 +144,7 @@ If you have an existing app with its own installer (WiX, NSIS, InstallShield) an
 - Your existing install and update mechanism stays in place
 
 **What you don't get:**
-- Store eligibility
+- Direct MSIX Store submission (the sparse package is not itself Store-submitted; however, your underlying installer can be submitted via the [MSI/EXE Store installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission))
 - The clean install/uninstall model of full MSIX
 
 **When to choose this:**
@@ -184,7 +187,7 @@ Many Windows apps are distributed using ClickOnce, MSI, WiX, Inno Setup, or simi
 | **MSIX via Store** | ✅ Built-in | ✅ Free (Store signs) | ✅ Yes | Most apps — recommended starting point |
 | **MSIX + .appinstaller** | ✅ Built-in | 💲 CA-trusted cert | ❌ No | ISVs distributing directly from a website |
 | **ClickOnce** | ✅ Built-in | 💲 Cert recommended | ❌ No | WPF/WinForms apps; not supported for WinUI 3 |
-| **MSI / WiX / Inno Setup** | ⚠️ Manual or custom | 💲 Cert recommended | ❌ No | Apps with complex install requirements or existing installer |
+| **MSI / WiX / Inno Setup** | ⚠️ Manual or custom | 💲 Cert recommended | ⚠️ Via MSI/EXE Store submission (see below) | Apps with complex install requirements or existing installer |
 | **Self-contained EXE (xcopy/zip)** | ❌ None | 💲 Cert recommended | ❌ No | Simple utilities; developer/power-user audiences |
 | **winget manifest** | ✅ Via winget | 💲 Cert recommended | ❌ No | Any of the above — adds discoverability via `winget install` |
 
@@ -200,7 +203,7 @@ ClickOnce is **not supported for WinUI 3 apps**. Use MSIX with `.appinstaller` f
 
 Traditional EXE and MSI installers remain common for Windows apps with complex installation requirements (driver installation, system services, registry configuration). Tools like [WiX Toolset](https://wixtoolset.org/), [Inno Setup](https://jrsoftware.org/isinfo.php), and [NSIS](https://nsis.sourceforge.io/) are community-maintained and widely used. Update support requires your own implementation.
 
-These formats are not Store-eligible as primary distribution packages. However, you can combine them with [packaging with external location](../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) if you need package identity for specific Windows features.
+These formats are not Store-eligible as MSIX packages, but can be submitted to the Store via the [MSI/EXE installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission) (requires a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) and a silent-install capable installer). You can also combine them with [packaging with external location](../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) if you need package identity for specific Windows features.
 
 ### Self-contained EXE (xcopy deployment)
 

hub/apps/package-and-deploy/code-signing-options.md

@@ -8,22 +8,26 @@ ms.localizationpriority: medium
 
 # Code signing options for Windows app developers
 
-If you publish your app through the Microsoft Store, code signing is free and handled for you automatically — you don't need to purchase or manage a certificate. Everything in this article applies to apps distributed **outside the Microsoft Store**.
+If you publish your app as an **MSIX package** through the Microsoft Store, code signing is free and handled for you automatically — Microsoft re-signs the package after certification and you don't need to purchase or manage a certificate. If you publish as an **MSI/EXE installer** through the Store, you are responsible for Authenticode signing your installer before submission. Everything else in this article applies to apps distributed **outside the Microsoft Store**.
 
 ## Comparison at a glance
 
 | Option | Cost | Availability | SmartScreen behavior | Store eligible | Best for |
 |---|---|---|---|---|---|
-| **Microsoft Store** (signs for you) | Free | Worldwide | ✅ No warnings | ✅ Yes | Recommended for most developers |
+| **Microsoft Store (MSIX)** — Store re-signs your package | Free | Worldwide | ✅ No warnings | ✅ Yes | Recommended for most new apps |
+| **Microsoft Store (MSI/EXE installer)** — publisher must sign | Cert chaining to [Trusted Root Program CA](/security/trusted-root/participants-list) required (varies by CA) | Worldwide | ✅ No SmartScreen prompts during Store install (UAC may still appear) | ✅ Yes | Existing Win32 apps submitting via MSI/EXE installer path |
 | **Azure Artifact Signing** (formerly Trusted Signing) | ~$9.99/month | Organizations: USA, Canada, EU, UK. Individuals: USA and Canada only | ⚠️ Reputation builds over time; initial warnings expected | ❌ No | Recommended for non-Store distribution |
 | **OV certificate** (from a CA such as DigiCert, Sectigo) | $150–300/year | Worldwide | ⚠️ Same as Azure Artifact Signing — reputation builds over time | ❌ No | Developers who can't use Azure Artifact Signing, or who prefer traditional CAs |
 | **EV certificate** | $400+/year | Worldwide | ⚠️ Same as OV since 2024 — no longer instant bypass | ❌ No | No longer recommended specifically for SmartScreen bypass |
 | **Self-signed certificate** | Free | — | ❌ Blocks installation for public users | ❌ No | Dev/testing only, or enterprise with managed certificate trust |
 | **No signature** | Free | — | ❌ Strong SmartScreen block; enterprises may block entirely | ❌ No | Not recommended for public distribution |
 
-## Microsoft Store — no signing needed
+## Microsoft Store — MSIX submissions: no signing needed
 
-Publishing through the Microsoft Store is the recommended distribution path for most Windows apps. Microsoft re-signs your package automatically, meaning users never see a SmartScreen warning and you never need to purchase or renew a certificate.
+Publishing an **MSIX package** through the Microsoft Store is the recommended distribution path for most Windows apps. Microsoft re-signs your package automatically, meaning users never see a SmartScreen warning and you never need to purchase or renew a certificate.
+
+> [!NOTE]
+> If you're submitting a **Win32 MSI or EXE installer** to the Store (rather than an MSIX package), Microsoft does not re-sign your installer. The installer and its PE files must be signed with a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) — self-signed certificates are not accepted. See [App package requirements for MSI/EXE](/windows/apps/publish/publish-your-app/msi/app-package-requirements).
 
 Create a free developer account at [storedeveloper.microsoft.com](https://storedeveloper.microsoft.com). After you register, use [Partner Center](https://partner.microsoft.com/dashboard) to submit your app and manage its listing.
 

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

@@ -41,9 +41,9 @@ For more information, see [Features that require package identity](../../desktop
 
 | Model | Package identity | Installer | Store eligible | Best for |
 |---|---|---|---|---|
-| **Packaged (MSIX)** | ✅ Yes | MSIX replaces installer | ✅ Yes | New apps, Store publishing, enterprise MDM |
-| **Packaging with external location** | ✅ Yes | Your existing installer | ❌ No | Existing apps with own installer, ISVs |
-| **Unpackaged** | ❌ No | XCopy / script | ❌ No | Internal tools, dev utilities, simple scenarios |
+| **Packaged (MSIX)** | ✅ Yes | MSIX replaces installer | ✅ Yes (MSIX submission) | New apps, Store publishing, enterprise MDM |
+| **Packaging with external location** | ✅ Yes | Your existing installer | ✅ Yes (MSI/EXE submission) | Existing apps with own installer, ISVs |
+| **Unpackaged** | ❌ No | MSI or EXE installer (also: XCopy or script for non-Store distribution) | ✅ Yes (MSI/EXE submission — requires an MSI or EXE installer with silent install support) | Broad Win32 distribution, internal tools |
 
 ### Packaged apps (MSIX)
 
@@ -63,7 +63,7 @@ This is the sweet spot for existing Win32/WPF/WinForms apps that ship via their
 |---|---|---|
 | Replaces your installer | Yes | No |
 | Binaries inside the package | Yes | No (external) |
-| Store eligible | Yes | No |
+| Store eligible | Yes (MSIX submission) | Yes (MSI/EXE submission) |
 | Package identity | Yes | Yes |
 | Update mechanism | MSIX update | Your existing mechanism |
 
@@ -82,13 +82,13 @@ Before you commit to unpackaged, check the [features table above](#features-that
 
 | Scenario | Recommended model | Details |
 |---|---|---|
-| **Indie developer publishing to the Microsoft Store** | Packaged (MSIX) | The Store requires MSIX. WinUI 3 apps are packaged by default — no changes needed. **Code signing is handled free by the Store.** → [Distribute your packaged app](../../distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store.md) |
+| **Indie developer publishing to the Microsoft Store** | Packaged (MSIX) recommended | MSIX is the recommended path — it enables Store-managed updates, differential downloads, and clean uninstall. WinUI 3 apps are packaged by default. **Code signing is handled free by the Store.** → [Distribute your packaged app](../../distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store.md)<br><br>Win32 apps with an existing MSI or EXE installer can also publish to the Store via the [MSI/EXE submission path](../../publish/publish-your-app/msi/create-app-submission.md), but the Store does not push updates to existing users — updates must be handled by the app or installer. |
 | **Enterprise app deployed via Intune or Configuration Manager** | Packaged, or external location for existing installers | New apps should use MSIX. Existing apps with their own installer can use packaging with external location. **Code signing:** use a self-signed cert (trusted via Intune, Group Policy, or Configuration Manager) or [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/). → [Deploy packaged apps](../../windows-app-sdk/deploy-packaged-apps.md) |
-| **ISV shipping a direct download with own installer** | Packaging with external location | Register a lightweight identity package alongside your existing installer. **Code signing:** a CA-trusted certificate is required for non-Store distribution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is the recommended lower-cost option. → [Grant package identity](../../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) |
+| **ISV shipping a direct download with own installer** | Packaging with external location | Register a lightweight identity package alongside your existing installer. **Code signing:** a CA-trusted certificate is required for non-Store distribution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is the recommended lower-cost option. → [Grant package identity](../../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md)<br><br>Alternatively, submit your existing installer to the Store via the [MSI/EXE submission path](../../publish/publish-your-app/msi/create-app-submission.md). |
 | **Internal tool or developer utility** | Unpackaged | Simplest to build and deploy. The Windows App SDK works via NuGet, but some features won't be available. |
 
 > [!TIP]
-> **Not sure about code signing costs?** Publishing through the Microsoft Store means you don't need to separately obtain or manage a certificate for end-user trust. For other distribution paths, your signing approach depends on deployment context — enterprise environments can trust a self-signed certificate through device management, while broader non-Store distribution typically requires a CA-trusted code signing solution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is Microsoft's recommended option (see [pricing](https://azure.microsoft.com/pricing/details/trusted-signing/)), with no hardware token required.
+> **Not sure about code signing costs?** Publishing an **MSIX package** through the Microsoft Store means you don't need to separately obtain or manage a certificate for end-user trust — Microsoft re-signs the package. Publishing a **Win32 MSI/EXE installer** through the Store requires a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list); self-signed is not accepted. For other distribution paths, your signing approach depends on deployment context — enterprise environments can trust a self-signed certificate through device management, while broader non-Store distribution typically requires a CA-trusted code signing solution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is Microsoft's recommended option (see [pricing](https://azure.microsoft.com/pricing/details/trusted-signing/)), with no hardware token required.
 
 ## Framework-dependent vs self-contained deployment