Distribution Channels

A Store submission requires a developer account in Partner Center. Two account types exist: Individual for publishing under your own name, and Company for a registered legal entity. With the onboarding flow that starts at storedeveloper.microsoft.com, Learn states that there are no registration fees for either type. Other entry points (Partner Center directly, Xbox or Visual Studio) show the legacy flow, which the Learn page says is not the free one.

Source: Steps to open a Microsoft Store developer account in Partner Center

For Bookshelf Desktop, a hobby project, an Individual account is enough; a team shipping it commercially chooses Company from the start, because the switch is not supported.

The submission flow in Partner Center is the same for every MSIX app. The checklist below follows the current Learn page and marks where Bookshelf Desktop needs a decision.

Source: Create an app submission for your MSIX app

The same flow can be automated. The Learn page points to the Microsoft Store submission API for that, and the CI/CD page of this section covers the Microsoft Store Developer CLI as a pipeline step.

An MSI/EXE submission skips the package upload. In its place, the Packages page takes the installer URL, and the rest of the flow (name reservation, pricing, properties, age ratings, listings, certification) is the same. The requirements that differ:

Source: Choose a distribution path: Microsoft Store

Every submission passes certification against the Microsoft Store Policies, currently version 7.20. The policies cover product quality, security, privacy, content, financial transactions, and the behaviour of packages. The practical consequences for a desktop developer are:

Source: Microsoft Store Policies version 7.20

The policy document is long and is revised several times a year, so the release checklist of a Store app should link to the current version instead of copying it.

The Windows App Certification Kit (WACK) runs a subset of the certification tests on the developer’s machine, so failures show up before a submission is made. It ships with the Windows SDK, can be started from the Start menu or the command line, and writes an HTML or XML report. Running it on the final, signed package is the cheapest way to avoid a failed certification, which otherwise costs a round trip of a day or more.

Source: Windows App Certification Kit

Partner Center supports package flights: a flight is a version of the app delivered only to a chosen group of Microsoft accounts or Entra ID groups, so a beta can ship through the real Store pipeline without a second listing. A submission can also roll out gradually to a percentage of users and be halted if crash rates climb. Both features are part of the MSIX submission path and are not available to MSI/EXE submissions, which have no Store-managed updates. Bookshelf Desktop uses a flight for its beta ring and a staged rollout for each public release.

Older tutorials link users to an install page with the ms-appinstaller:?source= URI scheme, which opened the installer directly from the browser. That protocol handler was disabled by default in App Installer version 1.21.3421.0, released on 12 December 2023, after the Emotet malware campaign abused it. On consumer devices it is off; enterprise administrators can re-enable it through the EnableMSAppInstallerProtocol Group Policy of the DesktopAppInstaller CSP (the policy value named "Disabled" means "not configured", so it is set to "Enabled" to turn the protocol back on). The supported pattern today is a plain download link to the .appinstaller file; the user downloads it and opens it.

Source: Current status of Windows app distribution features

Visual Studio still generates .appinstaller files with the 2017/2 schema by default. That schema does not support ShowPrompt, UpdateBlocksActivation or HoursBetweenUpdateChecks, and settings that use them are silently ignored at run time. The fix is to change the namespace to the 2021 schema by hand, as in the example below.

Source: Current status of Windows app distribution features

Source: App Installer file update settings

The elements work as follows:

The MainPackage Version must be higher than the installed version for an update to apply, which is why the four-part MSIX version number matters; Updates, Versioning & Telemetry explains how to derive it. The signing certificate must stay trusted by the user’s device between versions, and the publisher string must not change.

The feed is static files. Any web server, object-storage bucket or SMB share works as long as it serves the files with the right content types:

The content types in the table above are the registered names used by the MSIX tooling; a server that returns application/octet-stream for these files usually still works, but some browsers then treat the download differently. Treat the table as a configuration hint to check against your host rather than a hard requirement.

The chapter on distribution in Tidjani Belmansour’s Building CLI Applications with C# and .NET (chapter 11, pages 231 to 234) walks through exactly this flow for a command-line tool: publish a self-contained build for win-x64, host the installer on a stable HTTPS URL, generate a manifest with wingetcreate, and test it locally with winget install --manifest. The same steps apply to a desktop app. The book covers neither signing nor MSIX for this channel, so the signing guidance below comes from the official documentation instead.

Source: Create a single file for application deployment and hash command (winget)

The WinGet installer types are the ones WinGet knows how to run, so the build output is normally wrapped before it is referenced: an installer (MSI, an Inno Setup or Nullsoft EXE), an MSIX, or a zip that contains a portable or nested installer. The winget-pkgs README lists the accepted types as MSIX, MSI, APPX, MSIXBundle, APPXBundle or .exe application installers.

The question deserves care, because advice circulating on the web differs. What the official documentation says today:

So an unsigned installer is not rejected by policy, but it is the most likely to trigger SmartScreen prompts for users and antivirus false positives in validation (labels such as Binary-Validation-Error and Validation-Defender-Error exist for this). The practical rule for Bookshelf Desktop is to sign what WinGet installs: an MSIX signed with a CA-trusted certificate, or a signed EXE or MSI. If you read elsewhere that WinGet now requires signing, check the Learn policy page before relying on it; the official pages state a recommendation, not a requirement.

The multi-file manifest format splits a package version into a version file, an installer file and one locale file per language. The manifest version in the current Learn examples is 1.12.0. The three files below describe Bookshelf Desktop 1.4.0 distributed as a signed MSIX. The path inside winget-pkgs is manifests/e/Example/BookshelfDesktop/1.4.0/: the folder names follow the pattern letter, publisher, application, version, and PackageIdentifier plus PackageVersion must match that path.

Source: Create your package manifest

The fields to understand:

A manifest for a classic installer swaps the Installers entry: InstallerType: inno (or msi, nullsoft, exe), an InstallerSwitches block when the installer needs custom silent switches, and a ProductCode for MSI packages so that WinGet can detect the installed version and upgrade correctly. The Learn page lists common silent switches: /q for MSI, /SILENT or /VERYSILENT for Inno Setup, /S for Nullsoft, and /s for InstallShield.

Writing three YAML files by hand is rarely necessary. wingetcreate (winget-create 1.12.13.0) is a command-line tool that downloads the installer, computes the hash, reads installer metadata and prompts for the rest:

Source: winget-create

wingetcreate new ends with an offer to submit the manifest as a pull request; answering yes opens the pull request against microsoft/winget-pkgs automatically. The commands the README documents are:

For CI the README advises keeping the personal access token in a secret and passing it through the environment variable WINGET_CREATE_GITHUB_TOKEN or the -t option. A classic token needs the repo permission. In a GitHub Actions step the token is ${{ secrets.WINGET_PAT }}, never a literal; the CI/CD page of this section builds the whole release workflow around it.

The Learn repository page describes a four-step local check that a submission should pass before it is pushed:

Source: Submit your manifest to the repository

Belmansour’s chapter 11 uses the same winget settings --enable LocalManifestFiles and winget install --manifest pair to test a manifest before submission, because WinGet refuses local manifests until that setting is enabled. The Sandbox script installs WinGet in a throwaway Windows Sandbox, installs the package there and validates the manifest again, so it shows what the validation service will see.

Submitting means a pull request to microsoft/winget-pkgs. An automated pipeline then validates the manifest and installs the package; a human moderator reviews the result before the package is published to the catalog. The labels on the pull request report progress:

Source: Submit your manifest to the repository: validation process

Other rules from the same page: the repository accepts one manifest per submission, PackageIdentifier and PackageVersion must match the folder path, and Microsoft reserves the right to refuse a submission for any reason. For a false antivirus positive, the page links to the Microsoft Defender file submission portal.

In Visual Studio, Publish on the project creates a Folder profile, and the specific target is ClickOnce. The wizard then asks for:

The result is a folder with a .application file, an application manifest and versioned subfolders of application files. Publishing .NET Core 3.1, .NET 5 and later with ClickOnce requires Visual Studio 2019 16.8 or later; .NET Framework projects use a different, older wizard.

Source: Deploy a .NET Windows Desktop app with ClickOnce

The same profile can be published from the command line, which is what a CI job runs. The exact properties come from the profile Visual Studio generates under Properties\PublishProfiles, so create the profile once in the IDE and commit it:

Source: Deploy a .NET Windows Desktop app with ClickOnce

The .NET Framework ApplicationDeployment class does not exist in modern .NET. Starting with .NET 7 and Visual Studio 2022 version 17.4, the ClickOnce launcher passes the deployment properties to the app as environment variables that carry a ClickOnce_ prefix:

Only the properties are available; .NET 7 and later do not support the equivalent of the ApplicationDeployment methods such as CheckForUpdate. A small service keeps the rest of Bookshelf Desktop independent of the variables:

Source: Access ClickOnce deployment properties for .NET

To read URL parameters from ActivationUri, the deployment manifest must set trustURLParameters. The dotnet-mage tool (the .NET replacement for the older Mage tool) sets it with the -TrustURLParameters switch (short form -tu), added in .NET 7, instead of editing the manifest by hand.