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


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

!
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

"

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.

#
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,

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.

#
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.

******************************
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
®

!
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

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

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

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();

}
// ...
}
}

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.

-
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