Fix netfx build for S.S.C.Xml nuget package

[bartonjs]

Fixes #78652.

Manually verified that the net462/ref.dll and net462/lib.dll were missing the typefowards before, and they're present after.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #78652.

Manually verified that the net462/ref.dll and net462/lib.dll were missing the typefowards before, and they're present after.

Author:	bartonjs
Assignees:	-
Labels:	area-System.Security
Milestone:	-

[adamsitnik]

The change LGTM, but there is one more project file that has the same bug:

runtime/src/libraries/System.Threading.AccessControl/ref/System.Threading.AccessControl.csproj

Line 9 in dd0ec94

<Compile Include="System.Threading.AccessControl.netframework.cs" Condition="'$(TargetFrameworkIdentifier)' == 'NETFramework'" />

@bartonjs would you mind fixing it in this PR as well?

[carlossanlop]

@ViktorHofer is there a way to be notified via a build failure when there's a typo like this?

[ViktorHofer]

Thanks for fixing this, @bartonjs

[ViktorHofer]

APICompat doesn't catch this because the type forwards don't exist on netstandard2.0. Baseline validation that compares ref/net462 or lib/net462 from the previous package with the live built one could theoretically catch this. That said, we don't have such a feature in ApiCompat today.

I'm a bit surprised that our .NET Framework tests didn't catch this. It looks like the tests don't bind against the package asset and instead directly on the .NET Framework runtime library. That alone is a terrible indicator that we might not be testing our actually .NET Framework shipping assets and that would raise the question why we then even run those tests.

[bartonjs]

that would raise the question why we then even run those tests.

For cryptoxml, to ensure that any changes we do take are still compatible with netfx, because it's effectively a serialization library and needs that level of fidelity.

But, yes, it would be better if the tests (or APICompat/etc) could guard us from this, too.

[bartonjs]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3527528268