12

Closed

Don't Strong Name NuGet Assemblies

description

This post requires a little understanding about how strong naming works. It’s complicated, but basically here is the jist:
 
When you compile a library against a strong named assembly, only that specific version of the assembly can be used with the assembly that you are compiling with out resorting to heroics. You may say what is the big deal that is how all libraries are compiled and linked. But that isn’t true in .NET, if you don’t have a strongly named assembly, you have for better terms a weakly named assembly. And with weakly named assemblies there is not enforcement of the version, just the library name. So this makes it possible for developers to update a referenced library without actually recompiling the original library that referenced it. This is very powerful in the right hands, and pretty much what makes services like NuGet function with references so many intermingling of references between projects.
 
So once you understand that and it has sort of sunk in. Now consider what kind of monkey wrench would be thrown in to NuGet references process if libraries were strongly signed. Now consider the project that is strongly named is also the 5th most popular project on NuGet with over 125,000 downloads and is one of if not the most interreferenced library in NuGet. That is a monkey wrench of epic proportions that can cause some real damage isn’t it.
 
Well you have probably guessed that this isn’t some hypothetical problem that I am posting about in this work item. This is an actual problem in NuGet and is causing the community great pains against this ever popular and wonderful library.
 
I understand certain people like installing JSON.NET into the GAC and I have no problem with that, and I think it should continued to be signed for them. But why not stop signing just the assemblies that you push to NuGet. Because this problem is only going to get worse when the ASP.NET Web Stack starts building steam and this problem escalates out of control.
Closed Apr 13, 2012 at 12:32 AM by JamesNK
I believe continuing to strong name but not updating the assembly version is the best solution for everyone. See my blog post for more details - http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers.aspx

comments

JamesNK wrote Apr 4, 2012 at 4:46 AM

The ASP.NET web stack is strong named itself and will reference Json.NET through NuGet.

From 4.5 onwards the assembly version is only going to be updated for major releases, similar to ASP.NET MVC.

Haacked wrote Apr 4, 2012 at 5:05 AM

Following SemVer is probably a good answer in this particular case. After all, when installing packages via NuGet, it adds the necessary binding redirects.

Since ASP.NET Web Stack is going to use this library, removing the strong name from JSON.NET would break ASP.NET Web Stack.

You can't reference an assembly that doesn't have a strong name from an assembly that does have a strong name.

So you'd have to get ASP.NET Web Stack's NuGet packages to not be strong named first.

chrisortman wrote Apr 4, 2012 at 5:23 AM

Would it make sense to use only Major.Minor or Major.0.0.0 as the AssemblyVersionAttribute and put the Major.Minor.Patch in the AssemblyFileAttribute and/or AssemblyInformationVersionAttribute ?

I think then you would be able to drop in replace newer versions without recompile or binding redirects

nberardi wrote Apr 4, 2012 at 5:25 AM

James that is great news on following SemVer. How often are you going to update SemVer though? You made a jump from 4.0 to 4.5? Are you going to keep 4.5 around until 5.0 or do you anticipate a 4.6?

JamesNK wrote Apr 4, 2012 at 5:41 AM

I mentioned strong naming when I released 4.5 - http://james.newtonking.com/archive/2012/03/20/json-net-4-5-release-1-iso-dates-async-metro-build.aspx

4.5.0.0 will probably be the assembly version until .NET 5.0 which will be a long way off.

adamralph wrote Apr 4, 2012 at 7:11 AM

As @Haacked says, the problem with not signing Nuget assemblies is that they cannot then be referenced by strong named assemblies. Most clients I’ve worked for use strong naming and if Nuget assemblies were to become unsigned, all these stacks would break.

At my current client, I’ve already had to work around the problem of the RestSharp Nuget package not being strongly named. My workaround is to ildasm the assembly and then re-ilasm it with a key after each Nuget update. Indeed, it would be great if Nuget had a facility added to it to do this automatically. Nuget packages could then all be unsigned, with optional dynamic signing taking place at update time.

mkamoski wrote Feb 13, 2013 at 9:05 PM

Ug. Cannot believe this is a problem in Nuget with no workaround. Maybe only a Nuget problem insofaras not requiring all submittals to be strongly names. I mean, when the hey-ack, it is dirt simple for the submitter to strong name. Shame. Nuget is a good idea hampered by fuzzy implementation. Elmah has had this strong name problem since its inception and I am baffled that Aziz hasn't caught on. Anyway. So it goes. It is just too bad.