This project has moved. For the latest updates, please go here.

Why were strong names dropped?

Sep 5, 2012 at 3:38 AM

I'm curious what the reasoning is, since I've been trying to convince some other OSS projects to have strong named assemblies at least available if not as the main distribution.

Sep 5, 2012 at 8:30 AM
Edited Sep 5, 2012 at 8:34 AM

In short, strong names make package management/version resolving with indirect dependencies (A->(B,C)->D) very complicated, and on platforms without binding redirects (like Silverlight and Windows Phone) even impossible. To avoid breaking everything on every new release we'd have to resort to dirty hacks like not changing the assembly version on new releases. At the same time, strong names don't really have any advantage.

IMO, the only reason to strong-name an application today is company policy, and the issue that they can then only reference strong-named assemblies in their projects. There might also be a few very special cases where you'd want to put it into the GAC (although there's usually no point in adding application assemblies to the GAC). For these cases we still provide strong named packages with the .Signed suffix - in the spirit of the liberal MIT/X11 license.

This is an opensource project, so I have to make sure that you can always fix issues yourself (if we're too slow, disagree, or whatever), rebuild and then replace all the assemblies in your projects. This is trivial without strong names, but very complicated with strong names without rebuilding the whole application. Strong names bring no advantage regarding security, tampering protection and authenticity, at least for opensource projects.

Personally I'd recommend all NuGet package authors to either not strong-name at all, or to provide both with and without strong name, the former with a .Signed suffix. This is easy to provide with two different build profiles (e.g. in Math.NET Numerics we have both "Release" and "Release - signed" profiles).