Tài liệu Module 4: Deployment and Versioning doc

Introduction to Application Deployment Introduce common concepts, such as the Microsoft .NET Framework hierarchy of namespaces, the organization of assemblies, and the role of the assemb

Contents

Overview 1

Introduction to Application Deployment 2

Application Deployment Scenarios 7

Lab 4: Packaging and Deployment 37

Review 42

Module 4: Deployment and Versioning

domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred Complying with all applicable copyright laws is the responsibility of the user Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2001-2002 Microsoft Corporation All rights reserved

Microsoft, ActiveX, BizTalk, IntelliMirror, Jscript, MSDN, MS-DOS, MSN, PowerPoint, Visual Basic, Visual C++, Visual C#, Visual Studio, Win32, Windows, Windows Media, and Window NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of actual companies and products mentioned herein may be the trademarks of their respective owners

Instructor Notes

After completing this module, students will be able to:

! Package and deploy simple and componentized applications

! Create strong-named assemblies

! Install and remove assemblies from the global assembly cache

! Configure an application to control its binding to an assembly based on the assembly’s location and version data

Materials and Preparation

This section provides the materials and preparation tasks that you need to teach this module

Required Materials

To teach this module, you need the Microsoft® PowerPoint® file 2349B_04.ppt

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the lab

Presentation:

90 Minutes

Lab:

50 Minutes

Module Strategy

Use the following strategy to present this module:

! Introduction to Application Deployment Introduce common concepts, such as the Microsoft NET Framework hierarchy of namespaces, the organization of assemblies, and the role of the assembly manifest Describe simple and componentized applications, and their configuration and distribution scenarios

! Application Deployment Scenarios The examples in this section show how to deploy a simple stand-alone application, an application that uses a shared assembly, and an application that makes use of assembly versioning

Introduce compapp, a componentized application, which uses multiple assemblies Contrast compapp with the simple single assembly Hello

World application that was created in Module 2, “Introduction to a

Managed Execution Environment,” in Course 2349B, Programming with

the Microsoft NET Framework (Microsoft Visual C#™ NET)

! Related Topics and Tools Briefly introduce additional topics that are related to deployment and versioning but are beyond the scope of this course This section also provides a list of tools that you can use to work with assemblies

You should just inform the students of these topics and encourage them to look for more information in the NET Framework Software Development

Kit (SDK) documentation In addition, Course 2350A, Securing and

Deploying Microsoft NET Assemblies (Prerelease), covers code access

security and role-based security in greater detail

Overview

! Introduction to Application Deployment

! Application Deployment Scenarios

! Related Topics and Tools

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

This module introduces the concepts of packaging and deployment of Microsoft® .NET Framework applications and assemblies The NET Framework provides improved isolation of application assemblies, simplified application deployment, and robust versioning

This module walks you through the packaging and deployment of a simple Hello World application, and a small, componentized application These applications are written in C#, the new language designed for the NET Framework The steps that are necessary to construct, compile, and run C# applications were explained in Module 2, “Introduction to a Managed Execution Environment,” and Module 3, “Working with Components,” both in

Course 2349B, Programming with the Microsoft NET Framework (Microsoft

After completing this module, you will be able to:

! Package and deploy simple and componentized applications

! Create strong-named assemblies

! Install and remove assemblies from the global assembly cache

! Configure an application to control its binding to an assembly based on the assembly’s location and version data

In this module, you will learn

about packaging and

deployment of Microsoft

.NET Framework

applications and

assemblies

" Introduction to Application Deployment

! Common Concepts

! Simple Applications

! Componentized Applications

! Configuration and Distribution

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

You can deploy a NET Framework application in several ways depending on the following considerations:

! The complexity of the application

! The sharing of assemblies with other applications

! The application’s security and protection requirements

! The application’s method of distribution

An application’s deployment is not affected by the NET Framework common language runtime-compatible language that is used to develop the application All applications that are written for use with the NET Framework are compiled

to the same self-describing, Microsoft intermediate language (MSIL) code and run with he same NET Framework runtime

This section introduces common concepts, such as the NET Framework hierarchy of namespaces, the organization of assemblies, and the role of the assembly manifest It then describes simple and componentized applications, and their configuration and distribution

Topic Objective

To introduce issues that

arise in application

deployment and to introduce

the topics in the section

Lead-in

You can deploy a NET

Framework application in

several ways

Common Concepts

! Classes and Types Used in NET Framework Applications Are:

# Organized in a hierarchy of namespaces

# Stored in PE files, such as DLLs and EXEs

# Fully described by metadata

! Assemblies:

# Are made up of one or more PE files

# Contain a manifest that identifies the assembly and its files

# Specify exported and imported classes and types

# Are units of deployment, reuse, and versioning

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

As you learned in Module 2, “Introduction to a Managed Execution

Environment,” in Course 2349B, Programming with the Microsoft NET

Framework (Microsoft Visual C# NET), in addition to the common language

runtime, the NET Framework provides a common class library that is organized into a hierarchical tree of namespaces

At the root of this hierarchy is the System namespace, which contains objects

for many other useful classes that can be used from any NET-compatible language These objects include objects that are used for file I/O, messaging, networking, and security

The Organization of PE Files into Assemblies

The NET Framework class library that you and others create are also organized into hierarchical namespaces and stored in portable executable (PE) files, most typically DLLs and EXEs A single PE file can contain several namespaces, including nested namespaces You also can split a namespace across multiple

PE files One or more PE files, and possibly non-PE files, such as resources, are combined to create an assembly, which is a physical unit that can be deployed, versioned, and reused

The Role of the Assembly Manifest

In the NET Framework, each class type is fully described through the type’s metadata Each assembly contains a manifest that includes the name of each type that is exported from the assembly, along with information about the file that contains that type’s metadata The manifest also includes information about the identity of the assembly, such as name, files that make up the assembly, and version information, and full information about any dependencies on other assemblies

The NET Framework runtime uses assembly manifests to locate and bind to the referenced types

Topic Objective

To review the organization

of the NET Framework

class library and

assemblies, and the role of

the assembly manifest

Lead-in

The NET Framework

provides a common class

library that is organized into

a hierarchical tree of

namespaces

For Your Information

This topic reviews

information that was

covered in Module 2 Do not

spend much time on this

topic Present the material

as the starting point for a

discussion of deployment

and versioning

Simple Applications

! Require NET Runtime Be Installed on Local Computer

! Can Be Run Directly from a File Server or Copied Locally

! Make No Registry Entries

! Cannot Break Another Application

# Eliminate DLL Hell

! Can Be Uninstalled by Deleting Locally Copied File(s)

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

In the simplest case, a NET Framework application can be executed locally on any computer on which the NET runtime is already installed The program can run directly from a file server, or the files can be copied locally Nothing else is required No registry entries are made, and no other applications are broken or caused to stop running as a result

The fact that no registry entries are made eliminates DLL versioning issues, commonly referred to as “DLL hell.” Just deleting the executable file, if it was copied locally, is sufficient to remove the application and leave no trace on the computer

Topic Objective

To describe how easily an

application can be executed

in the NET Framework

Lead-in

In the simplest case, a NET

Framework application can

be executed locally on any

computer on which the NET

runtime is already installed

Componentized Applications

! Assemblies Private to an Application

# Same as a simple application

! Assemblies Private to Related Applications

# Deployed into a common subdirectory

! Assemblies Shared with Other Unrelated Applications

# Require a strong name and version information

# Deployed into the global assembly cache

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Componentized applications are only slightly more complex than simple applications The complexity of componentized applications depends on whether their components are:

! Contained in assemblies that are private to the application

! Shared with other related applications

! Shared with other potentially unknown applications

If all of the component assemblies are private, the componentized application can be treated in the same manner as the application The application can run from a file server, or the application files can be copied to a local volume Deleting all of a componentized application’s files is sufficient to remove the program

Likewise, if several related applications use the same component assemblies, those assemblies can be located in a common subdirectory However, if the application uses assemblies that are shared with other unrelated applications, these assemblies can be installed in the global assembly cache and have certain properties, such as a unique strong name that includes version information, that enable the NET runtime to ensure that the application binds to the appropriate versions

are only slightly more

complex than applications

Configuration and Distribution

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

As a developer of NET Framework applications, you should be aware of the different ways in which applications may be configured and packaged for distribution Usually, individual organizations, or an administrator within an organization, decide how an application is packaged for distribution and configured for the organization

Configuration

In the NET Framework, you can maintain application configuration in plain text files This use of plain text XML-based application configuration files allows administrators to tailor an application’s behavior on a particular computer without having to involve developers in the process

The following section, Application Deployment Scenarios, presents several common application scenarios While this module does not cover ASP.NET deployment, most of the concepts that are presented in this module apply to ASP.NET deployment

Deployment

Many client applications may be further packaged in a common distribution format, such as a CAB file or MSI file Client applications may also be installed by using application distribution mechanisms, such as Microsoft Windows® 2000 IntelliMirror® or Microsoft Systems Management Server (SMS), which both use the Microsoft Windows Installer technology

The Microsoft Windows Installer is an installation and configuration service that is included in the Windows 2000 operating system It is provided in a service pack to Microsoft Windows 95, Microsoft Windows 98, and Microsoft Windows NT® version 4.0

For more information about the Microsoft Windows Installer, see the Platform SDK documentation

Topic Objective

To introduce options for

configuring and deploying

applications in the NET

Framework

Lead-in

As a developer of NET

Framework applications,

you should be aware of the

different ways in which

applications may be

configured and packaged for

distribution

" Application Deployment Scenarios

! Deploying Multiple Versions of a Strong-Named Assembly

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

The examples in this section show how to deploy a simple application, an application that uses a shared assembly, and an application that makes use of assembly versioning

! Deploy the Application by:

# Running the executable file directly from a file server, or

# Installing it locally by copying the file

# Uninstall the application by deleting the file

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

In Module 2, “Introduction to a Managed Execution Environment,” in Course

2349B, Programming with the Microsoft NET Framework (Microsoft

Visual C# NET), you looked at the simplest NET Framework application, the

traditional Hello World application written in C# The C# source code for that program, HelloDemoCS, is as follows:

using System;

class MainApp { public static void Main() { Console.WriteLine("Hello World using C#!");

} }

This simple executable file prints a single line to the System.Console, a type

that is contained in the NET Framework class library It does not reference any other libraries and does not itself produce a library

Topic Objective

To explain how a simple

application is deployed

Lead-in

In Module 2, you looked at

the simplest NET

Framework application, the

traditional Hello World

application written in C#

For Your Information

Point out that while Hello

World is simplistic, it is

extremely versatile in its

ability to easily demonstrate

many new concepts of the

.NET Framework, including

deployment and versioning

Using Microsoft Intermediate Language Disassembler to Examine Hello World

Compiling this small application generates the HelloDemoCS.exe

To use Microsoft Visual Studio® NET tools within a command prompt window, the command prompt window must have the proper environment settings The Visual Studio NET Command Prompt window provides such an environment To run a Visual Studio NET Command Prompt

window, click Start, All Programs, Microsoft Visual Studio NET, Visual Studio NET Tools, and Visual Studio NET Command Prompt

If you run the Microsoft intermediate language (MSIL) disassembler (Ildasm.exe) against this executable file, a window appears, similar to the following illustration

The simple Hello World application highlights a particularly important concept behind programming for the NET Framework The application is clearly self-describing: all of the information that is needed to understand the application is contained in the metadata

The MSIL disassembler shows the classes or types that are created within the application In the case of the Hello World application, the only class is

MainApp The MSIL disassembler also shows the methods Main and a default

constructor, indicated by ctor The program does not have any other members

To save information about the assembly to a file, use the Dump command on the File menu

Important

To see additional information about the application, double-click Manifest The

following window appears

The preceding illustration shows the manifest, which contains information about the assembly, including the version (not yet set), external libraries, and types within those libraries, which the application uses

Deployment

Deployment to computers on which the NET runtime is installed is a simple process The Hello World application can run directly from a file server More advanced programs may involve security issues

In the simple Hello World case, no files are placed on the workstation, no entries are made in the system registry, and, in effect, there is no affect on the client workstation There is also nothing to clean up because there is nothing to remove on the client workstation

As you would expect, HelloDemoCS.exe can also be copied to a local volume

In this scenario, you can remove the program by deleting the file, and as before, nothing would remain on the workstation

Whether you run HelloDemoCS.exe from a file server or copy it to a local volume, running this application will not break another program, and no other application can cause HelloDemoCS.exe to stop functioning

A Componentized Application

! Assembly Component to Be Used by Application

# Assembly Stringer.dll is built from Stringer.cs as follows:

! Client Needs to Reference Assembly

! Deployment by File Server or Local Copy

csc /target:library Stringer.cs

csc /reference:Stringer.dll Client.cs

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

The Hello World application that is discussed in the preceding topic is completely trivial and hardly representative of even the simplest real-world

application This topic covers compapp, a componentized application, which

uses multiple assemblies

The Hello World application

that is discussed in the

preceding topic is

completely trivial and hardly

representative of even the

simplest real-world

application

Creating Stringer.dll

The client, Client.exe, calls types that are contained in a component assembly

that is named Stringer (Stringer.dll) The source code for the Stringer

assembly, is located in Stringer.cs:

using System;

namespace org { public class Stringer { private string[] StringSet;

public Stringer() { StringSet = new string[] { "C# String 0", "C# String 1", "C# String 2", "C# String 3"

};

} public string GetString(int index) {

if ((index < 0) || (index >= StringSet.Length)) { throw new IndexOutOfRangeException();

return StringSet[index];

} public int Count { get { return StringSet.Length; } }

} }

A client application that uses this component could fully qualify a reference to

the Stringer class, for instance, as org.Stringer Alternatively, a client application could include a using statement to allow easy access to the types in

Stringer.dll by specifying the namespace, as shown in the Client.cs source code: using System;

using org;

class MainApp { public static void Main() { Stringer myStringComp = new Stringer();

string[] StringsSet = new string[4];

// Iterate over component's strings Console.WriteLine("Strings from StringComponent");

for (int index = 0; index < myStringComp.Count; index++) {

StringsSet[index] = myStringComp.GetString(index); Console.WriteLine(StringsSet[index]);

} //

} }

Building the Application

To build this componentized application, you first build the Stringer.dll assembly component Then, you build Client.exe, importing the Stringer component by using the name of the file that contains the manifest, Stringer.dll,

rather than the namespace name, which is org in this case

csc /target:library Stringer.cs csc /reference:Stringer.dll Client.cs The MSIL disassembler displays the Stringer.dll and shows all of the members,

as in the following illustration

Like HelloDemoCS.exe, Client.exe contains manifest information about itself, the System library, and the types that the application uses However, the

manifest now contains information about the Stringer assembly

A MSIL disassembler display of the manifest for Client.exe shows the reference

to the Stringer assembly, as in the following illustration

Deployment

Like the simple application, Client.exe can run directly from a file server on any workstation that has the NET runtime installed Client.exe and Stringer.dll can also be copied to a local volume To remove the application, you need only delete the two files

Specifying a Path for Private Assemblies

! Specifying a Directory From Which to Load Private Assemblies.

# Client.exe.config file specifies a privatePath tag

! Configuration File’s XML Tags Are Case-Sensitive

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<probing privatePath=“MyStringer"/>

</assemblyBinding>

</runtime>

</configuration>

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

The preceding Client.exe example has one important weakness: both Client.exe and Stringer.dll reside in the same directory In the real world, an administrator may wish to use a directory structure to manage assemblies The NET

Framework provides a configuration mechanism that allows administrators to specify a directory from which to load private assemblies

Locating Stringer.dll and Client.exe in Separate Directories

Using the preceding Client example, all of the source code is the same, but for illustration purposes the build process has been modified so that the component application’s Stringer.dll is built in its own subdirectory named MyStringer

cd \compapp csc /target:library /out:MyStringer\Stringer.dll!

MyStringer\Stringer.cs csc /reference:MyStringer\Stringer.dll Client.cs

Using a Configuration File to Locate Assemblies at Run Time

Although the /reference: compile option locates an assembly in a directory

when compiling the program, a separate XML-based application configuration file is required at run time to support assemblies that are located in other directories For client executable files like the examples that are covered in this module, the configuration file resides in the same directory as the executable file The configuration file has the complete name of the executable file with an additional extension of config

Topic Objective

To show how to use a

configuration file to specify a

path for private assemblies

The Client.exe configuration file is called Client.exe.config It specifies a privatePath attribute, as shown in the following example:

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<probing privatePath="MyStringer"/>

</assemblyBinding>

</runtime>

</configuration>

The configuration file’s XML tags are case-sensitive

When this configuration file is placed in the same directory as the executable file, at run time, the NET Framework uses the privatePath attribute to determine where to look for components—in addition to looking in the application directory

When loading an assembly, the runtime also searches for a private path that is equal to the name of the assembly If the Stringer.dll assembly was located in a subdirectory named Stringer, instead of MyStringer, then a configuration file would be unnecessary

Deployment

Like the simple application, the revised Client.exe can run directly from a file server on any workstation that has the NET runtime installed Client.exe, Stringer.dll, and the application’s config file can also be copied to a local volume, using the same relative directory structure Deleting the files and directory effectively removes the application

While they are not used in the preceding example, it is important to know that

in addition to application configuration files, the NET Framework also supports separate user and Computer Configuration Files for many common configuration settings

Important

Note

A Strong-Named Assembly

! Global Assembly Cache

# Contains assemblies shared by unrelated applications

! Strong Names Are Required for Assemblies in the Cache

# Generate a public-private key pair:

# Add code to source file to specify version and key information:

# Compile:

#if STRONG [assembly: System.Reflection.AssemblyVersion("1.0.0.0")]

[assembly: System.Reflection.AssemblyKeyFile("orgKey.snk")]

#endif

#if STRONG [assembly: System.Reflection.AssemblyVersion("1.0.0.0")]

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

The client applications discussed in the preceding topics show the basics for constructing a complex program, but they are limited in that they only illustrate the use of assemblies that are private to the Client.exe and do not demonstrate the use of assemblies that are shared by more than one application

This topic discusses the problems that may occur when multiple applications share components It then introduces the use of strong names, the NET Framework solution to these problems

Issues with Sharing Components

Many applications use assemblies that are shared by more than one application These shared assemblies, which are typically provided by third-party

developers, are installed in a common location on the system, the global assembly cache By default, the system looks for each application’s assemblies

in the global assembly cache

In classic COM and COM+ applications, the sharing mechanism depends heavily on the Windows System Registry in which information about each component, including its version and physical file location, is stored This mechanism allows multiple applications to share a single component, but it also allows a component of a newly installed application to replace an existing component and possibly cause other applications to break

Such overwriting of existing components is often difficult to detect because the application that is causing the problem appears to work properly

Topic Objective

To discuss the problems

that may occur when

multiple applications share

components, and to

introduce the use of strong

names

Lead-in

The client applications

discussed in the preceding

topics are limited in that they

only illustrate the use of

assemblies that are private

to the Client.exe and do not

demonstrate the use of

assemblies that are shared

by more than one

application

is called the publicKeyToken

Strong names provide a strong integrity check Passing the NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built Note, however, that strong names in and of themselves do not imply a level of trust, such as that provided by a digital signature and supporting certificate

When component assemblies are associated with a distinct build, the system can isolate these component assemblies, thus allowing different versions to run at the same time for different client applications This system of protection is

sometimes called side-by-side execution It differs from backward compatibility

because with side-by-side execution, applications can run alongside other versions of the same applications without affecting their respective execution environments

You can facilitate side-by-side execution by assigning strong names to your

assemblies A strong name consists of the assembly’s identity, which includes

its simple text name, version number, and culture information, if provided, and

a public key

To demonstrate these additional build attributes the client and component

scenario is extended by adding an assembly named AReverser This assembly contains a class with a method that is named Invert, which uses the

System.Array.Reverse method to reverse an array of strings

The code details of AReverser are not relevant to deployment issues and

therefore are not shown This module’s lab contains the complete code details

Building the Assembly Without a Strong Name

You begin by building the new component assembly without specifying any

options to make it have a strong name First, you compile the new AReverser

assembly, as follows:

csc /target:library /out:AReverser.dll AReverser.cs

After compiling the new AReverser assembly, you can examine the metadata

by using the MSIL disassembler The MSIL disassembler indicates that the assembly does not have an established version number, as shown in the following code:

.assembly AReverser {

hash algorithm 0x00008004 .ver 0:0:0:0

} module AReverser.dll

Important

Note

Generating a Public-Private Key Pair

To create an assembly with a strong name, you must compile the assembly by using a private key Public keys are used for verification Therefore, before compiling the assembly, you must first generate a public-private key pair You use the Strong Name tool (Sn.exe) to generate a new key pair and place them in

a file, as in the following example:

sn –k orgKey.snk

Compiling a Strong-Named Assembly

Now that you have a private key, you are ready to compile the component, specifying the key file and the version number to be assigned You can do this

by specifying AssemblyVersion and AssemblyKeyFile attributes in the AReverser.cs file using the STRONG conditional compilation symbol:

#if STRONG [assembly: System.Reflection.AssemblyVersion("1.0.0.0")] [assembly: System.Reflection.AssemblyKeyFile("orgKey.snk")]

#endif

You must then define STRONG in the compile process:

csc /define:STRONG /target:library /out:AReverser.dll!

AReverser.cs

If you run the MSIL disassembler again on AReverser.dll, you can verify that

the assembly is now strong-named from the presence of a publickey property and a non-default version, which is specified by the ver property of 1:0:0:0

The following example shows the disassembled code:

.assembly AReverser {

publickey = (00 71 8A 7D 6A D7 ) .hash algorithm 0x00008004

ver 1:0:0:0 }

.module AReverser.dll For more information about the Strong Name tool, see Packaging and Deployment Tools in this module

Deploying Shared Components

! Installing the Strong-Named Component in the Global Assembly Cache

! Examining the Global Assembly Cache

! Removing a Shared Component File

gacutil /i AReverser.dll

gacutil /l

gacutil /u AReverser

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Deployment with strong-named assemblies is usually more complicated than deployment with assemblies that are not strong-named While components can easily be shared by related applications by putting them in a common

subdirectory, shared assemblies that are used by many applications on the system are often stored in the system’s global assembly cache

As with the previous examples of componentized applications, this revised Client.exe can run directly from a file server on any workstation on which the NET runtime is installed The Client.exe and Stringer.dll files can also be copied to a local volume

Installing a Strong-Named Assembly into the Global Assembly Cache

Installing the strong-named component into the global assembly cache requires the following additional command on the computer that will be running the corresponding Client.exe program:

gacutil /i AReverser.dll

You must have Administrator privileges on a computer to install assemblies into the global assembly cache Assemblies that are installed in the global assembly cache must have a strong name

After installing the AReverser assembly, you can then examine the system

assembly cache by typing:

gacutil /l

Topic Objective

To explain the commands

that are used to install,

examine, and remove

assemblies from the global

assembly cache

Lead-in

While components can

easily be shared by related

applications by putting them

in a common subdirectory,

shared assemblies that are

used by many applications

on the system are often

stored in the system’s global

assembly cache

Note