Should I strongly name all assemblies?

Question

So there are lots of questions around the benefits of strongly naming a .Net assembly, such as this one Why use strong named assemblies?

The benefits sound great, so why wouldn't I strongly name every project I make?

What are the advantages of NOT strongly naming an assembly, and which should I do by default when making new projects?

Zagazig

Answer 1

Strongly naming an assembly takes time (sort of) and is not useful for a project that you don't plan to take to the market/open-source it. There are some implications when you do not strongly name your assembly, such as you cannot add it to the GAC.

A possible benefit is that you can reference other unsigned assemblies within your assembly, whereas in a strongly named assembly you can only reference other strongly named assemblies.

Leatherman

I agree with everything except that it takes time. I mean, it does. But if you do it through VS it takes about 4 mouse clicks. – Spacecraft

Agree with MasterMastic, it took me seconds to sign the assembly (no password) with a generated snk file. BUT I am not asking for the benefits of doing so, rather NOT doing so. In what situations would I be better off NOT strongly naming an assembly, what would that offer that a strongly signed assembly can not? – Zagazig

Thanks for your edit CodingChief "a possible benefit..", at last that gives me one real benefit which I haven't found answered elsewhere. But then if all assemblies were strongly named in the first place then that wouldn't be an issue. Any others? – Zagazig

Answer 2

Strong-named assemblies are useful in the following scenarios:

1. You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.

2. An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.

3. You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.

4. When you want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

Source

Marthmartha

Some great reasons for strongly naming, but I am after good reasons NOT to strongly name – Zagazig

I am not sure if there are any strong reasons to weakly name assemblies. To be honest, the above 4 points sum it all. If you want any of the above, then sign them strongly, else keep them weakly unsigned. @user1722957 – Marthmartha

Ok, so the answer to the original question is 'Yes'? If I got into the habit of always strongly naming all my projects then no harm can come of it? – Zagazig

By all means, you can take the pain of strongly naming assemblies all the time. I would only sign it in release process(its one of my top 3 in a release checklist) – Marthmartha

Ok, then the next obvious question (from a reduction point of view) - why do we have the choice? Why aren't projects strongly named by default. There must be a downside? (perhaps I'm doing it wrong, but I thought the process in VS was about as pain free as it can get!) – Zagazig

strongly naming an assembly makes it tamper proof, but cannot be duplicated. If a strongly named assembly is tampered with, .NET CLR will not accept the assembly and your program may crash. By default, Microsoft assumes that the assemblies created on your system will not really end up in GAC, will reside in the .\bin folder and there could be duplicates of the assembly. – Marthmartha