Strong named assemblies — To sign or not to sign?

Should you sign your .NET assemblies or not? That is the question.

According to the Betteridge’s law of headlines the answer should be no. Unfortunately you’re going to have to decide for yourself.

I gathered some info and made a decision accordingly. Time has passed and I do not regret my decision.

Here’s the data:

• Do not rely on strong names for security. They provide a unique identity only.
• You can use different versions of the same assembly.
• Tampering with strongly signed assembly is possible. Since .NET 3.5 can be bypassed, because it was slow. [link]
• Strong naming is probably causing the issue we had with app.config [link]
• Strong named assembly can only reference other strong named assemblies [link]
• Vladimir Khorikov doesn’t sign his libs, since no one is doing it anymore [link]
• According to Microsoft, you should strong sign your dlls [link]
• This thing exists: strong namer — sign dlls which are not signed [link]
• NewtonSoft.Json, Serilog, TwinCAT.Ads — signed
• Interesting blog posts : https://jbp.dev/blog/signing-net.html
• This guy changed his mind

March 2016 — Still Strong-Naming your Assemblies? You do know it’s 2016, right?

September 2018 — Start Strong-Naming your Assemblies!

• To those still skeptical of strong-naming their assemblies, I propose a compromise solution: do strong-name your assemblies, but only increment the assembly version for major releases! Json.NET has been using this approach to avoid binding redirects since 2014, and as far as I can tell, with relative success!

• This diff message — https://github.com/dotnet/corefx/pull/33784/files#

Conclusion

Microsoft recommends to sign assemblies; critical libraries are signed as well. We want to ensure that specific versions will always work with each other. We should also able to sign dlls which are not signed by default.

Therefore, I recommend to use strong naming.