Add NetCoreAppCurrent configuration to libs (Phase 1)

[ViktorHofer]

Contributes to #54012
Fixes #54556
Fixes #54575

• Commit 1: Infra change only to make it easier to bump the minimum supported version of .NETCoreApp
• Commit 2: Add NetCoreAppCurrent to System.Numerics.Tensors (@tannergooding)
• Commit 3: Add NetCoreAppCurrent to System.Threading.AccessControl (@mangod9)
• Commit 4: Add NetCoreAppCurrent to System.Memory.Data (@adamsitnik @carlossanlop)
• Commit 5: Add NetCoreAppCurrent to System.Composition.* projects (@buyaa-n)
• Commit 6: Add NetCoreAppCurrent to System.IO.Packaging (@adamsitnik, @carlossanlop)
• Commit 7: Add NetCoreAppCurrent to System.IO.Ports and use runtime checks instead of targeting FreeBSD, OSX and Linux to avoid an unexpected increase in package size and reduce build times (@adamsitnik @carlossanlop @jozkee)
• Commit 8: Add NetCoreAppCurrent to System.Data.OleDb (@ajcvickers)
• Commit 9: Add NetCoreAppCurrent to Microsoft.Win32.Registry.AccessControl (cc @Anipik and myself)
• Commit 10: Add NetCoreAppCurrent to System.Reflection.Context (cc @buyaa-n)
• Commit 11: Add NetCoreAppCurrent to System.ComponentModel.Composition.Registration (cc @buyaa-n)
• Commit 12: Add NetCoreAppCurrent to System.Resources.Extensions (cc @buyaa-n)
• Commit 13: Add NetCoreAppCurrent to System.Net.Http.WinHttpHandler (cc @dotnet/ncl)

[ghost]

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Contributes to #54012

Commit 1 is an infra change only to make it easier to bump the minimum supported version of .NETCoreApp
Commit 2 adds NetCoreAppCurrent to System.Numerics.Tensors (@tannergooding)
Commit 3 adds NetCoreAppCurrent to System.Threading.AccessControl (@mangod9)

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	area-Infrastructure-libraries
Milestone:	-

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[azure-pipelines]

There was an error handling pipeline event 4f38cb9b-b770-4abb-b5c0-7bbb9145ef96.

[ericstj]

Would it make sense to default NETStandardCompatError/@Supported to $(NetCoreAppMinimum) so that we don't need to duplicate that in all the projects?

[supported]

I do not know why I am here. But I love you.

[ViktorHofer]

Even though we mostly care about .NETCoreApp, as .NETStandard has multiple compatible frameworks, I wouldn't want to default it to .NETCoreApp. As an example, for NET7 the min .NETFramework version will be net462 and we will make use of this infrastructure for .NETFramework as well.

[ericstj]

Defaulting could happen in Targets after the project sets the Include value. You could handle both cases based on TFI of the include. It's just a suggestion, but could avoid boilerplate if we think the boilerplate isn't adding value to the project. I guess from that perspective we could automatically calculate these entirely since we see what the project is targeting.

[ViktorHofer]

I guess from that perspective we could automatically calculate these entirely since we see what the project is targeting.

Thanks for the suggestion. Tbh that's what I would prefer. When I added this infrastructure in a previous PR I considered automation but didn't do it for different reasons. That said, I definitely wouldn't want to clean this up as part of this PR. For now I'm fine with having these items in the project file.

[ericstj]

Yeah, also fine with it for now. Just had this gut-reaction when I saw this being treated like boilerplate. If we do end up keeping it in the project file then we should add it to the docs: https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/libraries-packaging.md

[ViktorHofer]

@stephentoub thanks for the review. Can you please take another look? Addressed your feedback.

[stephentoub]

Other than a few more tweaks, the source changes LGTM.

[krwq]

The only reason this is working is because we pass this to native code... This should remain Span, same for Memory change below.

[ViktorHofer]

Spoke with @krwq offline and I decided to revert the changes in this file as a suitable implementation for the overloads without compromising the existing functionality requires more changes than I would want to make as part of this PR. Will file an issue to add the overloads.

[ViktorHofer]

Issues are:

• dotnet-linker-tests (Build Browser wasm release Runtime_Release): Transient restore issue in the middle of the build. Filed Trimming tests should restore upfront instead of after the product build #54920 to restore up-front instead.
• runtime-dev-innerloop (Build windows x86 release MSBuild_CMake): Again transient restore issue.
• runtime (CoreCLR Product Build windows x64 checked): Again transient restore issue in the middle of the build. Filed CoreClr build should restore all components up-front #54921 to restore up-front instead.
• A lot of test failures because of transient network hiccups. Nothing to file against.
• runtime (Libraries Test Run release mono Linux x64 Debug): Assert while running System.Net.Security tests #44689
• JIT work item failures that I don't really understand but which I've seen in multiple PRs