[2.0-stable port] Remove dead PackageReferences from the C++ VSIX extension project

[Kyaw Thant (kythant)]

Port of #6741 to release/dev/monobuild-2.0-stable.

The source PR is still in review — re-diff against #6741 before either completes if it takes review-feedback commits.

Applied natively rather than cherry-picked because the VSIX project lives at a different path on this branch:

• here: dev/VSIX/Extension/Cpp/Dev17/WindowsAppSDK.Cpp.Extension.Dev17.csproj
• release/dev/monobuild: dev/Templates/VSIX/Extension/Cpp/Dev17/...

The file contents are byte-identical, so the resulting diff matches the source exactly: 0 insertions / 12 deletions in the csproj and 0 / 6 in Directory.Packages.props.

The defect is present here identically

The Cpp Dev17 VSIX project carried four PackageReference entries declared GeneratePathProperty="true" with <ExcludeAssets>All</ExcludeAssets>. That combination flows no compile, runtime, build, native, contentfiles or analyzer assets, so the only thing such a reference produces is its $(Pkg<Id>) path property — and none of the four is referenced anywhere on this branch:

Path property	Uses (case-insensitive, repo-wide)
PkgMicrosoft_WindowsAppSDK	0
PkgMicrosoft_Windows_CppWinRT	0
PkgMicrosoft_Windows_SDK_BuildTools	0
PkgMicrosoft_Windows_ImplementationLibrary	0
PkgNuget_VisualStudio	2 — the one that is used, kept

So the four only cost a package download per build and contribute nothing to the produced .vsix.

Why the WindowsAppSDK one matters most

It is a self-reference pinned to the public 1.6.250408002 metapackage — an April 2025 release — declared in Directory.Packages.props under "External Package Versions" as a bare literal, not via the $([MSBuild]::ValueOrDefault('$(WindowsAppSDKVersionPinned)', ...)) pattern the internal packages use. Nothing could ever update it.

Removing the reference orphans its CPM entries, so the Self-Reference ItemGroup and the MicrosoftWindowsAppSDKVersion property go too. After the change no PackageReference to the metapackage remains anywhere in the repo, so the CPM entry cannot be needed.

Deliberately not touched

• MicrosoftWindowsAppSDKVersionPackageVersion (1.8.0) — confusingly similar name, different purpose: BuildAll.ps1 reads it for pipeline version metadata.
• test/ABForward/packages.config, which pins 1.6.250408002. packages.config does not resolve through Central Package Management, so the compat-test self-reference the deleted comment referred to is unaffected. (This branch has only that one such test; release/dev/monobuild also has test/TestApps/StoragePickersTestApp.)
• The same dead Microsoft.Windows.SDK.BuildTools pattern in the sibling Cs Dev17 project — left for a separate change, as on the source PR.

Branch divergence preserved

This branch's Directory.Packages.props legitimately differs from main-line in its fallback literals — Base 2.0.4, FrameworkUdk 2.0.0-stable-27200.1029.260616-0840.3, IXP 2.0.16-stable-Rolling.20260617.1, AppLicensing 2.0.0-stable.20260423.1. None were touched; only the two orphaned self-reference entries were removed. A file copy from main-line would have silently reverted every one of them.

Validation

• raw numstat == -w numstat on both files — pure deletions, no whitespace churn.
• Blob-exact line-ending census, both files unchanged in kind: Directory.Packages.props 131 → 125 LF (0 CRLF), csproj 247 → 235 LF (0 CRLF).
• No remaining PackageReference Include="Microsoft.WindowsAppSDK" in any .csproj / .vcxproj / .props / .targets / .proj, so the removed PackageVersion cannot strand a versionless reference (NU1010).

On the source PR, mono-build 157025355 rebuilt CreateVSIX against the branch and succeeded — all four .vsix files built and signed, and Installed Microsoft.WindowsAppSDK 1.6.250408002 no longer appears. A second run covering the other consumers of this CPM file (BasePackage + Foundation) is in flight there. The code here is identical, so those results carry over; the 2.0 mono-build consumes this branch via FoundationBranch defaulting to release/dev/monobuild-2.0-stable.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Kyaw Thant (kythant)]

The source PR (#6741) is now merged as 924cfdd6, and I re-diffed this port against what actually landed: the Directory.Packages.props delta is identical, so this port carries no drift.

Post-merge validation on the source side (157038503) rebuilt the Foundation stage against the merged commit and passed: all 4 Foundation arches + 4 MRT arches + AnyCPU + Pack green, and across 1035 task logs 0 failed tasks, 0 NU1010/NU1008, 0 'Unable to find version'. NU1010 is the specific error a removed \PackageVersion\ would cause if a versionless \PackageReference\ were left stranded — zero occurrences confirms none is.

The code here is identical apart from the dev/VSIX/ vs dev/Templates/VSIX/ path, so that evidence carries over. This branch is consumed by the 2.0 mono-build via \FoundationBranch\ defaulting to
elease/dev/monobuild-2.0-stable.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Kyaw Thant (kythant)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.