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

Contents
Overview 1
Introduction to Application Deployment 2
Application Deployment Scenarios 7
Related Topics and Tools 31
Lab 4: Packaging and Deployment 37
Review 42

Module 4: Deployment
and Versioning


Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
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.



Module 4: Deployment and Versioning iii


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
iv Module 4: Deployment and Versioning


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.

Module 4: Deployment and Versioning 1


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
Visual C#
™
.NET).
Because this course is an introduction to programming in the .NET Framework,
you should spend some time reading the .NET Framework Software

Development Kit (SDK) documentation. In fact, the labs, demonstrations, and
material for this module and other modules in this course are based on several
tutorials in the .NET Framework SDK.
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.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about packaging and
deployment of Microsoft
.NET Framework
applications and
assemblies.
2 Module 4: Deployment and Versioning


"
""

"

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.
Module 4: Deployment and Versioning 3


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.
4 Module 4: 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.
Module 4: Deployment and Versioning 5


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.

Topic Objective
To describe how assemblies
are handled in
componentized applications.
Lead-in
Componentized applications
are only slightly more
complex than applications.
6 Module 4: Deployment and Versioning


Configuration and Distribution
!
Configuration
#
Maintained in plain-text files
!
Deployment
#
Common distribution formats, such as a .CAB file
or a .MSI file
#
Common distribution mechanisms, such as
Windows 2000 IntelliMirror or Microsoft Systems
Management Server

*****************************
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.
Module 4: Deployment and Versioning 7


"
""
"

Application Deployment Scenarios
!
A Simple Application
!
A Componentized Application
!
Specifying a Path for Private Assemblies

!
A Strong-Named Assembly
!
Deploying Shared Components
!
A Versioned Assembly
!
Creating Multiple Versions of a Strong-Named Assembly
!
Binding Policy
!
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.
Topic Objective
To introduce the topics in
the section.
Lead-in
This section shows how to
deploy a variety of
applications, from simple
applications to applications
that make use of assembly

versioning.
8 Module 4: Deployment and Versioning


A Simple Application
!
Use the Microsoft Intermediate Language Disassembler
(Ildasm.exe) to Examine the Assembly Manifest
#
Version information
#
Imported types
#
Exported types
!
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.
Module 4: Deployment and Versioning 9


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.
Importan
t
10 Module 4: Deployment and Versioning


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.
Module 4: Deployment and Versioning 11


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 /target:library Stringer.cs
csc /reference:Stringer.dll Client.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.
Topic Objective
To introduce compapp, a
componentized application,
which uses multiple
assemblies.
Lead-in
The Hello World application
that is discussed in the

preceding topic is
completely trivial and hardly
representative of even the
simplest real-world
application.
12 Module 4: Deployment and Versioning


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; }
}
}
}

Module 4: Deployment and Versioning 13


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.

14 Module 4: Deployment and Versioning


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.

Module 4: Deployment and Versioning 15


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>
<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.
Lead-in
The .NET Framework
provides a configuration
mechanism that allows
administrators to specify a
directory from which to load
private assemblies.