Use of legacy .Signed MathNet.Numerics package causing build issues

[jas88]

NPOI Version

2.7.0

Issue Description

The developers of MathNet.Numerics have two variants, the main one and a legacy .Signed variant with a strong name, both of which identify internally as MathNet.Numerics; the developers themselves state that "This package contains strong-named assemblies for legacy use cases (not recommended)" and Microsoft say "Strong naming has no benefits on .NET Core/5+." Is there a need to keep using the legacy version rather than switching to the (much more popular) regular one?

[tonyqus]

Microsoft say "Strong naming has no benefits on .NET Core/5+."

Where do you get this? Can you give me a url or something?

[jas88]

First sentence of the last paragraph of the first section here: https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

I think I saw an issue from a Dutch developer asking for something to avoid triggering the warning MS say can safely be disabled as irrelevant on modern apps.

If it does concern legacy users, I think making the Framework 4.7.2 dependencies include the Signed version and the Core/6.0 one use the regular unsigned one might suit everyone.

[tonyqus]

@lahma How do you think?

[lahma]

Moden .NET (NET 6+ or something similar lingo) doesn't need signing, but anything targeting full framework will have problems if there's a need to do binding redirects or anything similar - it needs signed assembly. One option could be to use different library version based whether targeting NET 8 or not.