How to publish a WPF or Windows Forms app to the Microsoft Store

Which way should you package it?

Microsoft's MSIX docs split desktop apps in two. A WinUI 3 app uses single-project MSIX, and the single-project page lists only the WinUI templates as supported. For all other desktop apps, which includes WPF and Windows Forms, Microsoft points you to the Windows Application Packaging Project.

Microsoft recommends MSIX and lists free code signing and hosting on its CDN among the reasons. With an EXE or MSI listing, you host the installer, sign it with a certificate from a CA in the Microsoft Trusted Root Program, and give Partner Center a new versioned URL for every update. The rest of this guide covers the MSIX routes.

Check the app first

A packaged app runs with some limits. Microsoft's preparation checklist is long, and these are the items most WPF and Windows Forms apps run into.

• The app can't require elevation. Microsoft says apps that need it for any part of their functionality won't be accepted into the Store.
• Writing to the install folder isn't supported, so move log files and settings to the local app data store.
• Creating or changing keys under HKEY_LOCAL_MACHINE fails, so write to HKEY_CURRENT_USER instead.
• The working directory isn't the one from your old shortcut, so set it at runtime if your app depends on it.
• On .NET Framework, Microsoft recommends targeting 4.6.2 or later, and says earlier versions are expected to work in most cases but should be tested fully.

How to publish the first version

1. 1

   Reserve the name

   In Partner Center, click New product, choose MSIX or PWA app and reserve your app's name. Then open Product identity under Product management and copy Package/Identity/Name, Package/Identity/Publisher and PublisherDisplayName.

2. 2

   Add the packaging project

   Open your solution in Visual Studio and add a Windows Application Packaging Project in the same language as your app. The template shows up if you have the Universal Windows Platform development workload, or the MSIX Packaging Tools component in the .NET desktop development workload. Set the minimum version to Windows 10 Anniversary Update or later.

   Right-click the packaging project and choose Set as StartUp Project. Then right-click its Dependencies folder, choose Add Project Reference and pick your WPF or Windows Forms project. If you reference more than one app, right-click the one that should open from the tile under Applications and choose Set as Entry Point. You don't add any code to the packaging project.

   Build it once. If you get errors, open Configuration Manager and make sure the projects target the same platform. For x64, the simplest of the two fixes Microsoft gives is to add the x64 configuration in Configuration Manager before you add the packaging project.

3. 3

   Give the manifest your Store identity

   Right-click the packaging project and choose Publish, then Associate App with the Store. Sign in with your Partner Center account and pick the name you reserved. Visual Studio fills in fields on the Packaging tab of the manifest for you.

   You can also edit Package.appxmanifest in the packaging project by hand. The values are case-sensitive, and spaces and punctuation have to match too.

   <Identity
     Name="(Package/Identity/Name from Partner Center)"
     Publisher="(Package/Identity/Publisher from Partner Center)"
     Version="2.3.0.0" />
   
   <Properties>
     <PublisherDisplayName>(PublisherDisplayName from Partner Center)</PublisherDisplayName>
   </Properties>

   The fourth number of the version is reserved for the Store and has to stay 0. The first number can't be 0, and none of them can go above 65535.

4. 4

   Create the package

   Right-click the packaging project, choose Publish, then Create App Packages, and pick Microsoft Store with your app's name. Choose the architectures you want, set Generate app bundle to Always and include the public symbol files. Visual Studio writes an .msixupload to the AppPackages folder. On the last page you can run the Windows App Certification Kit, which Microsoft says is deprecated but still useful as a check before you submit.

5. 5

   Make the first submission

   Start a submission in Partner Center, fill in pricing and availability, properties, age ratings and the Store listing, and upload the .msixupload on the Packages page. Then submit it for certification. Once it passes, Microsoft publishes it, and the Store delivers updates to your users from then on.

Visual Studio 2026 dropped the Automate Store submissions option at the end of the wizard, so the upload happens in Partner Center or through a tool like StoreFast.

If you only have an installer

The MSIX Packaging Tool repackages an existing desktop app as an MSIX without the source code. You install it from the Microsoft Store or with winget, and it needs Windows 10 version 1809 or later and admin rights.

winget install "MSIX Packaging Tool"

Choose Application package, pick where to convert, and point it at your MSI, EXE, ClickOnce or App-V installer. The tool watches the install and builds a package from the changes it sees, so Microsoft suggests a clean machine or virtual machine. On the Package information page, enter the Name, Publisher and Publisher display name from Partner Center and a version that ends in 0. For an EXE you type these in yourself, and for an MSI the tool fills in what it can from the installer.

Run the app once on the Manage first launch tasks page so the tool can capture what it does on first launch, then save the .msix. The same package goes to Partner Center for the first submission, and you repeat the conversion for each new version of the installer.

How to build an .msix for updates

The .msixupload from step 4 is for Partner Center. For updates through StoreFast, build one .msix per release with msbuild on the packaging project. Microsoft's CI guide lists the arguments. SideloadOnly makes the package without the upload file, and AppxBundle=Never keeps it a plain .msix.

msbuild MyApp.Package\MyApp.Package.wapproj /p:Configuration=Release /p:Platform=x64 `
  /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxBundle=Never `
  /p:AppxPackageDir="Packages\" `
  /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="" `
  /p:PackageCertificateKeyFile=MyApp.pfx

The guide sets PackageCertificateThumbprint to an empty string on purpose, because a thumbprint in the project that doesn't match the .pfx fails the build. The .msix lands in a _Test folder under Packages. Raise the version in Package.appxmanifest before each build, or set it with a script in CI the way Microsoft's sample pipeline does.

Do you need a certificate?

Not a trusted one. Microsoft's package requirements say the Store replaces any signature on an MSIX with a Microsoft certificate after certification, so you don't buy a certificate or hand over a .pfx. A build that signs still needs some certificate. A self-signed one works, and its subject has to match the Publisher in your manifest exactly.

How to publish updates with StoreFast

Once the first version is live, connect your Partner Center account to StoreFast and your app shows up on the dashboard. For each release, raise the version, build one .msix and send it in one of these ways.

• Drop it on your app's page in StoreFast. It reads the package name and version on your computer, translates What's new into every listing language and submits the update.
• Add the StoreFast GitHub Action, legendaryspy/storefast-publish@v1, after your build step. The GitHub Actions guide covers the secrets and the workflow.
• Call the REST API from any other CI system.
• Ask a coding agent connected to the StoreFast MCP server. It shows you the update and waits for your yes before it submits.

- name: Build the package
  shell: pwsh
  run: |
    msbuild MyApp.Package/MyApp.Package.wapproj /p:Configuration=Release /p:Platform=x64 `
      /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxBundle=Never /p:AppxPackageDir="Packages\" `
      /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="" /p:PackageCertificateKeyFile=MyApp.pfx
    New-Item -ItemType Directory -Force dist | Out-Null
    Get-ChildItem Packages -Recurse -Filter '*_x64.msix' | Copy-Item -Destination dist

- name: Publish to the Microsoft Store
  uses: legendaryspy/storefast-publish@v1
  with:
    api-key: ${{ secrets.STOREFAST_API_KEY }}
    app: 9PJWF4W8V4WG
    package: 'dist/*.msix'

StoreFast doesn't take .msixupload or .msixbundle files yet, and the .msix you send replaces the packages in the last submission. If your first release was a bundle with several architectures, an update through StoreFast ships the one you build. The MSIX update guide covers version rules and the upload errors Partner Center gives.

Building with .NET MAUI or WinUI 3 instead? The MAUI and WinUI guide uses dotnet publish and single-project MSIX.

Who it's for

Questions

Can I use single-project MSIX for a WPF or Windows Forms app?

Not according to Microsoft's docs. The single-project MSIX page says it supports the WinUI templates for the Windows App SDK, and it sends every other kind of desktop app to the Windows Application Packaging Project instead.

Do I need a code signing certificate to publish a WPF app to the Microsoft Store?

Not a trusted one for an MSIX. Microsoft re-signs MSIX packages with its own certificate after certification. A self-signed certificate is enough for builds that sign, as long as its subject matches the Publisher in your manifest. If you submit an EXE or MSI installer instead, you sign it yourself with a certificate from a CA in the Microsoft Trusted Root Program.

Does my app need to run as administrator?

It can't. Microsoft says apps that require elevation for any part of their functionality won't be accepted into the Store, and the app has to work as the interactive user.

Why does the version have to end in 0?

Microsoft reserves the fourth number of the package version for the Store. You leave it at 0, the first number can't be 0, and each number goes up to 65535.

Can StoreFast publish my WPF or Windows Forms app?

Yes, if you ship it as an MSIX, from the second release on, as one .msix per update. You make the first submission in Partner Center, then publish updates from the dashboard, the GitHub Action, the API or a coding agent. EXE and MSI listings aren't supported yet.