We're using a global file called GlobalAssemblyInfo.cs and a local one called AssemblyInfo.cs. The global file contains the following attributes:
[assembly: AssemblyProduct("Your Product Name")]
[assembly: AssemblyCompany("Your Company")]
[assembly: AssemblyCopyright("Copyright © 2008 ...")]
[assembly: AssemblyTrademark("Your Trademark - if applicable")]
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyVersion("This is set by build process")]
[assembly: AssemblyFileVersion("This is set by build process")]
The local AssemblyInfo.cs contains the following attributes:
[assembly: AssemblyTitle("Your assembly title")]
[assembly: AssemblyDescription("Your assembly description")]
[assembly: AssemblyCulture("The culture - if not neutral")]
[assembly: ComVisible(true/false)]
// unique id per assembly
[assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")]
You can add the GlobalAssemblyInfo.cs using the following procedure:
- Select Add/Existing Item... in the context menu of the project
- Select GlobalAssemblyInfo.cs
- Expand the Add-Button by clicking on that little down-arrow on the right hand
- Select "Add As Link" in the buttons drop down list
Both strong naming and digital signatures use public key cryptography to provide evidence about the origin of an assembly, so that you can apply security policy to determine what permissions are granted to the assembly.
They differ not in their technical details, but in what problems they are intended to solve.
The purpose of a strong name is solely to ensure that when you load an assembly by name, you are loading exactly the assembly you think you are loading. That is the only by-design purpose of a strong name. You say "I want to load Frobber, version 4, that came from FooCorp". The strong name gear ensures that you actually load precisely that DLL, and not another assembly called Frobber, version 4, that came from Dr. Evil Enterprises.
In order to achieve this, all that is required is that you know the public key token associated with FooCorp's private key. How you come to know that public key token is entirely your business. There is no infrastructure in place designed to help you get that information safely. You're just expected to know what it is, somehow.
The purpose of a digital signature from a publisher certificate is to establish a verifiable chain of identity and trust. The chain of trust goes from a hunk of code of unknown or uncertain origin up to a "trusted root" -- an entity which you have configured your operating system to trust. You download some code, and the code has a digital signature with a certificate from FooCorp. You examine the certificate and it says "this program comes from FooCorp. The accuracy of this certificate is vouched for by VeriSign." Since VeriSign is one of your trusted roots, you now have confidence that this code actually did come from FooCorp.
Notice how much more complex the problem solved by digital signatures is. We're not trying to simply determine "is this hunk of code associated with this name, or not?" Instead we're trying to determine where did this code come from, and who vouches for the existence of the company allegedly responsible, and should we trust that company?
The difference between strong names and digital signatures emphasizes what is hard about crypto-based security. The hard problem isn't the cryptography; that's just math. The hard problem is safely managing distribution of information about the keys and associating them with the correct entities. Strong names, because they attempt to solve a very small but important problem, do not have key management issues. Or, rather, they foist the key management problem off to you, the user. Digital signatures are all about trying to automate safe distribution of key information via certificates, in order to solve much more complex problems of trust and identity.
Is that clear?
(Great question; this will go up on my blog on September 3rd.)
Best Answer
The purpose of strong-naming is to ensure that when you load an assembly, you are loading the assembly that you think you're loading. So if you load assembly with full name
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL
the strong-name works to ensure that you load this assembly and that some evil corporation hasn't slipped another assembly in its place. Strong-naming will not help you prevent unauthorized access to your software.