How to publish to the Microsoft Store from Azure DevOps

What you need before the pipeline runs

• An app with its first submission done. Microsoft's msstore CLI overview says you reserve the name and make the first submission, age ratings included, in Partner Center.
• A Microsoft Entra application with access to Partner Center, on a tenant that's associated with your developer account. Microsoft's routes need its tenant ID, client ID and client secret plus your seller ID. StoreFast creates its own when you sign in with Microsoft, and its connection guide covers both.
• A build that makes the .msix. The version has four numbers, and Microsoft's package rules reserve the last one for the Store, so it has to be 0, like 1.4.0.0.

Where the secrets go in Azure DevOps

Open the pipeline, click Edit, then Variables, add each value and tick Keep this value secret. To share them across pipelines, put them in a variable group under Pipelines, Library, where you can also link them to Azure Key Vault. Microsoft's secret variables page covers both.

One thing catches people out. Secret variables aren't turned into environment variables for scripts on their own, so a script step has to map each one under env, like the StoreFast pipeline below does with STOREFAST_API_KEY. The same page also suggests not passing secrets on the command line, because some systems log command lines.

How to publish with the msstore CLI

Microsoft's CI/CD page for the msstore CLI has an Azure DevOps example that sets up the CLI with the UseMSStoreCLI@0 task and signs in with msstore reconfigure. Add these four secret variables first.

• PARTNER_CENTER_TENANT_ID
• PARTNER_CENTER_SELLER_ID
• PARTNER_CENTER_CLIENT_ID
• PARTNER_CENTER_CLIENT_SECRET

This pipeline is Microsoft's example with a publish step added. Put your Store product ID in a STORE_PRODUCT_ID variable and point the path at the .msix your build makes.

trigger:
  branches:
    include:
      - main

pool:
  vmImage: windows-latest

variables:
  MSSTORE_OUTPUT_STREAM: stdout

steps:
  # Your build steps make the .msix before this point.

  - task: UseMSStoreCLI@0
    displayName: Setup Microsoft Store Developer CLI

  - script: msstore reconfigure --tenantId $(PARTNER_CENTER_TENANT_ID) --sellerId $(PARTNER_CENTER_SELLER_ID) --clientId $(PARTNER_CENTER_CLIENT_ID) --clientSecret $(PARTNER_CENTER_CLIENT_SECRET)
    displayName: Configure Microsoft Store Developer CLI

  - script: msstore publish "$(Build.ArtifactStagingDirectory)/MyApp.msix" -id $(STORE_PRODUCT_ID)
    displayName: Publish to the Microsoft Store

MSSTORE_OUTPUT_STREAM is there because Azure DevOps marks every stderr line as an error, even when the command worked. The msstore CLI's README recommends sending its readable output to stdout this way. The reconfigure step passes the secrets as arguments because that's how Microsoft's example does it, and the CLI also accepts a certificate in place of the client secret.

Two things to know from Microsoft's docs. The CLI is in preview, and app updates through it work for free products only, with paid products promised in a future release. To change What's new, you get the submission JSON with msstore submission get, edit each language yourself and send it back with msstore submission update, and you have to run publish before that, because publish starts a fresh draft and drops staged changes.

The Windows Store extension

Before the CLI, Microsoft's answer for Azure DevOps was the Windows Store extension on the Visual Studio Marketplace. It's still listed there with no deprecation notice. You install it in your organization, add a service connection of the Windows Dev Center type with your tenant ID, client ID and client secret, and use its tasks.

The extension now has two versions. V0 is for developers outside Microsoft and signs in with a client secret. V3 is only for Microsoft's own teams and uses certificates or workload identity federation. Its setup docs say it can only update apps that already exist and have at least one submission. For a new pipeline, Microsoft's current docs point to the msstore CLI.

How to publish with StoreFast's API

1. 1

   Create an API key

   In StoreFast's Settings, create an API key that can publish. Add it to the pipeline as a secret variable named STOREFAST_API_KEY.

2. 2

   Find the app's ID

   Call GET /apps once with the key and copy the app's id into a STOREFAST_APP_ID variable. It isn't a secret.

3. 3

   Add the step

   This pipeline runs when you push a tag that starts with v. It starts a release, uploads the .msix in parts, saves the notes, submits and waits until Partner Center has the package. Set VERSION and PACKAGE from your build, and put the step right after the one that makes the package.

   trigger:
     tags:
       include:
         - v*
   
   pool:
     vmImage: ubuntu-latest
   
   variables:
     STOREFAST_APP_ID: 3f2b7c1e-8a4d-4e6b-9c2f-5d1a0b7e6c94
     VERSION: 1.4.0.0
     PACKAGE: MyApp_1.4.0.0_x64.msix
   
   steps:
     # Your build or a download step puts the .msix and RELEASE_NOTES.md here.
   
     - bash: |
         set -euo pipefail
         API=https://storefast.app/api/v1
         AUTH="Authorization: Bearer $STOREFAST_API_KEY"
         SIZE=$(wc -c < "$PACKAGE" | tr -d ' ')
   
         # 1. Start the release
         RELEASE=$(curl -sf -X POST -H "$AUTH" -H 'Content-Type: application/json' \
           -d "$(jq -n --arg v "$VERSION" --arg f "$PACKAGE" --argjson s "$SIZE" '{version: $v, fileName: $f, size: $s}')" \
           $API/apps/$STOREFAST_APP_ID/releases | jq -r .releaseId)
   
         # 2. Upload the package in 8 MiB parts, numbered from 1
         split -b 8m "$PACKAGE" part-
         n=1
         for part in part-*; do
           curl -sf -X PUT -H "$AUTH" --data-binary @"$part" $API/releases/$RELEASE/parts/$n
           n=$((n + 1))
         done
         rm part-*
   
         # 3. Finish the upload
         curl -sf -X POST -H "$AUTH" $API/releases/$RELEASE/finish
   
         # 4. Save the notes; StoreFast shortens and translates them
         curl -sf -X POST -H "$AUTH" -H 'Content-Type: application/json' \
           --data "$(jq -n --rawfile notes RELEASE_NOTES.md '{english: $notes, summarize: true, platform: "windows"}')" \
           $API/releases/$RELEASE/notes
   
         # 5. Submit for certification. Leave this out to review it in StoreFast first.
         curl -sf -X POST -H "$AUTH" $API/releases/$RELEASE/submit
   
         # 6. Wait until the package is with Microsoft
         while true; do
           STATUS=$(curl -sf -H "$AUTH" $API/releases/$RELEASE | jq -r .status)
           echo "$STATUS"
           [ "$STATUS" = submitting ] || break
           sleep 15
         done
         [ "$STATUS" = submitted ]
       displayName: Publish to the Microsoft Store with StoreFast
       env:
         STOREFAST_API_KEY: $(STOREFAST_API_KEY)

4. 4

   Decide who submits

   Without the submit call, the release waits on your app's page in StoreFast with the package uploaded and the notes translated, and you click Submit when it looks right. Keep the call when you trust the pipeline.

With summarize on, notes like a changelog are rewritten into a short What's new of about 1,150 characters, and platform windows leaves out changes that only affect other platforms. Every endpoint, field and error is in the API reference.

Errors you might see

Which should you use?

Who it's for

Publishing from GitHub instead? The GitHub Actions guide has a one-step action. If you'd rather call Microsoft's API yourself, the submission API guide walks through every request.

Questions

Can an Azure DevOps pipeline publish the first version of my app?

No. Microsoft's msstore CLI docs say you reserve the app's name and create its first submission in Partner Center, including the age ratings questionnaire, and the Windows Store extension's setup page says it can only publish updates to existing apps. StoreFast has the same rule. After that first submission, a pipeline can publish every update.

Is the Windows Store extension for Azure DevOps deprecated?

Its Marketplace page doesn't say so. It's still listed by Microsoft, and it now comes in two versions: V0 for developers outside Microsoft, which signs in with a client secret, and V3 for Microsoft's own teams, which uses certificates or workload identity federation.

Do I need a Windows agent?

The msstore CLI runs on Windows, macOS and Linux, and the StoreFast pipeline in this guide only needs bash, curl and jq. You still need Windows to build the MSIX itself, so many pipelines build on windows-latest and publish from the same job.

Why does my msstore step show errors when it worked?

Azure DevOps marks every line a script writes to stderr as an error. The msstore CLI's README says to send its readable output to stdout with --output-stream stdout, or to set the MSSTORE_OUTPUT_STREAM variable to stdout for the whole job.

Can I check the update before it goes to Microsoft?

With StoreFast, yes. Leave out the submit call and the release waits on your app's page in StoreFast with the package uploaded and the notes translated, and you click Submit when it looks right.