Add Strong name signing

[shalarim]

We are trying to use NanoXLSX within a website (asp.net) application. The library won't load as it is not strong named.
https://learn.microsoft.com/en-us/dotnet/standard/assembly/sign-strong-name

Can you add a key and enable strong naming please?

[rabanti-github]

Hi,
Thanks for the report.
I have to do some research first about the consequences of such a change when publishing the library as NuGet package.
I will give you an update about this ASAP.

[rabanti-github]

As far as I understand the situation, just adding strong naming to the library may break the dependency resolution of any application that is currently not using strong naming. Therefore strong naming of NanoXLSX would enforce using strong naming of the applications that are using NanoXLSX.
This may be a problem.
However, an additional Artifact "NanoXLSX-signed+ (or something similar) that is deployed in parallel, may be a good solution.
I just have to figure out how to deploy these two NuGet packages without manual actions.
Please bear with me

[rabanti-github]

After some tries and further investigation, I came to terms, not to use strong naming at the moment.
Here are the reasons:

• As it looks, releasing a strong named library, as an open source project, without providing the private key can make it difficult for the community to make changes on the library without changing the whole project configuration
• Releasing the private key seems not to be a good idea, since this makes the whole security argument of signing an assembly superfluous
• The project configuration becomes currently more and more complex. Adding strong naming as a build variant may multiply the solution build configuration by factor two and needs probably a lot of manual operations like post build actions
• I found so far no ultimative argument in the Internet that would lead to a mandatory use of strong naming (like the usage of HTTPS is important to protect web traffic). As I mentioned, signing without providing the credentials may be beneficial for the security but non-beneficial for the community. Releasing security credentials makes security invalid
• Last but not least: I don't fully understand yet the impact of strong naming and signing of assemblies (or omitting it). And I learned that a not fully understood security feature that is implemented without thorough knowledge is a potential high risk that I don't want to take.

Sorry about that.

My suggestion is to create a fork of the library and to enable strong naming in your own environment. Then you have full control over your code. Usually, changes in this library should be easy to adapt, since no external dependencies are involved. I can of course try to help if upstream changes are making problem to be implemented in the fork.