No strong name for .NET Framework targets

[karakasa]

Description The library has no strong names and cannot be referenced from a Framework project.

Error/Exception Message System.IO.FileLoadException

Expected Behavior No exception.

Actual Behavior Exception thrown.

Steps To Reproduce Reference the NuGet package from a Framework project and use it.

Screenshots

Additional context/Comments/Notes/Rants https://github.com/nissl-lab/npoi/pull/1135#issuecomment-1667826536

[AdamWhiteHat]

Oh sorry, just saw this. Despite repeatedly telling gmail to prioritize GitHub emails as important, they still filed in with the rest of my general inbox items most of the time.

Yeah, I can strongname and sign my assemblies for you. I just recently remarked to myself that I should probably be doing this for all my libraries now that some of them are getting popular or are the top library for a particular numerical type.

I will try and get that set up released today. ETA about 8PM mountain standard time.

Thank you for your interest in my library.

[AdamWhiteHat]

Oh, by the way, I was reading the pull request on the referenced library, NPOI, and wanted to know: Did you want/need me to also target net472 and netstandard2.0 with my library as well? This would be trivial to add.

[karakasa]

net472 and netstandard2.0

It would be sufficient if the project targets .NET Standard 2.0, since 2.0 covers .NET Framework >=4.6.2 and .NET (Core) >=2.0

And thank you for your work 😉

[AdamWhiteHat]

Topics

• The Assembly is now Strong Named
• ⓘ A Returning to Semantic Versioning
• Updated NuGet Package Published
• New Targeted Frameworks
• ⚠ Truncate Method Now Functionally Different

## The Assembly is now Strong Named

The assembly is now strong named and available on NuGet as version [2.0.0.23230.](https://www.nuget.org/packages/ExtendedNumerics.BigDecimal/2.0.0.23230) Note: Nuget does not recognize the new version as being the latest package. [See here](#nuget-package) for further discussion on this. Because this is an open source project, as per Microsoft's recommendation, I checked in the identity/signing key so that further versions can be strong named by others. **Note:** This is not an issue, strong naming does not provide authenticity or anti-tampering guarantees, only a unique identity that you can tie to when referencing it from a project. I also didn't want to be the sole gatekeeper for strong naming releases, in the event I am suddenly abducted by aliens and never heard from again (or the proverbial hit-by-a-bus scenario, which ever you prefer).

## A Returning to Semantic Versioning

Version numbering scheme has changed. We are returning to using semantic versioning. I bumped the major version. We are at 2.0.0 now. Actually, version [2.0.0.23230](https://www.nuget.org/packages/ExtendedNumerics.BigDecimal/2.0.0.23230) to be exact. The version based on the date was nice for me, but would be absolute hell for anyone using our library who wanted to know if a newer version introduced a breaking change or not. Under the old scheme, the left most version number had zero correlation with whether the new version introduced breaking changes or not; it was the year of the date the assembly was built! There will be no more of that nonsense going forward. Version numbers will adhere to semantic versioning guidelines. I plan to make the same change for all my numeric libraries.

## Updated NuGet Package Published

The updated assembly with the strong naming and changes mentioned here has been pushed to NuGet and is version [2.0.0.23230](https://www.nuget.org/packages/ExtendedNumerics.BigDecimal/2.0.0.23230). Warning: Nuget is not currently showing this as the latest version, likely because 2 is smaller than 2023. Ill look into how to get nuget to recognize the new versioning scheme correctly. I can always deprecate all prior versions if it comes to it. Until I figure it out, you'll need to select and install version 2.0.0.23230 explicitly (not the latest version, according to NuGet).

## New Targeted Frameworks

I added two new targeted frameworks: 1. net472 2. netstandard2.0

## Truncate Method Now Functionally Different

Please take note, the BigDecimal.Truncate method is now functionally different due to a bug-fix: The Truncate now behaves like Floor, as it should, instead of Round, which is wrong. I hope you wern't relying on this incorrect behavior.

---

[AdamWhiteHat]

Okay, here is what I decided: Ill start the semantic version at 2023.1000.0.* because I really don't want to deprecate all previous versions and there doesn't appear to be any workaround that I could find.

So get this NuGet package version instead: 2023.1000.0.230 Or just update your project's Nuget package to the latest version.

I un-listed the 2.0.0.23230 version so as not to confuse others.