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.