Remove dead PackageReferences from the C++ VSIX extension project - #6741
Conversation
The Cpp Dev17 VSIX project carried four PackageReferences declared as
`GeneratePathProperty="true"` with `<ExcludeAssets>All</ExcludeAssets>`. That
combination flows no compile/runtime/build assets, so the only thing such a
reference produces is its `$(Pkg<Id>)` path property. None of the four
properties is referenced anywhere in the repo:
PkgMicrosoft_WindowsAppSDK 0 uses
PkgMicrosoft_Windows_CppWinRT 0 uses
PkgMicrosoft_Windows_SDK_BuildTools 0 uses
PkgMicrosoft_Windows_ImplementationLibrary 0 uses
(The only Pkg* property actually consumed under dev/Templates is
PkgNuget_VisualStudio, for the NuGet.VisualStudio.dll ExtensionDependencies
item.) So all four only cost a package download per build and contribute
nothing to the produced .vsix.
The Microsoft.WindowsAppSDK one also made the mono-build's CreateVSIX stage
download the public 1.6.250408002 metapackage - an April 2025 release - on every
run of a stage that is otherwise building 2.x bits. It was declared in
Directory.Packages.props under "External Package Versions" as a bare literal,
not via the WindowsAppSDKVersionPinned pattern the internal packages use, so
nothing could ever update it.
Removing that reference orphans the corresponding CPM entries, so drop them too:
the "Self-Reference" ItemGroup and the MicrosoftWindowsAppSDKVersion property.
Deliberately NOT touched:
* MicrosoftWindowsAppSDKVersionPackageVersion (1.8.0) - a different, similarly
named property that BuildAll.ps1 reads for pipeline version metadata.
* test/ABForward and test/TestApps/StoragePickersTestApp - they pin
1.6.250408002 through packages.config, which does not go through CPM, so
the compat-test self-reference those exist for is unaffected.
* The dev/Templates/Source/ProjectTemplates ProjectTemplate.csproj files -
template payload, versioned by the $WindowsAppSdkVersion$ token, never
restored by this build.
* The same dead Microsoft.Windows.SDK.BuildTools pattern in the sibling
Cs Dev17 project - left for a separate change.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
Validation: build 157025355 — succeeded
Restore and build are unaffected by the removal: All four The stale restore is gone. Baseline run 156949558 had: That line no longer appears. Scanning every task log for installs of the four formerly-referenced packages, the only remaining one is: which comes from the sibling Remaining mentions of Component Governance scans source manifests, not just what the build restores, so it still picks the version up from Worth noting explicitly: CG detecting it is the honest signal. The 1.6 self-reference is genuinely still a declared dependency of the repo via those two test apps; this PR only stops the VSIX build from restoring it for no reason. If we want it gone from CG as well, retiring or re-pinning those two compat tests is the follow-up. |
|
Ported to Applied natively rather than cherry-picked: the VSIX project sits at That branch's If this PR takes review-feedback commits, #6742 needs re-diffing before either completes. |
Post-merge validation: build 157038503 — succeededClosing the gap I flagged earlier: the pre-merge validation only exercised
All jobs green — 4 Foundation arches + 4 MRT arches + AnyCPU + Pack: The removed CPM entry stranded nothing. Across 1035 task logs:
Version resolution is coherent — Note on the earlier failed attemptMy first attempt at this (157035704) failed, and it was my stage selection, not this change. I used That run also had 0 NU1010/NU1008, and the failing packages were internal ones this PR never touched — so it never implicated the change. Rebuilding Remaining coverage note: |
) Port of PR #6741 to release/dev/monobuild-2.0-stable. Applied natively rather than cherry-picked because the VSIX project lives at a different path on this branch: dev/VSIX/Extension/Cpp/Dev17/ here versus dev/Templates/VSIX/Extension/Cpp/Dev17/ on release/dev/monobuild. The file contents are byte-identical, so the resulting diff matches the source PR exactly: 0 insertions / 12 deletions in the csproj and 0 / 6 in Directory.Packages.props. The defect is present on this branch identically. The Cpp Dev17 VSIX project carried four PackageReferences declared GeneratePathProperty="true" with <ExcludeAssets>All</ExcludeAssets>. That combination flows no 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: PkgMicrosoft_WindowsAppSDK 0 uses PkgMicrosoft_Windows_CppWinRT 0 uses PkgMicrosoft_Windows_SDK_BuildTools 0 uses PkgMicrosoft_Windows_ImplementationLibrary 0 uses PkgNuget_VisualStudio 2 uses <- the one that IS used, kept The Microsoft.WindowsAppSDK one pinned the public 1.6.250408002 metapackage, an April 2025 release, declared as a bare literal under "External Package Versions" rather than through the WindowsAppSDKVersionPinned pattern the internal packages use, so 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) - a different, similarly named property that BuildAll.ps1 reads for pipeline version metadata. * test/ABForward/packages.config, which pins 1.6.250408002 through packages.config. That does not resolve via Central Package Management, so the compat-test self-reference the deleted ItemGroup 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. This branch's Directory.Packages.props legitimately diverges from release/dev/monobuild in its fallback literals (Base 2.0.4, FrameworkUdk 2.0.0-stable-27200.1029.260616-0840.3, and so on). None of those were touched - only the two orphaned self-reference entries were removed.
2 participants
Removes four
PackageReferenceentries from the C++ Dev17 VSIX extension project that produce nothing, and the CPM entries that only existed to version one of them.What is dead about them
All four were declared as:
ExcludeAssets=Allflows no compile, runtime, build, native, contentfiles or analyzer assets. The only thing such a reference can contribute is the$(Pkg<Id>)path property thatGeneratePathProperty="true"creates. None of the four properties is referenced anywhere in the repository:PkgMicrosoft_WindowsAppSDKPkgMicrosoft_Windows_CppWinRTPkgMicrosoft_Windows_SDK_BuildToolsPkgMicrosoft_Windows_ImplementationLibraryFor contrast, the one path property this project does use is
PkgNuget_VisualStudio, consumed two lines below by theExtensionDependenciesitem that pullsNuGet.VisualStudio.dllinto the VSIX. That reference is untouched.So the four cost a package download on every build and contribute nothing to the produced
.vsix.Why the WindowsAppSDK one matters more than the others
It is a self-reference, and it was pinned to the public 1.6.250408002 metapackage — an April 2025 release. It was declared in
Directory.Packages.propsunder "External Package Versions", next to WebView2 and TAEF, as a bare literal:Note it was not in the
IsInternal="true""WindowsAppSDK Packages" group and not expressed via the$([MSBuild]::ValueOrDefault('$(WindowsAppSDKVersionPinned)', ...))pattern the internal packages use. Nothing could ever update it, by construction.The visible symptom: the Windows App SDK mono-build's
CreateVSIXstage downloads a 1.6 metapackage on every run while building 2.x bits —Nothing consumed it, so no 1.6 content ever entered the shipping
.vsix, but it is confusing to anyone auditing where package versions come from, and it is a stale public dependency recorded against a shipping component.Removing the reference orphans its CPM entries, so this also drops the
Self-ReferenceItemGroupand theMicrosoftWindowsAppSDKVersionproperty.Deliberately not touched
MicrosoftWindowsAppSDKVersionPackageVersion(1.8.0, line 32). Confusingly similar name, completely different purpose —BuildAll.ps1reads it for pipeline version metadata. Left alone.test/ABForwardandtest/TestApps/StoragePickersTestApp. These pin1.6.250408002throughpackages.config, which does not resolve through Central Package Management, so the compat-test self-reference the deletedItemGroupcomment referred to is unaffected by this change.dev/Templates/Source/ProjectTemplates/**/ProjectTemplate.csproj. Template payload, versioned by the$WindowsAppSdkVersion$token that gets substituted at template instantiation. Never restored by this build — they carry an explicitVersion=, which would be an NU1008 error under CPM if they were.Microsoft.Windows.SDK.BuildToolspattern in the siblingWindowsAppSDK.Cs.Extension.Dev17.csproj. Same analysis applies, but it is not part of the issue that prompted this, so it is left for a separate change.Validation
Windows App SDK mono-build nightly (def 190463),
CreateVSIXstage only, with the Foundation repo resource overridden to this branch and everything else reused from a known-good full run:useBuildOutput_RebuildStage=CreateVSIX,useBuildOutput_BuildId=156949558resources.repositories.WindowsAppSDKFoundation.refName= this branch, resolved at5027d617Build: https://dev.azure.com/microsoft/OS/_build/results?buildId=157025355&view=results
Checking that restore still succeeds without the four references, all four
.vsixfiles still build and sign, and1.6.250408002no longer appears in the logs. Result posted below.