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?

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.

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