Add target for .NET 6/8 or .NET Standard 2.0/2.1

[DaveDezinski]

I'm using SaxonCS 12.4 which references ICU4N and ICU4N.Resources. The ICU4N.Resources NuGet package is targeting .NET Standard 1.6 which brings in a lot of out of date NuGet packages that contain security vulnerabilities and need updating. Any plans to update the NuGet package to add targets for .NET 6/8 or update the existing target to .NET Standard 2.0/2.1 so we can get rid of these old package references?

[NightOwl888]

Thanks for the report.

One of the motivations for moving to satellite assemblies was to move most of the large resource files outside of the assembly so we don't have to deploy multiple copies of them (1 copy per target framework). The satellite assemblies are actually target framework neutral. However, after experimenting with the default fallback rules for PackageReference, it seemed at the time that there was no option that would allow us to deploy only 1 copy of the resources while multi-targeting our main assemblies. The closest we could get was to target netstandard1.0. Unfortunately, the reference assemblies it automatically brings in were an undesired side effect and are completely unnecessary.

After taking another look, it looks like there is a AssetTargetFallback property to override the default behavior. So, we will have to see whether changing the default behavior will work without bringing in undesired dependencies.

[DaveDezinski]

Any updates?

[NightOwl888]

I experimented with the AssetTargetFallback, but couldn't seem to get it to function. So, my thought is to use an approach similar to Microsoft.NETFramework.ReferenceAssemblies, which is a meta-package that conditionally depends on target framework-specific data packages. Although, technically we only need 1 data package that net40 and netstandard2.0 depend on because they contain the same assemblies. It sucks having to use multiple packages, but it seems to be the only way to work around the limitations of NuGet.

This isn't the only issue dealing with resources, though, and all of them will need either to be worked on together or we need to sidestep by rolling everything back into a single DLL until we can come up with a new plan for naming the files in a way that .NET can deal with. This is all still very experimental. And at the moment it isn't the highest priority to work on, but will need to be revisited prior to the next release.