No package validation coverage for runtime.native.System.IO.Ports

[ericstj]

See discussion in #66176 as well as #28796. Since this package was introduced we've never had coverage of it since it's the only library package we build that requires runtime-specific packages as dependencies.

This has caused regressions numerous times because the package is "special" and often overlooked and that special-ness has made it exempt from testing which makes this worse.

This issue could be moot depending on the resolution of dotnet/iot#1797, but I'd like to file it to track the concern since we've broken Ports multiple times since it was introduced.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See discussion in #66176 as well as #28796. Since this package was introduced we've never had coverage of it since it's the only library package we build that requires runtime-specific packages as dependencies.

This has caused regressions numerous times because the package is "special" and often overlooked and that special-ness has made it exempt from testing which makes this worse.

This issue could be moot depending on the resolution of dotnet/iot#1797, but I'd like to file it to track the concern since we've broken Ports multiple times since it was introduced.

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ViktorHofer]

@ericstj since you opened this, what are your thoughts on how to enable package validation for runtime.native.System.IO.Ports?

[ViktorHofer]

gentle ping @ericstj regarding my above question.

[ericstj]

We'd need to test it after running the platform specific build legs, as a join later in the build. At one point we did package testing in this way, but it was expensive since it waited on everything to complete and took a long time to run. We've gotten faster at this testing, since we don't do all the RID specific restores any more so it might be feasible to do it, but I'm not sure we have any step today that is a join after vertical legs and allConfigurations.

Another (different) way to test this would just be some redundancy around the expected packages for each leg. Something declaring what packages we'd expect the build to produce as a safegaurd to catch if those were accidentally removed through refactoring. Such a test could just maintain a checked in baseline and fail the build if it changes asking the developer to check in their change to the baseline if it was intentional.