Considering Other Deployment Issues | MCAD/MCSD: Visual Basic .NET XML Web Services and Server Components Study Guide

You have looked at using the Windows Installer setup project and the specifics of installing and deploying a Windows service, serviced component, and .NET Remoting object. Now you need to consider other deployment issues, such as registering COM components and .NET assemblies or adding components to the global assembly cache. In this section, you will look at registering components and assemblies, working with strong-named assemblies, deploying the GAC, and implementing component versioning.

Registering Components and Assemblies

The .NET Framework Assembly Registration utility (regasm.exe) enables you to register an assembly in the Registry for use by COM+ objects. You should give any assembly that you want used by COM+ a strong name. The assembly is not what COM+ interacts with, but you will notice that the mscoree.dll (the Common Language Runtime) is registered as the InprocServer32 for the class identifier (CLSID). The assembly is specified in another key, called assembly, that is used by the CLR to load the assembly.

In Exercise 10.9, you will register an assembly in the Registry by using regasm.

Exercise 10.9: Using regasm and the Registry Editor in a Windows Installer Project

Start a Visual Studio .NET command prompt.
Use the .NET Framework Assembly Registration utility to register the assembly that you created in Exercise 10.4 by typing the following:
```
regasm "c:\Document and Settings\My Documents\~CA your_user_name\Visual Studio Projects\bin\~CA debug\DynReg.dll" 
```
Verify that the assembly was registered by searching the Registry for DynReg.dll. Notice how the InProcServer32 points to the mscoree.dll, which is the Common Language Runtime. This is the COM+ object that is loaded; then the assembly key specifies the DLL or EXE of the assembly to load.

Working with Strong-Named Assemblies

A strong-named assembly is an assembly that has been signed by using a public key/private key pair generated by the sn.exe utility. A strong name uniquely identifies an assembly by generating a hash of the assembly’s manifest and then encrypting the hash with the private key. The encrypted hash is a signature and is stored in the manifest of the assembly. It is verified by the assembly’s client by using the public key of the key pair that is also included in the assembly’s manifest. Strong-named assemblies provide the following benefits:

They enable applications to run with the version of the assembly to which they were built. The signature along with the name, version, and culture ID of the assembly is recorded in the calling assembly’s manifest. This guarantees that your application will always use the right version of the assembly, unless the <assemblyBinding> configuration option overrides this.
They provide a strong code integrity check. The hash of the assembly computed at compile time is checked at runtime. If the result of the runtime check is different, then the assembly has been tampered with and it will not load. The strong name can also be used as evidence for code access security.
They make it possible to share assemblies. Only assemblies that have been signed can be registered in the GAC where they are shared. The strong name provides for strong binding to a specific version of the assembly and enables multiple versions of the same DLL to be installed and even loaded into an application domain at the same time. The strong name helps prevent a problem known as DLL Hell that plagued Windows and COM for years.
A strong-named assembly has more deployment options than a private assembly because you can place it in the GAC, which makes it available as a shared component on the system. Strong-named assemblies can also be used by COM components, and a serviced component must be strong named.

You create a strong-named assembly by using the sn.exe utility to generate a public key/private key pair in a file and then referencing the key file with the AssemblyKeyFile attribute from within the assembly. This attribute is located in the System.Reflection namespace. The following is an example of using the AssemblyKeyFile attribute to make a strong-named assembly:

Imports System.Reflection <Assembly: AssemblyKeyFile("c:\mykeyfile.snk")> Public Class Customer ... End Class

There is a file named AssemblyInfo.vb that is associated with each project that you create in Visual Studio .NET. This file contains all of these assembly-level attributes. It is compiled into the resultant assembly of the project and should be used for noting the author, version, keyfile, and so forth of the assembly.

Note

Remember that serviced components must be strong named.

Deploying to the GAC

A shared assembly is a strong-named assembly that is installed in the global assembly cache (GAC). The GAC is a code collection that is shared with all applications on the machine. Because it is shared by multiple applications, you must sign your assemblies so they can be uniquely identified and versioned. This prevents versioning issues by making sure the version of the assembly that you built—and more importantly, tested your application with—is the one that you bind to. An assembly is verified when it is installed in the GAC, and will not be installed if the hash does not match the encrypted version in the signature.

You can install an assembly in the GAC by using the Windows Installer project, the .NET Framework Configuration tool, the Global Assembly Cache tool (gacutil.exe), or Windows Explorer.

Using Windows Installer is the recommended way to deploy assemblies to the GAC in a production environment because it provides for assembly reference counting, which means it will keep track of the number of applications using the shared assembly and can remove it when it is no longer in use. Windows Installer packages also support installation through Active Directory software policies, giving users of your application an automated deployment option.

The gacutil.exe is a utility included in the .NET Framework to install strong-named assemblies in the GAC. It is run from a Visual Studio .NET command prompt, and although it has many options, here are the three most useful:

-i installs a strong-named assembly in the GAC.

-l lists the assemblies in the GAC.

-u uninstalls an assembly from the GAC.

The following example shows how to install an assembly in the GAC with gacutil.exe, assuming it has a strong name:

gacutil -i TestAssembly.dll

The .NET Framework Configuration tool is an Microsoft Management Console (MMC) snap-in that enables you to configure many aspects of your applications and the .NET Framework. You can add an assembly to the GAC by clicking Assembly Cache in the tree pane and then clicking the Add An Assembly To The Assembly Cache link in the right-hand pane. This will launch the Add Assembly To The Assembly Cache Wizard.

You can use Windows Explorer to drag and drop or to copy the assembly to the assembly cache that is represented as a directory called assembly under the Windows directory.

You can install the assemblies that you use for Windows services, serviced components, and Remoting objects in the GAC also. The main criteria you should use is whether this is a server-level resource or one just local to the application.

Serviced components hosted in a COM+ server application require registration in the GAC, whereas COM+ library applications do not. It is recommended that COM+ library applications be installed in the GAC also, because COM+ applications are generally server-level resources.

In Exercise 10.10, you will add the assembly that you created in Exercise 10.4 to the GAC by using the gacutil.exe utility.

Exercise 10.10: Installing an Assembly in the Global Assembly Cache

The assembly already has been given a strong name. Run the following command in a Visual Studio .NET command prompt:

gacutil /i "c:\Document and Settings\My Documents\~CA your_user_name\Visual Studio Projects\bin\~CA debug\DynReg.dll"

Verify the installation by navigating to the following path, %windir%\assembly, and looking for the assembly in the Windows directory.
You can also verify that it was installed by typing the following:
```
gacutil /l ComPlusStuff.DynReg
```
Use the following command to uninstall the assembly from the global assembly cache:
```
gacutil /u ComPlusStuff.DynReg
```

Implementing Component Versioning

Any assembly registered in the GAC is versioned. Whenever you build an assembly, it binds to a specific version of any shared assembly (an assembly registered in the GAC) that you use. If the user installs a newer version of the assembly on their computer, your assembly will still use the version it was compiled against. This strict version-binding can be overridden by a developer or administrator by using the <assemblyBinding> tag in the configuration files for the application.

The GAC can store multiple versions of the same assembly, which is called side-by-side deployment. The runtime checks the GAC first for a strong-named assembly before it begins probing directories for the assembly if it does not exist in the GAC.

You can control the version of your assembly by modifying the <Assembly: AssemblyVersion(1.0.*)>attribute in the AssemblyInfo.vb file. The AssemblyVersion attribute takes the following format for the version string: major.minor.build.revision. At a minimum, you need to specify the major portion of the version number. You can have part of the version number automatically populated if you use an asterisk (*), although you need to specify at least the major and minor portions of the version number.

Microsoft recommends specifying the version number by hand, but this can be a pain to do with every build in development, so they provided you with the asterisk (*). When you create a Release build, you should set the version number manually. If you use an asterisk, the build number will be set to the number of days since January 1, 2000 local time and the revision will be set to the number of seconds since midnight local time modulo 2. You can use an asterisk for just the revision number if you want, which will set it to the number of seconds since midnight local time modulo 2.

The following are examples of valid version numbers: 1, 1.1, 1.1.*, 1.1.1.*, 1.1.1, 1.1.1.1.

Real World Scenario—Using Versioning in .NET

You create an assembly called ABCGUI.dll that contains custom GUI interface components. These will be used by four applications that your company will be shipping. These applications will be released at different intervals over the next three years. Because of changing requirements on the applications, some of the GUI components might need to change in the ABCGUI.dll. You need to make sure that changes to the GUI components will not affect the applications that are already released if the ABCGUI.dll assembly changes.

You decide to take advantage of the side-by-side installation feature of the GAC. You give ABCGUI.dll a strong name. You add the AssemblyVersion attribute to the assembly and change the version for each build of the component by hand. You have the assembly being used by each application register in the GAC with a Windows Installer project used to install each application. You release the first application with the 1.0.0.0 version of the ABCGUI.dll. During the development of the second application, there are some major modifications made to the ABCGUI.dll assembly so it is released with version 2.0.0.0 of ABCGUI.dll. You test the install of both applications on the same machine; running ildasm.exe on the applications shows that the first application is using 1.0.0.0 of ABCGUI.dll and the second uses 2.0.0.0. Both assemblies exist in the GAC. This reduces the possibility of version conflicts between versions.