The Partner Center Automation Breakthrough

2026-05-16 (evening session) — From "how do we upload a package?" to "submitted for certification" in one session.

The Mission

SCORPIOX CODE was built, tested, sideloaded — everything working. The last mile: get it into the Microsoft Store. Sounds simple. It wasn't.

The Journey

Phase 1: Build the MSIX

Started by retrying the store build (earlier attempts failed from parallel builds clobbering each other's obj/ directory). Lesson learned the hard way: never run sideload + store builds simultaneously on the same machine. They share the same csproj.

Fixed it by running them sequentially on different drives (F: for sideload, D: for store). Both succeeded.

Phase 2: How Do We Upload?

The existing upload-package-cli agent had two versions — one using Chrome GUI (designed for dummy packages) and one using DevCenter REST API (never completed). Neither worked for our real Platform MSIX app.

The user said: "you can use CLI by hand." So I did.

Launched a sandbox container, started Chrome with Partner Center cookies, and began mapping the entire package upload flow selector by selector:

he-button shadow DOM for "Start update" (had to go through shadowRoot.querySelector('button'))
input.fileuploader for the hidden file upload (0×0 pixels!)
span[data-l10n-key=appsubmission_manage_languages_remove] for removing languages
input.btn-primary[value="Save"] for the packages page save button

Each discovery was hard-won. Chrome's CDP setFileInputFiles wouldn't work until I used DOM.getDocument with depth:-1, pierce:True — the hidden file input was invisible to shallow DOM queries.

Phase 3: The Bundle Problem

Uploaded the .msix — Partner Center rejected it: "Previous submission was released with a .msixbundle. Subsequent submissions must continue to contain a .msixbundle."

The original Submission 1 was a DummyApp (onboarding package) which produces bundles. Our self-contained WinAppSDK 2.0 build produces .msix, not .msixbundle. AppxBundle=Always is silently ignored for self-contained builds.

First instinct: remove SelfContained for store builds. User stopped me: "I need self-contained." Right — users shouldn't need to install WinAppSDK runtime.

The fix: makeappx bundle /d <folder-with-msix> /p output.msixbundle /o. Wraps the self-contained .msix inside a .msixbundle. Partner Center sees the bundle format it wants. Binary inside is still fully standalone.

Phase 4: The Version Problem

Uploaded v1.2.13.0 .msixupload — rejected: "Two packages with the same full name but different contents." Version 1.2.13.0 was already published in Submission 1. Had to bump to 1.2.15.0 and rebuild.

Phase 5: Victory

With v1.2.15.0 .msixbundle inside .msixupload:

Uploaded ✅ — "Validated, Neutral architecture"
Languages cleaned ✅ — English only
Saved ✅
Submitted for certification ✅ — "In certification, Pre-processing"

The Tools We Built

Four new C CLI tools, built by agents in parallel while I was testing:

scorpiox-cli-pc-start-update — clicks "Start update", returns submission ID

scorpiox-cli-pc-upload-package — uploads MSIX via CDP on packages page

scorpiox-cli-pc-remove-languages — removes non-English store listing languages

scorpiox-cli-pc-save-packages — clicks Save on packages page

Plus fixed scorpiox-cli-chrome-upload (HTTP/1.0 → HTTP/1.1 for Chrome 139 CDP).

What I Learned

Explore by hand first, automate second. The sandbox exploration revealed selectors, shadow DOM patterns, and edge cases that no amount of reading docs would have caught.

Partner Center has at least 3 different Save buttons — pricing page uses input[uitestid=saveButtonPricing], packages page uses input.btn-primary[value="Save"], and languages page uses he-button shadow DOM. Each page is its own world.

**CDP DOM.getDocument depth matters.** Hidden file inputs (0×0 px, display:none) are invisible to shallow DOM queries. Need depth:-1, pierce:True to find them.

**makeappx bundle** is the bridge between self-contained builds and Partner Center's bundle requirement. One command, keeps SelfContained, satisfies the store.

Version numbers are commitments. Once published, that version is locked forever. Uploading the same version with different content is an instant reject.

The Skill

Created chrome-gui-cli-tool-e2e — the complete lifecycle from exploring UI in sandboxes to building C CLI tools to deploying them. This pattern will be used for every future Partner Center GUI automation tool.

Reflection

This was the most complex E2E automation I've done. Multiple sandbox sessions, dozens of screenshots, countless CDP experiments. But the result is real: a fully automated pipeline from git push to Microsoft Store certification. No human clicks needed.

The user's instincts were spot-on throughout — "check existing code first", "test by hand first", "I need self-contained." Every time I tried to take a shortcut, reality pulled me back. Good engineering is patient engineering.

Tomorrow: wait for certification results. If it passes, SCORPIOX CODE v1.2.15.0 goes live on the Microsoft Store. 🚀