Strong-name Assemblies

[cptjazz]

tl;dr
The assemblies for this library should be strong-named. It doesn't hurt too much. I'd volunteer to do the change.

Long version
The assemblies in this library should be strong-name signed to provide maximum compatibility.
See https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming.

I understand that adding strong-names to this project is a breaking change by definition.
But I claim that now (before referencing this library in Akka and increasing its "market penetration") is the last chance to add strong-names without wreaking too much havoc.

Additional info:
At the moment I maintain a fork of Akka itself (1.3.x at the moment) that has strong-named assemblies, because a project where I use Akka requires strong-naming. This fork is used in a production system for several months now. We did not notice any problems here so I also do not anticipate any major problems when adding strong-names to this library directly.

[Aaronontheweb]

We have historically resisted strong-naming due to the numerous issues it creates for maintainers. That being said, I raised the subject on Twitter and got some replies back from folks who work on IdentityServer, ProxyKit, and some other large .NET OSS projects and the harm seems to be pretty minimal for users running .NET Core and the MSBUILD15 .*proj format that was introduced along with .NET Core back in 2017, since both of those technologies mitigate the bane of strong naming which is binding redirects.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming - based on the guidance here, I think it should be easy for us to program our build scripts to implement this specific piece of guidance:

CONSIDER incrementing the assembly version on only major version changes to help users reduce binding redirects, and how often they're updated.

I.E. I think we'd bump the assembly version each time we do a minor version release, which seems to happen about once every 12-18 months. That'll only affect .NET framework users anyway, but it'll make the .NET framework users who have strong naming requirements happy.

In order to do this, we're going to have to SN Akka.NET, HOCON, Hyperion, and our Akka.Persistence plugins. I think we should consider doing this as a new project after Akka.NET v1.4.0 ships.

Thoughts? cc @akkadotnet/contributors @akkadotnet/core

[sean-gilliam]

What does strong naming buy us? Looking at https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named, it's not a security feature as per the warning

Do not rely on strong names for security. They provide a unique identity only.

Looking at the common scenarios for SNAs

---

• You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.

I fail to see how this is really useful.

• An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.

Using multiple versions of Akka.NET libraries in the same app domain seems like a disaster in the making.

• You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.

Installing Akka.NET into the GAC seems like a corner case to me better left to the user. Seems like more of a headache than benefit.

• You want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

See above comment about GAC install.

---

So other than GAC installation, does this buy us anything?
Just my 2c.

[Aaronontheweb]

So other than GAC installation, does this buy us anything?

Less hassle for and complaints from users who are forced to use strong-naming due to policy[1] at work.

1 - Policies which likely mistake strong naming as a security feature.

[sean-gilliam]

1 - Policies which likely mistake strong naming as a security feature.

As a defense contractor I feel attacked :P

I'll note even though I work in government, our dept doesn't require SNAs. But if other users need it, then we should accommodate those needs if it's not too much hassle.

[Aaronontheweb]

But if other users need it, then we should accommodate those needs if it's not too much hassle.

That's what changed my mind when I went asking about this on Twitter the other day - seems like the people who'd be impacted by this most are Akka.NET users on .NET Framework. SN is mostly ignored on .NET Core.

[Danthar]

I am one of those users :P So i am biased.
But i agree with everything @sean-gilliam has said thus far.

[IgorFedchenko]

@Aaronontheweb So there are some small reasons to use strong naming. At least we may think they are small (depends on the number of users with that weird SN requirement).

But on the other side - why not? What do we loose? What are the cons? Just assign this unique token to an assembly, and let it stay there, making some of the users happy. Especially since @cptjazz is ready to do the PR.

I mean, we do not have a rush to use SN in Akka.NET, and why not to merge PR adding SN here? Mostly for "legacy" full framework users, but still this gives some value.

If only I am not missing some drawbacks of this approach. But this page says "We know you do not like SN very much, guys, but with .NET Core it is slightly better to use them, then not to use - you are not loosing anything anyway". This is how I get it.

[cptjazz]

I know, SN is disputed.
In my situation we talk about a small application framework dynamically loading "plugins" (don't nail me down on the term here) and we want to make sure that dependency mismatches are detected early.

Most of the widely used NuGet packages are strong-named. We use a few dozen of them and Akka is the only major one I had to "patch".
That said, I know for Akka itself it will take time to make this change (if ever). But since SN is contageous, it doesn't hurt to already prepare the libraries it depends on.