Pin Microsoft.WindowsAppSDK.Base to calendar-scheme version to fix N…

[v-arlysenko]

…U1605

Foundation's Version.Details.xml pinned Microsoft.WindowsAppSDK.Base at 2.0.3-dev.experimental1 (new SemVer scheme), but WindowsAppSDKAggregator has temporarily reverted Base to the pre-SemVer calendar scheme (2.0.260323000-dev.experimental9) while feeders (LiftedIXP/DCPP, WinUI lift, DWriteCore) ship transports built against the new scheme.

Because the new-scheme version (2.0.3-...) is numerically lower than the calendar-scheme floors baked into feeders' transport nuspecs (e.g. 2.0.260223001-experimental), NuGet detected a downgrade and the Foundation nightly + every Maestro PR validation built against main were failing with NU1605 in BuildSampleApps_x64 / BuildSampleApps_arm64.

Sync Foundation's pin to match Aggregator's so the consumed Base is consistent with what feeders' nuspecs require. Revert to the new SemVer scheme once Aggregator does.

Tracking: AB#62180574

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

[alexlamtest]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[agniuks]

we shouldn't need this anymore, we put the pin in place a month ago at this point - the component repos should have updated by now, what's holding that up? The real fix would be to unpin aggregator and update all of the components.

Let's at least understand what component is blocking so we can escalate - Foundation only has a dependency on IXP, Base, and Closed.

[agniuks]

IXP version looks extremely outdated, "260419" that might be the culprit

[agniuks]

here: #6430
FYI about Maestro PRs in Foundation in case that wasn't on your radar.

[v-arlysenko]

Thanks, nice catch!

[agniuks]

IXP update merged in, let's see how the next nightly looks.

[alexlamtest]

Yeah, agreed that we should wait and see if unblocking the Maestro PR fixes the bug. Thanks!

[v-arlysenko]

@agniuks — you were right on both counts. The blocking component is IXP/DCPP;
Base and Closed are not at fault. Closing #6515 as the wrong direction.

Confirmed: IXP is the culprit

The IXP packages Foundation consumes were built at DCPP commit
a007e3a86ec33bad02efd987d6a4617e36c78c59 (April 19). At that SHA,
DCPP's eng/Version.Details.xml had:

<Dependency Name="Microsoft.WindowsAppSDK.Base"
            Version="2.0.260223001-experimental">

That calendar-scheme floor is baked into the IXP transport nuspec via the
$BaseComponentVersion$ placeholder, and it's exactly the version showing
up in every Foundation NU1605:

Unpackaged -> Microsoft.WindowsAppSDK.Foundation
                -> Microsoft.WindowsAppSDK.InteractiveExperiences 3.0.0-experimental-Rolling.20260419.2
                -> Microsoft.WindowsAppSDK.Base (>= 2.0.260223001-experimental)
Unpackaged -> Microsoft.WindowsAppSDK.Base (>= 2.0.3-dev.experimental1)

Ruled out: Base and Closed are not at fault

• Base: I scanned all 123 NU1605 occurrences in the latest failed
  Foundation nightly (build 148041848). The downgraded package is
  always Microsoft.WindowsAppSDK.Base — but Base itself is the
  victim of the floor coming from IXP, not the source of the conflict.
• Closed (WindowsAppSDK.AppLicensingInternal.TransportPackage,
  Foundation's pinned SHA f52676312e...): at that commit, Closed only
  depends on Microsoft.FrameworkUdk — no direct WindowsAppSDK.Base
  dependency. Zero appearances in NU1605 chains.

Wrinkle: why "just bump IXP forward" isn't a one-line fix

DCPP main HEAD now consumes Base 2.0.6-dev.experimental1 (SemVer —
they finished their migration). However, all 34 successful
LiftedIXP-Official (OneBranch) builds since April 20 publish
2.0.0-stable-* / 2.0.15. DCPP no longer publishes
3.0.0-experimental-* packages. Foundation main is pinned to
3.0.0-experimental-Rolling.20260419.2, which is an orphaned channel —
Maestro can't flow anything forward because nothing new ships on it.

By NuGet semver, 3.0.0-experimental-... > 2.0.0-stable-..., so a
naive Foundation bump to the new versions would be a major-version
downgrade and would likely create new NU1605 errors elsewhere
downstream (Aggregator and friends).

Asks for your input

1. Is jumping Foundation from 3.0-experimental to 2.0-stable IXP
   actually the intended path, or is there a different IXP channel we
   should be on?
2. Are there known API-compat issues between those IXP versions that
   would need Foundation code changes alongside the version bump?
3. Should I drive this directly, or do you want to align with IXP team
   first / loop in an owner?

Tracking: AB#62180574. Closing #6515 now.