Avoid strong naming (if you can)! Strong naming is a complete pain.
As soon as you strong name an assembly, everything that it references has to be strong named as well. In a simple application, no big deal. If you have to deal with COM interop libraries etc., other projects, etc the problem becomes a maintenance nightmare.
This is a good read.
From the link: Strong naming assemblies has many advantages:
- Trust. Users of the assembly can trust that it came from the signee, such as Red Gate Software, thanks to the public key cryptography involved.
- Tamper prevention. Users of the assembly can trust that nobody has tampered with it since the signee released it. The .NET runtime will not load assemblies whose signed hash doesn’t match their current hash.
- Compatibility with the GAC. The global application cache only accepts strong named assemblies.
It also has disadvantages:
- “The const problem”, or “One naming policy to rule them all”. Strongly named assemblies cannot use assemblies which aren’t strongly named. Like a virus, strong naming must spread throughout an application, or perish. This causes difficulties interacting with open source or other unsigned, third party components.
- Version coupling. Since an assembly’s strong name includes its version, the .NET framework generally requires that, if assembly A is using assembly B, the exact version of assembly B against which A was linked must be available at runtime.
- Compatibility with the GAC. The global application cache only accepts strong named assemblies.
I've not had much fun dealing with strong named assemblies in the past, particularly ones which expose interfaces for shared applications. You end up having to engineer round the strong named assembly (e.g. using publisher policy)