.NET Web Services Solutions

Using the AssemblyInfo File to Customize Assembly Settings

When you create a program or web service within the .NET environment, Visual Studio .NET packages the program code into an assembly. In general, an assembly is a file that uses the .exe extension (for programs) or the .dll extension (for web services and class libraries). The assembly file contains the code for the program modules as well as a special document, called a manifest, that describes the assembly’s contents. In addition, the manifest contains specific information about the assembly itself, such as the assembly’s version number or the version number the program (or web service) requires for each of its component modules.

click to expand Figure 12.2: To edit a support file using Visual Studio .NET, simply double-click the file entry within the Solution Explorer.

As discussed, the assembly contains program code. Unlike a traditional .exe or .dll file that contains “native-mode” code (the 1s and 0s that correspond directly to the CPU’s instruction set), the assembly contains program code in an intermediate-language (IL) format. Before a system executes the assembly’s code, a special just-in-time (JIT) compiler on the system must convert the intermediate-language code into native-mode code the CPU can execute.

To better understand the contents of an assembly, you can use a special .NET command-line utility named ILDASM (for intermediate-language disassembler). For example, the following command displays the assembly contents for the Hello web service that you created in Chapter 2:

C:\SomeDirectory> ildasm Hello.dll <Enter>

In this case, the ILDASM utility will display the window shown in Figure 12.3, within which you can view the web service’s manifest information or the intermediate-language code for a specific module.

As discussed, the assembly’s manifest describes the assembly’s contents. If you double-click the Manifest entry within the ILDASM window, you can view the contents of the assembly manifest, as shown in Figure 12.4. Table 12.2 briefly describes the common manifest entries.

click to expand Figure 12.3: Using the ILDASM utility to display a web service’s assembly contents

Table 12.2:  Entries Common to a .NET Assembly

Assembly Entry

Purpose

.assembly

Specifies the assembly’s name

.assembly extern

Specifies the names of other assemblies used by this assembly

.class extern

Specifies the names of classes the assembly exports that are defined in a different module

.exeloc

Specifies the path to the assembly’s executable program

.hash algorithm

Specifies the algorithm the assembly used to create its hash values

.manifestres

Specifies the names of resources contained within the assembly

.module

Specifies the name of an assembly’s module

.module extern

Specifies the name of an assembly module that resides in a different assembly

.publickey

Specifies the assembly’s public key

.publickey token

Specifies a token value that represents the assembly’s public key

.subsystem

Specifies the assembly’s run-time environment

.ver

Specifies the assembly’s version information

Figure 12.4: Viewing a web service’s manifest content

Finally, using the ILDASM utility, you can disassemble and view a module’s intermediate-language code. To do so, click the plus signs that precede the module entries until you display the method you desire. Then, double-click the method’s entry. The ILDASM utility, in turn, will display the method’s intermediate-language code as shown in Figure 12.5.

Figure 12.5: Using the ILDASM utility to display a module’s intermediate-language code

Each time you create a .NET web service, Visual Studio .NET creates a file named AssemblyInfo.vb (or .cs if you are using C#), which contains entries you can use to customize assembly settings. Listing 12.1 illustrates the file’s default contents.

Listing 12.1 AssemblyInfo.vb

Imports System.Reflection Imports System.Runtime.InteropServices ' General Information about an assembly is controlled through the ' following set of attributes. Change these attribute values to ' modify the information associated with an assembly. ' Review the values of the assembly attributes <Assembly: AssemblyTitle("")> <Assembly: AssemblyDescription("")> <Assembly: AssemblyCompany("")> <Assembly: AssemblyProduct("")> <Assembly: AssemblyCopyright("")> <Assembly: AssemblyTrademark("")> <Assembly: CLSCompliant(True)> 'The following GUID is for the ID of the typelib if this project is ' exposed to COM <Assembly: Guid("E15D39B3-FF3B-4B4B-A07A-FF3A2838E8EB")> ' Version information for an assembly consists of four values: ' ' Major Version ' Minor Version ' Build Number ' Revision ' ' You can specify all the values or you can default the Build and ' Revision Numbers by using the '*' as shown below: <Assembly: AssemblyVersion("1.0.*")>

For years, developers have battled conflicts that arise due to the release of a new version of a .dll file. The .NET environment is unique in that it allows multiple versions of the same .dll file to exist side by side. In fact, a program can actually use more than one version of a .dll file. The .NET environment takes advantage of version information that exists in each assembly. As you release a new version of your web service, you should edit the AssemblyInfo file and update the version number the assembly contains.

Related

Категории