Add regression test for exclude filter on non-normalized TFMs

[mgnslndh]

This PR adds a regession test for the issue described in #1126. A fix is strictly not necessary since a recent change from NuGet.ProjectModel 7.0.1 to 7.6.0 solved the issue.

With NuGet.ProjectModel 7.0.1, LockFileTarget.Name was normalized (e.g. "net48" -> ".NETFramework,Version=v4.8") and no longer matched the raw projectFileDependencyGroups keys. No package was marked as a direct reference, so --exclude-filter removed every package as an orphan.

NuGet.ProjectModel 7.6.0 keeps the raw target name, which resolves the issue. Add a functional test using a real net48 project.assets.json to guard against a regression.

The test fails against 7.0.1 with 0 of 10 components remaining.

[mgnslndh]

Question: should direct-reference matching stop depending on NuGet's target name format?

This PR only adds a regression test. The bug itself was fixed by the NuGet.ProjectModel 7.0.1 → 7.6.0 update in 52ea46d. I'd like your advice on whether we should also change the matching logic.

Background. ProjectAssetsFileService.GetDotnetDependencys finds a target's direct references by comparing strings:

.Where(f => f.FrameworkName == targetRuntime.Name)

ProjectFileDependencyGroup.FrameworkName is the raw key from project.assets.json, which is the project's target alias (net48, Net8.0, …). Whether LockFileTarget.Name matches it depends on NuGet's reader:

TFM	7.0.1 LockFileTarget.Name	7.6.0 LockFileTarget.Name
net48	.NETFramework,Version=v4.8	net48
netstandard2.0	.NETStandard,Version=v2.0	netstandard2.0
Net8.0	net8.0	Net8.0
net8.0-windows10.0.19041.0	net8.0-windows10.0.19041	net8.0-windows10.0.19041.0
net8.0 + RID	net8.0/win-x64	net8.0/win-x64

So the current code works because of how 7.6.0 happens to read names. RID targets never match under either version. That has no visible effect today, because the plain target's copy of each package is the one kept.

Proposed change:

.Where(f => string.Equals(f.FrameworkName, targetFramework.TargetAlias, StringComparison.OrdinalIgnoreCase)
            || NuGetFramework.Parse(f.FrameworkName).Equals(targetRuntime.TargetFramework))

• It matches on the target alias from PackageSpec, which is what the group keys are. This also covers RID targets and custom aliases.
• It falls back to comparing parsed frameworks, for older assets files whose keys look like .NETStandard,Version=v2.1. The existing tests cover that format.

I have this change ready with a unit test that builds LockFile objects with names that differ from the group keys (6 cases). On current master all 6 fail; with the change the full suite passes on net8.0, net9.0 and net10.0. I also applied the change on top of NuGet 7.0.1: every case that dropped to 0 components kept its full list.

Questions:

1. Is it worth making the matching robust like this, or is relying on the 7.6.0 behavior acceptable?
2. If yes, should it go into this PR or a separate one?

This does not fix #1130, where RID-only packages are removed by --exclude-filter. That's a separate problem in how packages from different targets are merged.

[uo-uhbc]

Q1: yes, make the matching robust — and I can confirm the premise empirically. I ran your regression test against the same net48 assets file with NuGet.ProjectModel pinned both ways: 10 components on 7.6.0, 0 on 7.0.1 (Assert.Equal() Failure: Expected 10, Actual 0, both tests failing). So the correctness of the whole component list currently rests on how a transitive dependency happens to format a string. #1122 is open to take it to 7.9.0 and touches only Directory.Packages.props and packages.lock.json — nothing in it checks the format.

I also applied your proposed matching and tested it: at 7.0.1, where master gives 0 of 10, both tests pass and the full suite is 220 passed / 0 failed / 2 skipped; at 7.6.0 it is 220 / 0 / 2 on net8.0, net9.0 and net10.0. It removes the dependency on NuGet's name format and regresses nothing, so I would say it is worth doing.

Q2: separate PR. This one is mergeable and valuable on its own.

I have corrected my comment on #1126 and the related passage in #1133 — I had generalised from a net10.0 repro, which matches under both NuGet versions and so can never reach the path you describe. Your analysis holds; mine never tested a TFM where it could fail.

Your RID observation also reproduces for me: adding <RuntimeIdentifier>win-x64</RuntimeIdentifier> gives "targets": ["net10.0", "net10.0/win-x64"] against "projectFileDependencyGroups": ["net10.0"] with no change in output, as you said.

Last thing: ExcludeFilter_RemovesOnlyExcludedPackageAndItsOrphans pins something worth pinning — the cascade is the sweep's intent, not a bug. That is the right frame for #1130 and #1133 too: the problem there isn't that the sweep cascades, it is that it walks a graph the tool already knows is incomplete. Agreed this PR doesn't touch #1130 — I measured a fix for that one on #1129 and commented there.