AsyncEx
AsyncEx copied to clipboard
StephenCleary
Strong names
Can strong names be assigned to all Nito packages? From what I gather, they were available previously.
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.
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 https://github.com/StephenCleary/AsyncEx/issues/229#issuecomment-748620742
My real question is, why do you strong-name? What benefit of strong naming are you depending on?
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.
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).
You might not always be in full control of the stack that you are working on. For example when you are building extensions / addons to products that mandate signing (e.g. Visual Studio itself). IMO, expecting open-source libraries to sign their assemblies might not be realistic. There are several workarounds for when you need your dependencies to be signed. One workaround for example is to reference StrongNamer nuget. It's a build-time only dependency that relies on targets to find and sign all your dependencies
