Understanding the .NET Framework - Signing an Assembly
(Page 8 of 8 )
In addition to setting an assembly's permissions, you can also sign the assembly to ensure its authenticity. There are two ways of signing an assembly. You can give an assembly a strong name and/or you can add a signcode digital signature to the assembly. Signing an assembly with a strong name adds a public key encryption to the assembly. Strong names ensure name uniqueness, and they are designed to prevent name spoofing. The strong name is stored in the file containing the assembly manifest. Signcode is a different and potentially complementary method of ensuring trust. No level of trust is associated with a strong name, whereas signcode does enable trusting code based on its publisher. Signcode is implemented using PKI and requires a publisher to prove their identity to a third-party authority and obtain a certificate. This certificate is then embedded in your assembly and can be used by the CLR to trust the code's authenticity. The signcode signature is stored in a reserved slot in the assembly. Signcode signing of an assembly is best used when you already have a trust hierarchy that's using signcode signatures.
Security Policy | Location |
Enterprise | %runtime install path%ConfigEnterprisesec.config |
Machine | %runtime install path%ConfigSecurity.config |
User | %USERPROFILE%Application dataMicrosoftCLR security configvxx.xxSecurity.config (Windows 2000 and NT) |
| %WINDIR%usernameCLR security configvxx.xxSecurity.config |
Table 2-9. Security Policy Files

Figure 2-7. Using the .NET CFramework Configuration tool to set assembly security
Summary
In this chapter, you got a high-level overview of the .NET Framework. The .NET Framework, however, involves a lot more than you can fit into one chapter. In fact, several books have been written about it. For more detailed information about the .NET Framework, you can refer to Microsoft's .NET Framework Developer's Guide. In the next chapter, you'll get a closer look at the part of the .NET Framework that we database developer's really care about-namely, the System.Data Namespace, which provides the classes that make up ADO.NET.
This is chapter two of ADO.NET: The Complete Reference, by Michael and Denielle Otey (McGraw-Hill/Osborne, ISBN 0-07-222898-9, 2003). Check it out at your favorite bookstore today. Buy this book now. |
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |