Should I decisively name all the assemblies?

So, there are many questions about the benefits of strong naming for a .NET assembly, such as Why use strong nodes with names?

The benefits sound great, so why don't I name every project I am doing?

What are the advantages of NOT strongly calling an assembly, and what to do by default when creating new projects?

+5
source share
2 answers

Strict naming of the assembly takes time (a kind) and is useless for a project that you do not plan to bring to the market / open source. There are some consequences when you do not name your assembly strictly, for example, you cannot add it to the GAC.

A possible advantage is that you can reference other unsigned assemblies in your assembly, while in an assembly with a strong name you can only reference other assemblies with a strong name.

+7
source

Strong assembly names are useful in the following scenarios:

  • Do you want your assemblies to refer to nodes with strong names, or you want to give your friend access to your assemblies from other assembly nodes with strong names.

  • The application needs access to different versions of the same assembly. This means that you need different versions of the assembly to load side by side in the same application domain without conflicts. For example, if assemblies that have the same simple name have different API extensions, strong naming provides a unique identifier for each version of the assembly.

  • You do not want to negatively affect application performance using your assembly, therefore you want the assembly to be neutral for the domain. This requires a strong name, because a domain-neutral assembly must be installed in the global assembly cache.

  • If you want to centralize the maintenance of your application using the publisher policy, this means that the assembly must be installed in the global assembly cache.

A source

0
source

Source: https://habr.com/ru/post/1202339/


All Articles