Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jas88 opened this issue Jun 16, 2024 · 2 comments
Open

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

jas88 opened this issue Jun 16, 2024 · 2 comments

Comments

@jas88
Copy link

jas88 commented Jun 16, 2024

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?

@jas88 jas88 added the bug label Jun 16, 2024
@tonyqus
Copy link
Member

tonyqus commented Jun 16, 2024

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
Copy link
Author

jas88 commented Jun 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants