Add MSIXVC2 upload support to PackageUploader.exe via MakePkg.exe

[Jason Williams (WilliamsJason)]

Summary

UploadXvcPackage now detects MSIXVC2 packages and delegates the upload to the MSIXVC2-capable MakePkg.exe, translating the operation config into MakePkg.exe command-line parameters. This is CHANGE 2 of a two-part GDK release work item.

There is no new verb and no new config switch — detection is driven off the package file itself, so an existing UploadXvcPackage config "just works" for an MSIXVC2 package. The legacy XVC1/MSIXVC1 upload path is untouched.

Rebased onto CHANGE 1 (#134)

This PR is rebased onto merged main and now consumes CHANGE 1's resolver directly. The placeholder is gone: Msixvc2CapabilityPlaceholder is deleted and both TODO(GDK-release) markers are removed.

src/PackageUploader.Application/Tools/IMsixvc2UploadToolProvider.cs remains as the narrow abstraction this PR consumes (IsAvailable, ExecutablePath), and Msixvc2ToolResolverAdapter implements it over PackageUploader.ClientApi.Tools.IMsixvc2ToolResolver. As designed, the swap was a single registration line in HostExtensions.ConfigureServices.

The adapter resolves with no path hints — pure self-discovery. The UI passes already-resolved paths because it has its own file pickers; the CLI has no such input. It honors the provider contract that the compiler cannot express here, this project having nullable reference types off:

• Resolve() returning null maps to IsAvailable == false and a null ExecutablePath, so "no capable tool" stays the clean, actionable error the operation already reports.
• Resolution happens exactly once and both members are served from that one result. The resolver deliberately does not cache and re-probes by launching a candidate executable on every call, so a two-call adapter would probe repeatedly per upload and could disagree with itself between reads. UploadMsixvc2PackageAsync reads the members three times, so this is not hypothetical. It is registered scoped, not singleton, so each operation gets a fresh resolution rather than one cached for the life of the process.
• Nothing escapes as an exception. The resolver is documented as never throwing; the catch is defense in depth, degrading to unavailable.

Verified against the real GDK, not only mocks. The legacy MakePkg.exe in the GDK bin directory fails the uploadsource probe, the resolver falls back to the makepkg2.exe shipped alongside it, and a live upload to branch JaswillTest completed and applied its availability date:

MakePkg.exe uploadsource probe: not supported (exit code 2) for C:\Program Files (x86)\Microsoft GDK\bin\MakePkg.exe.
makepkg2.exe uploadsource probe: supported (exit code 0) for C:\Program Files (x86)\Microsoft GDK\bin\makepkg2.exe.
Running C:\Program Files (x86)\Microsoft GDK\bin\makepkg2.exe upload /pd "..." /branch "JaswillTest" ...

The probe pair appears exactly once in that run, confirming the single resolution end to end.

Circular-dependency guard (two independent barriers)

MakePkg.exe shells back out to PackageUploader.exe for XVC1 uploads — the legacy makepkg.exe upload /? help says so in its own words: "Uploads a specified package to Partner Center via the PackageUploader tool." Delegating unconditionally would create infinite process recursion between the two executables.

Barrier 1 — package format detection. UploadXvcPackageOperation.ProcessAsync only delegates when the package is detected as MSIXVC2. This is driven off the package file, not a config flag, so it cannot be bypassed by configuration. Covered by NonMsixvc2Package_NeverShellsOut and MissingPackageFile_NeverShellsOut.

Barrier 2 — delegation breadcrumb. PackageFormatDetector.IsLikelyMsixvc2Package is a heuristic: its fallback check scans the trailing bytes for the 4-byte ZIP EOCD signature, which an encrypted XVC1 tail can contain by chance. A false positive there would be unbounded. So Msixvc2ProcessRunner stamps PACKAGEUPLOADER_MSIXVC2_DELEGATED=1 onto every MakePkg.exe child process, and Msixvc2DelegationGuard refuses to delegate when that variable is already present in our own environment. Any MakePkg.exe that shells back to us inherits the stamp, so the cycle breaks after exactly one hop regardless of what the heuristic decides — it logs a warning and falls through to the normal upload path. Tested in both directions.

MakePkg.exe argument mapping

upload /pd "<directory of packageFilePath>"
       [/branch "<branchFriendlyName>" | /flight "<flightName>"]
       [/market "<marketGroupName>"]
       /storeid "<bigId>"
       /auth <method>
       [/tenantid "..."] [/clientid "..."]
       [/clientsecret "..." | /certthumbprint "..." [/certstore "..."] [/certlocation "..."]]
       [/resourceid "..."]

Every flag is now grounded in the verbatim help output of a real MSIXVC2-capable binary — makepkg2.exe upload /?, version 2604.405.14000.0, from C:\PackagingTest\Release\Tools\ — cross-checked against the two existing UI argument builders. The earlier "needs verification" section is resolved and removed.

Flag	Grounding
/pd	In makepkg2.exe upload /? and in PackageUploadViewModel.BuildMsixvc2UploadArguments() — the already-built-package scenario, which is what the CLI has. /d is the pack-from-a-loose-content-folder form.
no /msixvc2	/msixvc2 appears only in the /d (pack-and-upload) form. The /pd form in PackageUploadViewModel does not emit it, so neither do we.
/branch, /flight, /market, /storeid	Help output + both UI builders. Emitted in the same order as the UI.
/auth, /tenantid, /clientid, /clientsecret, /certthumbprint, /certstore, /certlocation, /resourceid	Help output, verbatim.
no /uploadsource	See below — deliberately dropped.

Correction: /uploadsource has been dropped

The previous revision emitted /uploadsource PackageUploader. That was flagged as unverified, and the flag check found it to be wrong. /uploadsource does exist, but probing its enum shows it accepts only makepkg2 and XGPM. There is no value representing PackageUploader, so the flag is now omitted entirely and the tool's own default is used. IMsixvc2UploadToolProvider.SupportsUploadSource and the probe behind it are removed.

Caveat: the MSIXVC2-capable binary available for verification is makepkg2.exe, not the renamed MakePkg.exe that ships with the upcoming GDK. The legacy makepkg.exe on the same machine is the pre-merge tool (it has /tenantid but no /auth, and returns exit 2 for supports uploadsource). Any statement about the renamed tool's surface is inferred from makepkg2's.

Authentication — non-interactive/CI auth is supported

The previous revision hard-failed every --Authentication value except CacheableBrowser, which would have made MSIXVC2 upload impossible from any unattended pipeline. That was based on the UI being the only grounding available; the real help output shows the tool accepts a full credential surface:

/auth <method>   Available methods: Default, Browser, CacheableBrowser, AzureCli, ManagedIdentity,
                 ManagedIdentityFederated, Environment, AzurePipelines, ClientSecret,
                 ClientCertificate. Default is CacheableBrowser.

So PackageUploader now forwards the configured identity rather than rejecting it.

--Authentication	Forwarded as	Note
AppSecret	/auth ClientSecret	PackageUploader's legacy name for the same AAD application-secret flow. AzureApplicationSecretAccessTokenProvider (MSAL confidential client) and ClientSecretCredentialAccessTokenProvider (Azure.Identity.ClientSecretCredential) take the same TenantId/ClientId/ClientSecret triple — a straight alias, not a behavior change.
AppCert	/auth ClientCertificate	Store-based certificate.
Default, Browser, CacheableBrowser, AzureCli, ManagedIdentity, ManagedIdentityFederated, Environment, AzurePipelines, ClientSecret, ClientCertificate	Same name	Verbatim from the help output.

The --TenantId hard-fail is also removed — /tenantid is a real flag.

Two configurations are still rejected, because the tool genuinely has no equivalent:

• Certificate file path (ClientCertificateAuthInfo:CertificatePath). The tool selects a certificate from a Windows store by thumbprint (/certthumbprint, /certstore, /certlocation) and exposes no flag naming a certificate file. Error message points at importing to a store and using AppCert.
• Certificate subject (AadAuthInfo:CertificateSubject). No subject flag exists; resolving the subject ourselves and forwarding a thumbprint would be guesswork about which certificate the user meant.

Security note: /clientsecret puts the secret on the child's command line, where anything that can read the process table can see it. PackageUploader redacts /clientsecret and /certpassword from its own logs, and the README recommends Environment, AzurePipelines, ManagedIdentity, or ManagedIdentityFederated on shared build agents.

Config option handling

Warn-and-ignore the harmless, hard-fail the meaningful:

Option	Behavior on the MSIXVC2 path
gameAssets — all paths resolve to the same directory as packageFilePath	Warn and continue. MakePkg.exe picks the assets up from the package folder.
gameAssets — any path resolves elsewhere	Hard-fail, naming the offending path and the expected directory. Silently dropping an asset the user deliberately placed elsewhere would change the outcome.
minutesToWaitForProcessing	Always warn and ignore. The default is 30 and an explicit 30 is indistinguishable, so treating it as an error would be unreliable.
deltaUpload	Warn and ignore.
availabilityDate / preDownloadDate	Supported, applied exactly as on the XVC1 path — see below.
productId without bigId	Resolved to the Big ID via GetProductAsync. Only fails if the lookup genuinely can't produce one.
--Authentication / --TenantId	Forwarded. See the authentication section above.

gameAssets is no longer [Required] on the attribute; the requirement is now enforced inside UploadXvcPackageOperationConfig.Validate() only when the package is not MSIXVC2, so XVC1 validation is unchanged. Both branches are tested.

How availabilityDate / preDownloadDate are applied

An earlier revision of this PR hard-failed these two options, on the premise that SetXvcConfigurationAsync needs the specific GamePackage that was just uploaded and that MakePkg.exe does not report that identity back. That premise was wrong, and it was the last true adoption blocker for MSIXVC2 on the CLI, so it was worth checking against the real tool rather than inferring.

A live upload shows MakePkg emitting Package Id is <guid> at info level — no /v required — early in the run, before the content transfer. And SetXvcConfigurationAsync only ever reads GamePackage.Id. That one line is the entire missing input.

• Msixvc2ProcessRunner now returns Msixvc2ProcessResult(ExitCode, UploadedPackageId) instead of a bare exit code.
• The capture is deliberately strict: an exact "Package Id is " marker plus Guid.TryParseExact(..., "D", ...). MakePkg prints several other ... is <guid> lines (Xfus Id, Draft Instance Id, CV, ingest job), so a looser marker would silently date the wrong package. Two conflicting ids in one run resolve to null rather than a guess.
• The operation does not trust the reported id. It looks it up via GetGamePackagesAsync for the target branch and market group. That lookup is required regardless — GamePackageResource.Id is internal init, so the Application cannot fabricate a GamePackage — but it doubles as proof the package belongs where the dates are being written. If the output format ever drifts, this fails loudly instead of quietly mis-dating.
• The date condition mirrors XVC1 exactly (is not null, not ?.IsEnabled == true), so a disabled date still calls through and clears a previously-set value.

Verified end to end: a real CLI upload to branch JaswillTest captured a760372c-8c3b-4d15-bdef-57449a7cb4a6 and set the configuration against it.

One caveat, called out in the README as a > [!NOTE]: because the dates are a post-upload step, a failure there does not undo the upload.

Shared MSIXVC2 detection

IsLikelyMsixvc2Package moves out of PackageUploader.UI/Model/Xvc/XvcFile.cs into PackageUploader.ClientApi/Packaging/PackageFormatDetector.cs — ClientApi being the only project referenced by both the UI and the Application. XvcFile.IsLikelyMsixvc2Package now delegates to it, so there is a single source of truth. Behavior is identical apart from an added null/whitespace path guard.

Child process handling

Msixvc2ProcessRunner mirrors the UI: UseShellExecute = false, CreateNoWindow = true, stdout/stderr redirected and streamed through the existing ILogger so console users see progress, the operation's CancellationToken is honored (the child process tree is killed on cancel), the child's exit code is propagated as the operation's success/failure, and PACKAGEUPLOADER_MSIXVC2_DELEGATED=1 is stamped on the child environment.

Tests

src/PackageUploader.Application.Test/Tools/:

• MSIXVC2 + capability available → shells out with the exact expected argument string (branch and flight forms).
• MSIXVC2 + capability unavailable → clear error, no shell-out.
• Non-MSIXVC2 package → never shells out (the circular-dependency guard), and takes the legacy ingestion path with identical calls and arguments.
• Missing package file → never shells out.
• Loop-breaker, both directions: sentinel absent → delegates; sentinel present → never shells out, logs a warning, and falls through to the legacy path. Plus direct unit tests of Msixvc2DelegationGuard against the environment variable.
• Auth: AppSecret → /auth ClientSecret with tenant/client/secret forwarded; AppCert → /auth ClientCertificate with thumbprint/store/location; AzurePipelines forwards the method with no credential flags; ManagedIdentityFederated forwards /resourceid; missing secret, missing thumbprint, certificate file path, and certificate subject each throw with an actionable message.
• Asserts /uploadsource is absent from the built arguments.
• Availability/pre-download dates: applied after a successful upload, skipped when unset, and hard-failing when MakePkg reported no usable id or the id is not in the target market group.
• Msixvc2ProcessRunnerTest drives a real child process to cover id capture, absence, non-GUID rejection, conflicting ids, and that other ... is <guid> lines are not mistaken for the package id.
• deltaUpload → warns and still shells out.
• Non-zero child exit code → operation fails.
• Cancellation → the operation token reaches the runner and the operation reports cancelled.
• productId-only config → resolves and passes the Big ID to /storeid; unresolvable → clear error.
• Asserts /msixvc2 is absent from the built arguments.

src/PackageUploader.ClientApi.Test/Packaging/PackageFormatDetectorTest.cs ports the detector coverage.

Validation

dotnet build src\PackageUploader.sln
  Build succeeded. 0 Warning(s) 0 Error(s)

dotnet test src\PackageUploader.Application.Test\PackageUploader.Application.Test.csproj
  Passed! total: 103, failed: 0

dotnet test src\PackageUploader.ClientApi.Test\PackageUploader.ClientApi.Test.csproj
  Passed! total: 77, failed: 0

dotnet test src\PackageUploader.UI.Test\PackageUploader.UI.Test.csproj
  Passed! total: 357, failed: 0