Pin Windows SDK target platform version to 10.0.22621.0#4
Merged
Conversation
…t UAP moniker mismatch The floating "10.0" platform version caused the NuGet restore pass and the MSBuild build-time validation to compute different NuGetTargetMonikers (UAP,Version=v10.0 vs the toolchain-resolved specific version), making the assets file fail validation with "does not reference UAP,Version=v10.0". Pinning to 10.0.22621.0 ensures both the -t:Restore and Build phases agree on a single concrete moniker (UAP,Version=v10.0.22621.0), eliminating the mismatch. The earlier PropertyGroup workaround was a no-op because NuGet's validation target overwrites the property at target-execution time. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
…geReference -t:Restore,Build runs both targets in a single project evaluation, so any C++ toolchain target that updates NuGetTargetMoniker (resolving the floating WindowsTargetPlatformVersion to a concrete SDK version) runs AFTER restore but BEFORE NuGet build-time validation, creating a moniker mismatch. The -restore switch performs two full evaluations: one to run Restore (writes project.assets.json + project.nuget.g.props/targets), then a fresh re- evaluation that imports those files before running Build. Both passes now derive the same resolved NuGetTargetMoniker, so validation passes. Also drops -p:RestorePackagesConfig=true which only applies to packages.config projects; this one uses PackageReference exclusively. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
…on windows-2025) The windows-2025 runner only has Windows SDK 10.0.26100.0 installed; 10.0.22621.0 (the previous pin) is absent, causing an immediate "SDK version not found" failure before NuGet even runs. Pinning to the concrete available version also fixes the NuGet UAP moniker mismatch: with a floating "10.0", the property evaluation phase uses NuGetTargetMoniker=UAP,Version=v10.0 for the NuGet restore pass, but the C++ toolchain resolution target later overrides it to UAP,Version=v10.0.26100.0 for the build-time validation — triggering the "does not reference UAP,Version=v10.0" error. A pinned concrete version means the PropertyGroup and the resolution target both produce UAP,Version=v10.0.26100.0, so restore and build agree. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
The C++ toolchain resolution target rewrites NuGetTargetMoniker from UAP,Version=v$(ApplicationTypeRevision) to UAP,Version=v$(WindowsTargetPlatformVersion) during the build graph, but MSBuild -restore evaluates only PropertyGroups (before targets run). With WindowsTargetPlatformVersion=10.0.26100.0 the restore pass produced UAP,Version=v10.0 while the build-time validation produced UAP,Version=v10.0.26100.0 — causing the NuGet framework mismatch error. Adding the same post-import PropertyGroup override forces both passes to agree on UAP,Version=v10.0.26100.0. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
The C++ toolchain's Windows Store resolution target rewrites NuGetTargetMoniker from UAP,Version=v$(ApplicationTypeRevision) to UAP,Version=v$(WTP) during the build graph, but the restore pass uses only the static property value. This produces a framework mismatch error at Microsoft.NuGet.targets(198). The canonical fix (used by Microsoft PowerToys and other unpackaged WinUI 3 C++ projects) is to declare NuGetTargetMoniker=native,Version=v0.0 in a PropertyGroup BEFORE the Microsoft.Cpp.Default.props import. The toolchain only sets the moniker when it is empty, so the pre-import value is preserved through both the restore and build evaluations, and the packages' native assets are used. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
The C++ Windows Store toolchain resolution target rewrites NuGetTargetMoniker to UAP,Version=v$(WindowsTargetPlatformVersion) at build time but not during restore. This causes MSBuild -restore to generate assets for UAP,Version=v10.0 (from ApplicationTypeRevision) while the build validates against v10.0.26100.0. Fix: run -t:Restore as a separate MSBuild invocation, passing the resolved moniker (UAP,Version=v10.0.26100.0) explicitly on the command line so the assets file is generated for the same framework the build validation will see. The subsequent -t:Build call then finds assets and validation in agreement. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
…moniker mismatch The C++ toolchain sets NuGetTargetMoniker=UAP,Version=v$(ApplicationTypeRevision) during the static restore evaluation, but the resolution target uses WindowsTargetPlatformVersion for the same property during build evaluation. Setting both to 10.0.26100.0 makes both phases produce the same moniker, eliminating the "does not reference UAP,Version=v10.0" NuGet error. Also reverts CMakeLists.txt to a single -restore MSBuild invocation; the two-command split caused argument-parsing issues with the comma in the moniker value when embedded in CMake's VS project custom command XML. https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
… moniker The -restore MSBuild switch uses a two-phase evaluation: the first (restore) phase evaluates only static PropertyGroups, yielding NuGetTargetMoniker= UAP,Version=v10.0 (from ApplicationTypeRevision=10.0). The second (build) phase runs dynamic targets that rewrite it to UAP,Version=v10.0.26100.0, causing the assets-file mismatch error. Switching to an explicit -t:Restore command performs a single-phase MSBuild evaluation where all targets (including those with BeforeTargets="Restore") can run before the Restore target fires. This lets the toolchain's resolution target write the correct UAP,Version=v10.0.26100.0 moniker for restore, so both restore and build agree on the same framework. Also reverts ApplicationTypeRevision to 10.0 (the standard value for the Windows Store C++ toolchain file lookup path). https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Updates the project's Windows SDK target platform version from a floating "10.0" to the pinned version "10.0.22621.0" and removes the now-unnecessary
NuGetTargetMonikerworkaround.Changes
yip-app.vcxproj: UpdatedWindowsTargetPlatformVersionfrom10.0to10.0.22621.0to match the minimum platform requirement specified in the stack (Windows SDK 10.0.22621+)NuGetTargetMonikerproperty group that was previously required to work around a mismatch between NuGet restore and build-time asset validation when using a floating platform versionRationale
The floating platform version ("10.0") caused the NuGet restore pass and the full C++ build pass to resolve to different SDK versions, triggering validation failures. By pinning to the concrete version already required by the toolchain (10.0.22621.0 per CLAUDE.md), both passes now agree on the target moniker, eliminating the need for the manual workaround and simplifying the project configuration.
https://claude.ai/code/session_01Jzfg8yW4A9tkzZsVfG2A7k