This article has been 
excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors 
of C# Corner.
Assemblies can be digitally signed with a strong name, which consists of a 
public key, simple text assembly name, version number, and culture. The public 
key provides an assembly with a unique name, and strong-name signing assures 
users that the assembly has not been altered since being signed. Strong names 
use public-key encryption and digital signature techniques to guarantee secure 
code distribution. Code signing prevents attacks from hackers who tamper with 
code or impersonate the identity of a publisher. 
Code signing uses Public-Key Infrastructure (PKI) methods to give your code a 
unique identity. These PKI methods are complex mathematical functions used to 
prevent others from assuming the publisher's identity. Code signing ensures that 
your code has not been tampered with after you signed it. 
You can use the Strong Name command-line tool (Sn.exe) for many purposes when 
working with shared components that reside in shared assemblies. You can 
generate a new public-private key pair and write that pair to a file by adding 
the -k option to the following command: 
sn -k <outputfile> 
You can verify an assembly has a strong-name signature with the -v[f] option, as 
follows: 
sn -v[f] <assembly> 
You can verify that a particular assembly is signed using a particular key file. 
You can extract a public key from a key pair in a file and export it to a 
separate file with the -p option, as specified in this command: 
sn -p <inputfile> <outputfile> 
You can verify that the same key pair signed both components if the –t and –T 
options on the following commands produce the same key token: 
sn -t <outputfile> 
sn -T any.dll 
One last example illustrates the two steps needed when you want to attach a 
strong-name signature to your code:
- Create the strong-name key and compile 
your assembly with key you generated. You create a key pair and view the 
public key portion. Then you need to make an identity demand for code signed 
with the corresponding private key.  
 
 - sn -k mykeypair.dat  - sn -p mykeypair.dat mypublickey.dat  - sn -tp mypublickey.dat 
- Now add a declaration to the code in your 
assembly to indicate the location of the file generated in step one, as 
shown in Listing 22.11. 
Listing 22.11: AssemblyKeyFile 
[assembly:AssemblyKeyFile("mykeypair.dat")]
public
class MyClass
{
//class
}
The SN tool offers yet another feature: the delayed signing of an assembly. In 
simple terms, this feature reserves a place for the signature in the assembly 
manifest, but you do not initially sign the assembly with a private key. In 
delayed signing, the SN signature is applied after the assembly has been built 
and tested. Bear in mind that assembly developing and publishing tasks can be 
separated and assigned to different people. Delayed signing is helpful when the 
assembly's developer does not have access to the private key that will be used 
to generate the signature-a common occurrence during the development and testing 
phase of applications. (In fact, it is a good security practice to limit the 
number of people who have access to the private key.) 
When the assembly is built with AssemblyDelaySign set to true, as shown here, 
the CLR books space for the strong-name signature and stores the public key in 
the assembly. 
[assembly:AssemblyDelaySign (true)]
Please note that the /delaysign+ and /keyfile options can also be used with the 
Assembly Generation tool (Al.exe) to create delay-signed assemblies. 
Conclusion
Hope this article would have helped you in understanding the 
SN Tool in .NET. See other articles on the website on .NET and C#.
| ![visual C-sharp.jpg]() 
 | The Complete Visual 
C# Programmer's Guide covers most of the major components that make 
up C# and the .net environment. The book is geared toward the 
intermediate programmer, but contains enough material to satisfy the 
advanced developer. |