C#: why sign an assembly?

Question

Why would the previous author have signed the assemblies in this way?

No idea, maybe he wanted all his assemblies to be signed with the same key.

Is signing assemblies necessary and what would be wrong with not signing it?

No, it is not necessary but it is a mechanism allowing you to ensure the authenticity of an assembly. It allows you to ensure that an assembly hasn't been tampered with and indeed it origins from this author. It is also necessary if you want to put them into the GAC.

What disadvantages are there in signing assemblies - does it cause delays?

Signed assemblies can only load other signed assemblies. Also they are tied to a specific version meaning that you need to use binding redirects or recompile the application if you wanted to use a different version. There's a little performance overhead as well due to the verification of the signature but it is so little that you shouldn't be concerned about.

You need to sign assemblies if you want to put them in the GAC.

If you sign an executable, then any class libraries it links to also needs to be signed. This can be difficult if you're using a third-party library (especially if you need to use an ActiveX control or similar).

Richard Grimes have written a good workshop about security in .NET and that includes a chapter about this: Security Workshop

The reason for all the assemblies being signed with the same .snk file could be if he used unit testing with code coverage. To be able to do code coverage (at least with the tools built into the testing version of Visual Studio 2005) and if the assemblies are signed, you need to specify what .snk files are used for the signing, but I think you can only specify one .snk file for the whole solution, so if you sign the various class libraries with different .snk files you can only check the code coverage on one of them at a time.

A very important reason to sign an assembly is so you can be sure it is your assembly. Since the private key is yours, nobody else can sign an assembly with that same key. This means that when the public key of an assembly is one you know (you can retrieve this using the GetType().Assembly.GetName().GetPublicKey() function), the assembly is yours and it has not been tampered with.

If you would excuse me for answering an old question. But most of the responses here imply that strong-naming provides security. But Microsoft advises against using it for security.

The docs on strong name signing currently says:

⚠ Warning

Do not rely on strong names for security. They provide a unique identity only.

It is mostly useful for ensuring that you have the binary you expected, and not a different binary that incidentally has the same name and version (or version set by binding redirect)

Microsoft lists reasons for using strong-naming:

• 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.
• 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.
• 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.
• You want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

It also notes:

For .NET Core, strong-named assemblies do not provide material benefits.

and

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

So, Microsoft says it's okay to just publish your strong-naming private key along with code. Meaning anyone could create strong-named assemblies with the correct public key. I would it say it is safe to assume that strong-naming is not a secure source of Authenticity.

Read more about it here: https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named

Inspite of all the usages of signing dll, the dll should be signed for only two reasons

1. Versioning

2. Authentication

a. Versioning denotes what version the dll has been build on and while pushing them into GAC two dll with same name can exists but different version

b. Authentication denotes whether the dll is not tampered and does exists the same when it was created.

If you want to understand more about the basics and dll signing you can refer here