dlls are not signed within NuGet packages

[franklixuefei]

Hi Stephen,

This is Frank from Microsoft Azure. Our pipeline says that all the Nito dlls are not signed, and I went ahead and checked them - they are indeed not signed. There's no Signature tab under the dll properties. Normally if a DLL is signed, a valid signature tab should appear there. Please refer to the below images.
FYI - I'm using version 5.1.0

I wonder if this is a known problem?

Thanks!
Frank

[StephenCleary]

Short answer: this is a known issue. I have no plans to add strong-naming to AsyncEx now, for reasons described here. See also #2. If Microsoft would provide better tooling and guidance for strong naming libraries without causing massive maintenance headaches, then I would be willing to reconsider.

A Short History of Strong Naming in AsyncEx:

• AsyncEx v2 was strong named. Endless problems ensued and only grew as the library's popularity grew. The strong naming was removed in v3.
• AsyncEx v4 had a separate library that was strong named. More problems ensued to the point it became a maintenance burden. This strong named option was also removed.
• AsyncEx v5 (prerelease) was public signed for a release or two. I had high hopes that public signing would work around the problems with strong naming, but it did not fix a worthwhile amount of the problems with strong naming, so the public signing was also removed.

I still think the .NET ecosystem would be better served by a service that auto-signs packages following a semantic versioning approach. So far, I have not had time to write this service.

[franklixuefei]

Wow, thanks for the detailed reply, Stephen, and I didn't realize this underwent so much ups and downs related to strong name signing. For your final point - public signing - what was the reason for you to abandon it eventually, if you don't mind elaborating it a little bit more? Because tbh, at least for our team, we don't care about strong name signing, but only public signing. Our pipeline just does regular public signing of our project DLLs with some Azure internal certs, and checks if all the 3rd party dlls were signed beforehand (not checking strong name signing though). This step threw due to Nito dlls not signed.
I understand that strong name signing is obsolete in some sense.

Thanks!
Frank

[StephenCleary]

Interesting that it's checking assemblies are signed, but not checking the signatures. It's been a while since I've worked with the public signing, but IIRC the problems were:

1. (Obviously) It doesn't work for anything that actually checks the signatures, e.g., the GAC.
2. It doesn't solve any of the binding redirect issues.
3. (IIRC) The diamond problem is still in full force.

I still think a service that autosigns packages on demand is a good idea. And I still don't have time to write it. In the meantime, the Strong Naming Toolkit and StrongNameSigner are still available.