C# 2005 Programmer’s Reference - chapter 42 pdf

918 CHAPTER 42 Instrumenting Applications with System.Diagnostics Types Runtime detection of program errors is an important capability. Similarly, it’s important to monitor the performance of a program. The next chapter shows how to capture runtime performance of an application. The System.Diagnostics namespace includes a framework for supporting performance counters. Performance counters enable a program to be monitored for performance and scalability. At a basic level, predefined system performance counters can be used to examine a program’s behavior. The performance counter framework supports customized performance counters for situa- tions where it’s necessary to monitor specialized behavior. Custom performance counters identify conditions specific to an application and must be explicitly managed by the application. Sampling provides more sophisticated monitoring of program performance. This tech- nique takes a number of samples and performs calculations on a regular basis. More so than other methods, the results of sampling can provide much more insight into a program’s capability. PART 10 Deploying Code CHAPTER 43 Assemblies and Versioning CHAPTER 44 Securing Code CHAPTER 45 Creating Visual Studio 2008 Setup Projects CHAPTER 46 Deploying Desktop Applications CHAPTER 47 Publishing Web Applications This page intentionally left blank CHAPTER 43 Assemblies and Versioning IN THIS CHAPTER . Inside Assemblies . Assembly Features . Configuration . Deployment Assemblies are the Common Language Infrastructure (CLI) logical units of functionality, providing identity, scope, security, and version management. Composed of one or more files, assemblies solve several problems that plague executable and library files on other platforms. Some of the more prominent aspects of assemblies are side- by-side deployment, full containment and self-description, and security. Some of these aspects are reminiscent of earlier programming methodologies but are much improved with unique approaches to avoiding known problems. Inside Assemblies Assemblies can be made up of one or more files. Each file can be either a module or another assembly. The contents of an assembly could include a manifest, type metadata, Intermediate Language (IL) code, and resources. One of the files in the assembly must contain a manifest. Figure 43.1 shows a possible assembly configuration. The example in Figure 43.1 shows three different files that make up an assembly. The main file, SomeAssembly.exe, contains all four elements of an assembly, including the assembly manifest. The other files, SomePictures.resources and SomeLibrary.netmodule, contain additions to the assembly. Resources are files that hold various types of reusable data. Possible contents include strings, icons, pictures, or sound files. An earlier chapter discussed creation of resource files to support localization. 922 CHAPTER 43 Assemblies and Versioning Resources IL Code IL Code Resources SomePictures.resources Type Metadata SomeLibrary.netmodule Type Metadata Manifest SomeAssembly.exe FIGURE 43.1 Assembly example. Content Type Description Culture Localization info Files List of files inside assembly Name Name of assembly Modules are always deployed as part of an assembly because they are not meant to be separate executable entities. A couple benefits include modularization and multilanguage integration. Modularization benefits come from the capability to separate code into logical entities, providing another way to group and manage code. Another benefit comes with the ability to pull code written in multiple languages into a single assembly. For example, if ModuleA contains code written in Managed C++ and ModuleB contains code written in VB, both of these modules can be compiled into an assembly with a C# source file that uses code in both modules. The following command line creates a module: csc /target:module SomeLibrary.cs This example creates the file SomeLibrary.netmodule. When you have a module, as created here, the following command line can add the module to an assembly: csc SomeAssembly.cs /addmodule:SomeLibrary.netmodule That command line creates a new assembly, SomeAssembly.exe, which includes a reference to the module SomeLibrary.netmodule. The /addmodule command-line option makes the resulting SomeAssembly.exe assembly reference the SomeLibrary.netmodule file. Therefore, the SomeLibrary.netmodule file must be in the same directory as the SomeAssembly.exe; otherwise, a FileNotFoundException exception is generated. Manifests As mentioned earlier, every assembly must have a manifest. The manifest may reside in its own file or within another file with other assembly elements. Manifests contain metadata about the assembly. Table 43.1 lists manifest contents. TABLE 43.1 Manifest Contents 923 Inside Assemblies 43 Content Type Description References Referenced assemblies Strong name Public key info Types List of types inside assembly Version Version number of assembly Attributes Several attributes decorate assemblies for various purposes. These attributes can be catego- rized as identity, informational, manifest, and strong name. Identity Identity attributes provide uniqueness to distinguish one assembly from another. The benefits of this are that different versions of an assembly may be running at the same time and there must be a way to tell each version apart. Programs also have the option to call the assembly they want to use by specifying culture or version requirements in their configuration files. Configuration files are explained later in this chapter. Table 43.2 outlines assembly identity attributes. Here are a couple examples of identity attributes: [assembly: AssemblyCulture(“en_US”)] [assembly: AssemblyVersion(“1.0.*”)] Informational The informational attributes impart knowledge about the origin of an assembly. These attributes tell which company created the assembly, copyright, trademark, and other proprietary information about the assembly. Table 43.3 outlines informational attributes of assemblies. Attribute Name Description AssemblyCompany Company name AssemblyCopyright Copyright info AssemblyFileVersion Win32 file version; defaults to assembly version TABLE 43.1 Continued TABLE 43.3 Informational Attributes TABLE 43.2 Identity Attributes Attribute Name Description AssemblyCulture Localization Info AssemblyVersion Version number of assembly AssemblyFlags Controls side-by-side execution 924 CHAPTER 43 Assemblies and Versioning TABLE 43.4 Manifest Attributes Attribute Name Description AssemblyConfiguration Config info such as Release or Debug AssemblyDefaultAlias Short friendly name of assembly AssemblyDescription Summary of what assembly is AssemblyTitle Full friendly name of assembly Attribute Name Description AssemblyInformationalVersion Product version number; not used by runtime AssemblyProduct Product information AssemblyTrademark Trademark information Here are some examples of identity attributes: [assembly: AssemblyCompany(“MyCompany”)] [assembly: AssemblyProduct(“My Product Name”)] [assembly: AssemblyCopyright(“Copyright 2001”)] [assembly: AssemblyTrademark(“TM Product Name”)] Manifest The manifest attributes explain what an assembly is and how it should be used. With a short name, full name, and description, a user can get a good idea of how to use the assembly. The configuration can provide insights into what environment and assembly can be used. Table 43.4 outlines assembly manifest attributes. Here are a few examples of identity attributes: [assembly: AssemblyTitle(“My Assembly”)] [assembly: AssemblyDescription(“Provides extensive widget support.”)] [assembly: AssemblyConfiguration(“Release”)] Strong Name The strong name attributes primarily support security. They identify the key, key file, and timing associated with various security issues. An assembly can have what is called a strong name, which consists of a combination of identity, manifest, and strong name attributes. Another section later in this chapter shows how to create a strong name for an assembly. Table 43.5 outlines strong name attributes for assemblies. Here are three examples of identity attributes: [assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile(“MyKey.snk”)] [assembly: AssemblyKeyName(“MyKeyContainer”)] TABLE 43.3 Continued 925 Assembly Features 43 TABLE 43.5 Strong Name Attributes Attribute Name Description AssemblyDelaySign Indicates whether delayed signing is used AssemblyKeyFile Name of key file AssemblyKeyName Name of key container Assembly Features Besides being just another executable program or library, an assembly offers several features that enhance program management and execution. The features of identity, scope, versioning, and security form a basis for assigning a strong name to an assembly. Identity An assembly is a unit of identity. For instance, a class named MyClass in an assembly named AssemblyOne is different from a class named MyClass in an assembly named AssemblyTwo. Scope Through proper use of the internal modifier, assembly types are visible only within that assembly. External assemblies won’t be able to see or access any types marked as internal. Versioning The ability to version assemblies allows a few key capabilities, such as automatic upgrades, enhanced deployment, and side-by-side execution. An assembly version is a 4-tuple sepa- rated by dots with the following format: <major>.<minor>.<build>.<revision> Table 43.6 shows the meaning of each position and a suggested method of implementation. TABLE 43.6 Assembly Version Numbers Position Description Major Major release number Minor Minor release number Build Intermediate build Revision Hot fix number 926 CHAPTER 43 Assemblies and Versioning The version may be specifically stated in the AssemblyVersion attribute or defaults may be accepted. In the following AssemblyVersion attribute, the major version is 1, the minor version is 0, and the build and revision version numbers will be assigned during compilation: [assembly: AssemblyVersion(“1.0.*”)] Security Public keys and certificates make assemblies inherently more reliable and secure than the libraries and executables developed in traditional machine-compiled languages. There are two ways to secure your assemblies: strong names and digital signatures. Strong Names Strong names consist of assembly name, version, culture, and public key. The following command line generates a key file to be used in applying a strong name to an assembly: sn –k Mykey.snk After a key file has been generated, it may be referenced in an assembly by specifying the generated key filename in an AssemblyKeyFile attribute as follows: [assembly: AssemblyKeyFile(“MyKey.snk”)] Certificates Certificates provide proof of code identity and are the secure complement to strong names. More specifically, a strong name alone does not guarantee authenticity of code. You need a certificate to prove identity. Normally, certificates are obtained through certification authorities such as Verisign and Thawte. However, for testing purposes there are a couple tools in the .NET Framework SDK that make it easy to create a test certificate. The makecert utility creates an X.509 certifi- cate, as the following example shows: makecert mycert.cer -sk mykey This command line creates an X.509 certificate named mycert.cer and a registry key named mykey. The certificate must be translated into a Software Publisher Certificate (SPC): cert2spc mycert.cer mycert.spc The cert2spc utility created a new SPC named mycert.spc, which contains the X.509 certificate specified in mycert.cer. Now that we finally have a certificate, the assembly may be signed as follows: signcode /spc mycert.spc /v mykey SomeAssembly.exe 927 Configuration 43 The signcode utility added the mycert.spc SPC, identified with the /spc switch, to the SomeAssembly.exe assembly. The key was the mykey registry key, which was created with the makecert. Now the SomeAssembly.exe assembly is signed and secure. The utilities in this section have many options to customize their functionality. Just use the –h option for help. In addition, executing the signcode utility without command-line options opens a wizard application that steps you through the certification process. Configuration Another benefit of assemblies is that they can be configured dynamically through configu- ration files. These files are written in XML, providing human-readable access to program configuration. There are basically two types of configuration files: machine and application. Machine configuration files hold configuration information for all applications running on a machine. In this light, they are intended to be more generic and applicable to multiple applications. Machine configuration files are located at %runtime install path%\Config\Machine.config. When running applications, the machine configuration file is consulted first, and then the application configuration file settings are applied. Executable application configuration files have the same name as the executable filename with the extension .config appended. For example if a program were named MyApp.exe, its configuration file would be named MyApp.exe.config. ASP.NET and web service config- uration files are named web.config. All configuration files have a <configuration> root element. Subsections are divided into startup, runtime, remoting, crypto, class API, and security settings. This chapter focuses specifically on assemblies, so I discuss startup and runtime settings in the next couple sections. Startup Configuration Startup configuration options are specified within the <startup> section of a configura- tion file. You would use this section to specify which version of the CLR to use. In version 1.0, the only optins was to use the requiredRuntime element, which could be configured as follows: <configuration> <startup> <requiredRuntime version=”1.0.2914.0” safeMode=”true”/> </startup> </configuration> According to this configuration file, a program must run with CLR version 1.0.2914.0. Setting the safeMode attribute to true enables a registry search to see whether this assem- bly was redirected to run against another version of the CLR. [...]... Zone 1.2.1 1.2.2 Nothing - MyComputer: FullTrust ApplicationDirectory: FullTrust - Intranet: LocalIntranet All code: Same site Web All code: Same directory FileIO - Read, PathDiscovery 44 Security is ON Execution checking is ON Policy change prompt is ON 942 CHAPTER 44 Securing Code 1.3 Zone - Internet: Internet 1.3.1 All code: Same site Web 1.4 Zone - Untrusted: Nothing 1.5 Zone - Trusted: Internet 1.5.1... assembly cache They’re self-contained entities that don’t require external catalogs or registries to enable their execution 43 This page intentionally left blank CHAPTER 44 Securing Code IN THIS CHAPTER Code-Based Security Role-Based Security Security Utilities The NET security model introduces a significant security enhancement, referred to as code-based security The need for code-based security has grown... runtime This is useful when a third-party library is upgraded and is also backward-compatible with the older version The following example shows how to redirect an assembly: . 10 Deploying Code CHAPTER 43 Assemblies and Versioning CHAPTER 44 Securing Code CHAPTER 45 Creating Visual Studio 2008 Setup Projects CHAPTER 46 Deploying Desktop Applications CHAPTER 47 Publishing. self-contained enti- ties that don’t require external catalogs or registries to enable their execution. This page intentionally left blank CHAPTER 44 Securing Code IN THIS CHAPTER . Code-Based. policy, for both code- and role-based security. Code-Based Security Code-based security is implemented via a multifaceted approach that pulls together cooperative security mecha- nisms to determine