Strong name

[DanAvni]

Can you please release FcmSharp as strong named assembly? My app is strong named and as such requires every reference to be strong named as well

Thanks

[bytefish]

Hm, I am cautious with Strong Naming the assemblies, because I am unsure of the overhead it introduces for me as a project maintainer. Is there any possibility you sign the assembly yourself, if you are required to use strong-named assemblies?

[DanAvni]

The nugets I use from github are strongly named and I do not think it's more than creating a snk file aמג setting the project properties

I can give you samples of other nugets if you want

[bytefish]

I am still reading a lot on Strong-Naming assemblies:

• https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md
• https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/public-signing.md

I am unsure, what do you think?

[DanAvni]

I can tell you that I have been signing my assemblies for years based on some security review we had for our app which recommended to do so. So far I had no issues with it and have been able to drop replacement dll as long as the version did not change (maybe it works with version changes as well)

As I said I know the about 10 nugets I use which are all strong named without any problem (I am using the .net classic dll so maybe just sign it?)

[bytefish]

Yes, but it's not as simple as that.

Just see all the discussions in other popular Open Source projects (NancyFx, Octokit.NET) on Strong-Named assemblies. And then again I fear a lot of Github issues on wrong Binding Redirects, which the reason why JSON.NET only bumps the Assembly Version for Major releases only. Which is weird, because now you have two Version Numbers, that looks like a Workaround to me.

This is a good discussion:

• https://github.com/octokit/octokit.net/issues/405

If you need a strong-named assembly urgently, the please clone the project for and sign it yourself for now. I know this isn't as convenient as having a NuGet package, but then again strong-naming might add some overhead to me.

Please read the linked issue to get some views from the .NET community on it.

[bytefish]

I will keep this issue open for now and think about it the days ahead.

[DanAvni]

Another option I remembered seeing on at least one project in the past is the project has two nugets: one signed and one not and their deployment scripts create both. Having said that I think they moved to a signed only nuget as well but a solution like that might be easier for everyone.

What do you think?

[bytefish]

No, I don't want a separate NuGet. I think I could start strong naming the assembly and commit the key into the repository, so other people won't have problems building the library by themselves. The thing I wonder is what approach to Versioning I could take. I don't like the approach of Json.NET, which freezes the version at the Major Revision and only increases it for Major Releases. So if I had Version 2.7.0 the Assembly Version would still say 2.0.0, which is plainly wrong. Json.NET is apparently doing this to limit Binding Redirects.

[bytefish]

Please bear with me, but I want to find out the implications before doing it. I know Microsoft also Strong Names all of its assemblies, but I yet have to find out what overhead this means on my side and what problems it could lead to, speaking of issues on the user-side.

I know some people need strong named assemblies for corporate policies, but the library is released under a license as much permissive as possible. So it is possible to clone the project and sign it by yourself, so the compiler is happy.

And if you read other threads on strong named assemblies you can see what kind of heated discussion it is within the .NET Open Source community... with threads of 150 comments. Some projects I highly respect, such as NancyFx don't strong name their Assemblies and said to never do so. Why?

See at the moment there are not a lot issues, because the library simply works. This is good, because I have a lot of work in my day job and can't process a lot of issues.

So before going strong named I need to understand it first and find out how to release it without producing issues on the user-side. It's not like I dismiss it easily, because strong-naming came up for every of my libraries to date.

[bytefish]

Despite all my writings I decided to give it a go and just strong-name the assembly. If there are major complaints I can revert it back any time. I am still not sure, if going from a not strong-named assembly to a strong-named assembly is a breaking change -- I hope not. The internet is low on this.

Like suggested in https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md I am commiting the Private Key to the repository:

Firstly, we would recommend that these open source projects check-in their private key (remember, strong-names are used for identity, and not for security).

I hope all this makes it easier to consume the package for users, that need strong named assemblies; and at the same time doesn't break anything for users, that don't need strong-named assemblies. 👍

The Version 2.7.0 with strong-named assemblies is uploaded to NuGet and should be available as soon as Microsoft updates its indexes, which can take up to 1 - 2 hours.

Please reopen the ticket, if the problem persists.

[bytefish]

@DanAvni It's listed in NuGet now. Please give me some feedback, if it works as expected. 🙏

[DanAvni]

Will do. Thanks!

[DanAvni]

Hi Phillip,

I haven't done full tests but so far in what I have tested it all seems ok. My app is able to use the library and call into FCM without any problems

Many Thanks!