Unusual package layout for System.Text.Encodings.Web/10.0.1

[ViktorHofer]

runtime/src/libraries/System.Text.Encodings.Web/src/System.Text.Encodings.Web.csproj

Lines 4 to 5 in 5422d6d

	<TargetFrameworks>$(NetCoreAppCurrent)-browser;$(NetCoreAppCurrent)-wasi;$(NetCoreAppCurrent);$(NetCoreAppMinimum)-browser;$(NetCoreAppMinimum);netstandard2.0;$(NetFrameworkMinimum)</TargetFrameworks>
	<TargetFrameworks Condition="'$(NetCoreAppPrevious)' != ''">$(TargetFrameworks);$(NetCoreAppPrevious)-windows;$(NetCoreAppPrevious)</TargetFrameworks>

It's unusual that there's a net9.0-windows TFM but not for net10.0 and at the same time it's unusual that some of the 10 ones are only on 10.

@dotnet/area-system-text-encodings-web can you please take a look?

[dotnet-policy-service]

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

[ericstj]

As a general rule it's probably a source-authoring bug when a library has inconsistent runtime/platform targeting across TargetFrameworks.

If that results in API differences, a tool like APICompat will catch it. If it's only resulting in different runtime behavior (eg between frameworks/runtimes or between package/shared-framework) then nothing will catch it.

Perhaps a way to test for this would be to compare the resolved assets targeting information across different frameworks and make sure it's consistent.

For instance if the shared framework had a platform-specific lib, then the package should as well. If a platform has a platform specific lib on one framework it should on future frameworks, etc.