Microsoft Store Publisher

Microsoft Store Publisher

Use this skill when the user wants to publish a Windows application to the Microsoft Store, create or validate an MSIX, complete a Partner Center submission, respond to certification findings, or monitor publishing status.

This skill is for Windows desktop applications, including packaged classic Win32 apps that use runFullTrust. It is based on a successful end-to-end submission using Partner Center, an unsigned Store MSIX, the Windows App Certification Kit, and browser automation against Partner Center's current web components.

Required safeguards

Treat Partner Center as a production publishing system.

1. Never accept the Microsoft Application Developer Agreement or another binding agreement without fresh, action-specific user confirmation.
2. Never press Submit for certification without fresh, action-specific user confirmation after every section is complete and the final package is validated.
3. Never cancel certification, delete a submission, change pricing, change market availability, publish manually, or send Partner Center feedback without confirmation for that exact action.
4. Never enter, retrieve, print, save, or expose passwords, passkeys, tokens, recovery codes, MFA codes, or payment information. Let the user complete credential and operating-system authentication prompts.
5. Do not use the user's everyday browser profile for automation. Use a dedicated persistent profile and let the user authenticate interactively.
6. Do not infer legal, trademark, patent, privacy, export-control, or open-source compliance. Identify the concern and state when professional review is prudent.
7. Do not claim WACK passed from an exit code alone. Find and read the generated report and verify its overall result.
8. Do not upload a package until its identity, publisher, display name, architecture, version, and signing state have been inspected.

Files in this skill

• references/submission-playbook.md - complete submission sequence.
• references/msix-checklist.md - package and manifest requirements.
• references/partner-center-dom.md - known routes, text, roles, custom elements, selectors, and automation quirks.
• references/worked-example.md - concrete lessons from a successful full-trust desktop app submission.
• scripts/partner-center-control.mjs - Playwright controller for a dedicated Edge profile.
• scripts/inspect-msix.ps1 - unpack and inspect an MSIX before upload.
• scripts/invoke-wack.ps1 - run WACK, then find, verify, and save its XML and HTML reports.
• templates/run-full-trust-rationale.md - restricted-capability explanation.
• templates/certification-notes.md - tester instructions.
• templates/store-listing.md - listing content worksheet.
• templates/submission-record.json - durable identity, package, validation, and certification handoff record.

Read the relevant reference before performing that phase. Do not rely on remembered Partner Center labels because Microsoft changes the UI.

End-to-end workflow

1. Establish scope and readiness

Collect or determine:

• Application name and reserved Store product name.
• Repository and build command.
• Application version and intended MSIX version.
• Supported architectures and minimum Windows version.
• Whether the app is WinUI, UWP, packaged Win32, Electron, Wails, Tauri, .NET, or another desktop technology.
• Native executables, helper processes, services, drivers, startup tasks, protocol handlers, file associations, codecs, and restricted capabilities.
• Privacy policy, support URL, website, licensing, notices, and corresponding source obligations.
• Real device and network requirements for certification.
• The Microsoft account the user wants selected during sign-in.

Inspect the repository before proposing package changes. Search for existing manifest templates, package scripts, signing scripts, app icons, version sources, privacy documents, third-party notices, and startup behavior.

2. Reserve the product and capture identity

In Partner Center, reserve an available product name. Avoid trademarked terms in the product name unless the user has a documented right to use them.

After reservation, capture the exact values under:

Product management > Product identity

• Store product ID
• Package identity name
• Publisher ID, usually a CN=... value
• Publisher display name
• Package family name
• Reserved product display name
• Public Store URL

Never guess these values. The MSIX must use the Partner Center values exactly.

3. Build the Store package

Follow references/msix-checklist.md.

Important defaults:

• A Microsoft Store submission MSIX should be unsigned. Microsoft signs it after certification.
• A package distributed outside the Store must be signed with a certificate whose subject exactly matches the manifest publisher.
• The fourth version component must be 0 before Store submission because it is reserved for Microsoft.
• The first version component must be nonzero.
• Package/Properties/DisplayName must exactly match a reserved product name. Matching only the application's visual display name is not sufficient.

Prefer a repeatable build script that:

1. Validates input versions and identity values.
2. Builds or receives the production executable.
3. Stages the manifest, executable, assets, licenses, privacy information, notices, and source links.
4. Packs with makeappx.exe.
5. Unpacks the generated MSIX into a verification directory.
6. Verifies the unpacked executable hash.
7. Emits a JSON receipt with identity values and SHA-256 hashes.

4. Inspect and test the MSIX

Run:

.\scripts\inspect-msix.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ExpectedIdentityName '<Partner Center identity name>' `
  -ExpectedPublisher '<Partner Center publisher ID>' `
  -ExpectedDisplayName '<reserved product name>'

The script belongs to this skill directory, not necessarily the application repository. Resolve its full path before invoking it.

Install and exercise the packaged app under real package identity when possible. Test:

• First launch and upgrade.
• Startup tasks and persisted settings.
• Helper process launch.
• Tray behavior and clean exit.
• Network discovery and firewall behavior.
• File and registry access under package identity.
• Uninstall and data retention behavior.
• Restricted capability behavior.

5. Run WACK

Run:

# Run this command from an elevated PowerShell terminal.
.\scripts\invoke-wack.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ReportPath '<artifact-directory>\WACK-report.xml'

The WACK command-line runner requires elevation. The model must not approve the operating-system authentication prompt for the user.

WACK accepts a report path only when it ends in .xml. Any other extension fails with exit code -1 and The report output file path should point to a XML file. Current kits write the XML report to the requested path and an HTML rendering of it to %LOCALAPPDATA%\Microsoft\AppCertKit\<same base name>.htm. One earlier run left only an HTML report in that folder and no XML report.

The script:

• Always passes WACK an .xml path. A -ReportPath ending in .htm or .html names the saved HTML report, and the XML report is saved beside it with the same base name.
• Uses the XML report from this run at the requested path, or else the newest WACK report in %LOCALAPPDATA%\Microsoft\AppCertKit. It skips files from earlier runs and the unrelated XML files WACK keeps in that folder, and keeps waiting while the report is still an unfinished interim report.
• Pairs the HTML report with the XML report by report time, then saves both beside -ReportPath.
• Reports the XML OVERALL_RESULT the way the HTML report shows it: PASS is PASSED, FAIL is FAILED, WARNING is PASSED WITH WARNINGS, and an interim report is INCOMPLETE. The HTML result is used only when there is no XML report.
• Fails when the result is not PASSED, not every test ran, the XML and HTML reports disagree, appcert.exe exited with an error, or the report's package identity name or version does not match the package. For a bundle, it warns instead, so check the name and version by hand.
• Lists every test that did not pass in nonPassingTests, with WACK's messages for it. An HTML-only result leaves this list empty.

When it finds a report, the script prints a JSON summary, then throws if passed is false. Do not continue to submission unless passed is true. PASSED WITH WARNINGS is not PASSED: fix the tests it names and rerun WACK. Read every entry in warnings. Optional test failures do not block Store onboarding, but investigate them.

Record the result in the submission record: overallResult as wack.result, xmlReport as wack.reportPath, kitVersion as wack.kitVersion, and reportTime as wack.testedAt. When resultSource is html, use htmlReport as the report path and copy the kit version and report time from the HTML report's header.

To parse and verify an existing report without running WACK again:

.\scripts\invoke-wack.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ReportPath '<artifact-directory>\verified-WACK-report.xml' `
  -ExistingReportPath '<existing-WACK-report.xml>'

Pass an .htm report only when no XML report exists. Given an XML report, the script looks for the HTML report with the same base name, beside it or in %LOCALAPPDATA%\Microsoft\AppCertKit, and uses it when the report times match. Given an HTML report, it uses the XML report beside it when the two match.