When should we not create Assembly's strong name? What are the disadvantages of "strong named assembly"?

Question

I have a project, i.e. library.exe. In this I have referenced an assembly (logging.dll ver 1.0.3.0) and I have given this assembly a strong name.

Now suppose I changed a method in logging.dll and made version 1.0.4.0.

Now when I copy/replaced the old DLL with this new one I got an exception. I know that exception is because I have changed version number of the DLL. As it was a strong name DLL it's not allowed unless I rebuilt library.exe.

What I want to say with above story is

1. Use strong name with assembly only when we have to add it to GAC.
2. If we have an application where individual assemblies requires updating do not use strong named assemblies.

Am I correct with point 1 and 2?

When should strong named assemblies not be used?

What are the disadvantages of "strong named assembly"?

Answer 1

It is only really needed if you want to place your assemblies in the GAC, but it also helps against tampering. It is fairly easy to change the code in an assembly so this gives bad people an advantage. When you are using strong named assemblies you are signing it with a private key only you have. People could still change your assembly, but they can't give it the same strong name, because they do not have your private key. In that case .Net refuses the assemly tamperd with. When they sign your assembly with a new private key the .Net still refuses to load it since the identity of the assembly has changed.

There are several ways to solve the versioning problem. When your application wants to load a v1 assembly you could tell it to look voor a v2 anyway. See here for more information. The other option would be not to change the Assembly Version at all, but to change the File Version of the assembly only. For .Net the assemblies are the same, but you and your installer can still see which one is newer. See the AssemblyFileVersion attribute.