Strong names about asyncex

[StephenCleary]

Why do you want strong-named packages?

[BlackGad]

Our packages utilize strong naming, yet we encounter warnings because the Nito assemblies we reference are not signed. Specifically, the warnings pertain to Nito.AsyncEx.Coordination and Nito.AsyncEx.Tasks, both of which lack a strong name. Signing these assemblies would be highly beneficial and appreciated, considering their quality.

Starting with .NET 5+, strong names no longer offer advantages, leaving warnings as the only concern.

[StephenCleary]

Strong naming causes numerous serious maintenance issues for package maintainers, and for this reason I'm not going to strong name any of my libraries. For more details, see #229 (comment)

My real question is, why do you strong-name? What benefit of strong naming are you depending on?

[BlackGad]

Previously, the focus was on .NET Framework and some GAC usage. However, you make a valid argument. Perhaps now is the opportune moment to move away from using strong names.

[CZEMacLeod]

As a reason to use strong names (out-with those of us still maintaining large net framework based applications), we use them to identify assemblies containing injectable services that we develop (rather than scanning all assemblies), and to filter and list assemblies that are part of the product, separately from those that are our framework or 'third' party, such as for About pages, or to list dependent licenses and acknowledgements etc.
We use the Brutal Strongnamer to handle the few packages which don't supply a strong named package, or just copy the required classes to a utilities package which we strong name (but this doesn't allow us to easily track updates, security issues, or easily assign the correct rights and licencing to the code beyond the source level).