Publish your first Windows app

You built a WPF, WinForms, or WinUI 3 app — now you need to get it into users' hands. This guide walks through the full path from a finished build to a published app, covering the two most common distribution scenarios: publishing to the Microsoft Store (recommended) and setting up direct download distribution.

Step 1: Choose your distribution path

Your distribution path determines your code signing costs, update mechanics, how users discover your app, and how enterprises can deploy it.

→ Choose a distribution path for your Windows app has a full comparison. In short:

• Microsoft Store — recommended for most apps. Free signing, built-in updates, broad discoverability, and a trusted install experience. Requires a free developer account — register at storedeveloper.microsoft.com.
• Direct download — appropriate for commercial ISVs with their own storefront, enterprise LOB apps, or apps with content the Store doesn't permit. You are responsible for signing, hosting, and updates.

Most new indie apps are a good fit for the Store. If you're unsure, start there.

Step 2: Set up code signing

If you're publishing an MSIX package to the Microsoft Store: skip this step. Microsoft re-signs your package automatically as part of the certification process.

If you're submitting a Win32 MSI/EXE installer to the Microsoft Store: you still need to sign your installer before submission. The installer and its PE files must be signed with a certificate chaining to a CA in the Microsoft Trusted Root Program. Self-signed certificates are not acceptable. See App package requirements for MSI/EXE.

If you're distributing directly: you need a trusted code signing certificate. Unsigned apps and self-signed apps trigger strong SmartScreen warnings, and some enterprise environments will block them entirely.

→ Code signing options for Windows app developers has a full comparison. Quick guidance:

• Organizations in USA, Canada, EU, or UK / Individuals in USA or Canada: Azure Artifact Signing (formerly Trusted Signing) — approximately $9.99/month, no hardware token required, integrates with CI/CD pipelines. This is Microsoft's recommended option for non-Store distribution.
• Individual developers outside USA/Canada, or anyone not eligible for Azure Artifact Signing: An OV certificate from a Certificate Authority such as DigiCert or Sectigo — typically $150–300/year.

Step 3: Package your app

How you package your app depends on the app framework you used.

WinUI 3

WinUI 3 apps created with the Windows App SDK project templates are already packaged as MSIX by default. When you build your solution in Visual Studio, the output is an .msix or .msixbundle file ready for Store submission or direct distribution.

If you want to distribute an unpackaged WinUI 3 app (without MSIX packaging), see Distribute an unpackaged WinUI 3 app. Note that unpackaged WinUI 3 apps cannot produce a single-file EXE and require the Windows App SDK runtime on the user's machine (either installed separately via the runtime installer, or bundled using self-contained deployment).

WPF and WinForms

WPF and WinForms projects do not produce MSIX by default. You have a few options:

Option A: Windows Application Packaging Project (MSIX)
Add a Windows Application Packaging Project to your solution in Visual Studio. This wraps your app in an MSIX package, giving you package identity, Store eligibility, and App Installer–based updates. This is the recommended approach for Store submission.

→ Package your desktop app using single-project MSIX

Option B: dotnet publish (self-contained EXE)
For direct download distribution, dotnet publish with --self-contained produces a standalone EXE that includes the .NET runtime — users don't need to install .NET separately.

dotnet publish -c Release -r win-x64 --self-contained true

This produces a folder of files suitable for zipping and distributing, or wrapping in an installer. It is not directly Store-eligible.

Option C: Framework-dependent publish
Omit --self-contained if you're comfortable requiring users to have the correct .NET runtime installed. The output is smaller but has a runtime dependency.

Step 4a: Submit to the Microsoft Store (recommended path)

The Store submission process runs through Partner Center.

Steps at a glance:

1. Create a developer account — Free. Register at storedeveloper.microsoft.com. The account is permanent.
2. Reserve your app name — Claim your app's name in Partner Center before submission. The name is held for you during development.
3. Build and package your app — Create an MSIX package that meets Store requirements. For Store submissions, MSIX/AppX packages don't need a CA-trusted signature — Microsoft re-signs the package with a Microsoft certificate after certification. If you distribute outside the Store using an MSI or EXE installer, Authenticode signing is recommended and expected by Windows security features.
4. Create your submission — Upload your package, provide store listing details (description, screenshots, categories, age rating), and set pricing.
5. Certification — Microsoft reviews your app for policy compliance. Certification typically takes a few business days for new apps.
6. Publish — Once certified, your app appears in the Store and is available to users.

→ Create your app submission
→ App package requirements

Step 4b: Distribute directly (alternative path)

If you're distributing your app outside the Store, you have several packaging and hosting options.

MSIX with App Installer (.appinstaller)

MSIX packages distributed with a companion .appinstaller file support automatic update checks. When users install the app from the .appinstaller file, Windows periodically checks the URL you specify for a newer version and offers to update.

ClickOnce (WPF and WinForms)

ClickOnce is a .NET deployment technology built into Visual Studio that supports automatic updates for WPF and WinForms apps. Users install from a hosted manifest, and ClickOnce handles update checks transparently.

ClickOnce is not supported for WinUI 3 apps — use MSIX with .appinstaller instead.

→ ClickOnce security and deployment

EXE installer

A traditional EXE installer created with a tool such as WiX Toolset or Inno Setup is familiar to users and straightforward to produce. These are well-established community tools used by many Windows applications. Note that EXE installers require you to implement your own update mechanism.

Hosting your download

Common hosting options for direct download:

• GitHub Releases — free, versioned, and integrates well with automated build pipelines. Suitable for open-source and small commercial apps.
• Your own website — full control over the download page, analytics, and payment flow. You'll need reliable storage and CDN capacity if your app grows.
• Third-party stores — some developers distribute through storefronts such as itch.io for gaming-adjacent apps.

winget for discoverability

Submitting your app to the Windows Package Manager Community Repository makes your app installable via winget install. This is especially valued by developer and power-user audiences who prefer command-line tooling. Submission is a pull request against the community manifest repository and is free.

Step 5: Set up auto-update

Keeping users on the latest version reduces support burden and ensures security fixes reach them promptly.

For EXE or self-contained deployments without a built-in update mechanism, Velopack is a community tool that adds auto-update and installer capabilities to .NET apps. It is not a Microsoft product — evaluate it based on your own requirements.

Step 6: Handle SmartScreen for new apps

Every new app — regardless of how well it's signed — will trigger a SmartScreen warning on first download until it accumulates enough download history. This is expected and normal. Here's how to handle it well:

• Sign every release. Unsigned apps show a more severe "Windows protected your PC" block. Signed apps show a softer "unrecognized app" warning that users can bypass more easily.
• Set expectations with early users. Tell beta testers and early adopters what to expect. A brief note in your release announcement ("You may see a SmartScreen prompt on first run — this is normal for new apps; click 'More info' then 'Run anyway'") prevents confusion and abandoned installs.
• Be patient. Reputation builds organically with download volume. There is no manual submission process to accelerate it for consumer endpoints.

→ SmartScreen reputation for developers explains the full reputation model, what users see at each stage, and enterprise policy considerations.

What's next

Once your app is published, you can:

• Monitor app health and ratings — Partner Center provides crash analytics, user ratings, and review management for Store apps
• Manage releases with staged rollouts — the Store supports rolling out a new version to a percentage of users before a full release
• Set up telemetry — consider integrating a crash and usage analytics service such as Azure Application Insights or another analytics SDK to understand how your app is used
• Respond to user feedback — Partner Center surfaces Store reviews; for direct download apps, consider a feedback channel (GitHub Issues, a dedicated email address, or a community forum)

Related content

• Choose a distribution path for your Windows app
• Code signing options for Windows app developers
• SmartScreen reputation for developers
• Current status of distribution features
• Create your app submission
• Azure Artifact Signing (formerly Trusted Signing)
• Windows Package Manager (winget)