Origem do texto: http://msdn.microsoft.com/en-us/library/aa302347.aspx

Martin Wasznicky
Microsoft Corporation

January 2002

Summary: Examines and compares two approaches for deploying Microsoft .NET applications: the DOS XCOPY command, and the Microsoft Windows Installer technology. (8 printed pages)

Objectives

• Learn when and how to use XCOPY for deploying Microsoft® .NET solutions
• Learn when to use Microsoft® Windows® Installer for deploying .NET solutions

Assumptions

The following should be true for you to get the most out of this document:

• You are an experienced Microsoft® Visual Basic® programmer
• You have deployed applications using Microsoft® Visual Studio® Installer or Microsoft Windows Installer 2.0
• You have used the XCOPY DOS command
• You have access to .NET and Microsoft® Internet Information Server (IIS)

Contents

Introduction
Using XCOPY
Windows Installer
What's New in Visual Studio .NET?
Summary

Introduction

The Microsoft .NET Framework provides several new features poised to make application deployment as simple as an XCOPY operation. Many developers are familiar with the issues of deploying traditional COM applications; registering classes and type libraries, maintaining binary compatibility, and the lack of side-by-side component deployment (all of this is sometimes referred to as "DLL HELL"). Regedt32.exe has become a familiar tool in the developer's component deployment arsenal because of the dependencies that COM has with the registry.

With the introduction of assemblies and versioning to the .NET Framework, the umbilical cord to the registry is finally cut. Because assemblies are self-describing (they contain metadata describing, among other things, the types, resources, and referenced assemblies), their dependency on the registry is removed, making the promise of XCOPY deployments a reality.

However attractive XCOPY deployment sounds, like any technology, it has its limitations. Depending on the complexity and automation needs of a particular deployment scenario, XCOPY may not be able to live up to an application's deployment needs. In these cases, the .NET Framework integrates with Microsoft Windows Installer 2.0 technology to provide alternative setup, distribution, and deployment options for the developer. Furthermore, Visual Studio .NET provides setup and deployment projects, built on top of the Windows Installer 2.0 technology. This allows developers to easily create setup and deployment packages for the more complex applications built on the .NET Framework.

There are two major topics covered in this document:

• Using XCOPY: An overview of the DOS XCOPY command used as an instrument for deploying .NET applications. XCOPY uses and limitations will be discussed, including persisting security ACL information, file and folder attributes, folder system generation, and sharing violations.
• Windows Installer: An overview of the Windows Installer technology, and examining its capabilities as exposed by .NET. The appropriateness of when to use Windows Installer technology versus XCOPY is examined as well.

Using XCOPY

Deploying applications usually consists of distributing the final application or component to computers on which the application will run. Due to the self-describing nature of .NET assemblies, deployment and replication of .NET-built applications using XCOPY has become a reality because, in many cases, there is no longer a need to modify the registry or perform other ancillary tasks, like stopping a Microsoft® Windows® NT Service. The simplicity of assemblies makes XCOPY an appropriate tool to use in certain specific deployment scenarios.

Some applications that lend themselves very easily to XCOPY deployment and replication are XML Web Services and ASP.NET Web applications. Previously, these types of applications were built using Internet Information Services (IIS) and traditional COM components. Installing the components for these applications usually entailed registering the component during the deployment process by using the Regsvr32.exe utility. Updating existing components was far more troublesome, because IIS placed an exclusive file lock on the components. The only way to release the lock was to shut down IIS. Replacement of existing components typically included the following steps:

1. Stop IIS service.
2. Unregister old component using the Regsvr32.exe utility.
3. Copy new component.
4. Register new component using the Regsvr32.exe utility.
5. Start IIS service.

These steps are no longer needed for XML Web Services and ASP.NET Web applications. IIS does not place exclusive file locks on .NET assemblies and, because assemblies are self-describing, they don't have to be registered. This makes ASP.NET Web-based applications ideal for XCOPY deployment and management.

As an example, let's walk through deploying an XML Web Service to a remote computer located on the same Windows NT domain. For the purposes of this example, the client computer where the Web application currently resides is named CLIENT1, and the remote computer, to which the Web application will be deployed, is named SERVER1.

Here is what the directory structure of the Web application to deploy looks like.

Figure 1. Internet Information Service's MMC on CLIENT1 displaying the virtual directory of the DemoWebSrv ASP.NET Web application to deploy to SERVER1

Within the /bin subdirectory, there is an assembly named DemoWebSrv.DLL. The physical location of the directory structure on CLIENT1 is C:\INETPUB\WWWROOT\DEMOWEBSRV. The path, C:\INETPUB\WWWROOT on CLIENT1 is mapped to the network share name of WWWROOT

Let's start the deployment scenario by following these steps:

1. Create a network share on SERVER1 named WWWROOT, and map it to the wwwroot subdirectory located under the InetPub directory. This is the default location of the IIS Default Web Site. This location will be used as the destination argument of the XCOPY command.
2. Copy the folder structure and files of the DemoWebSrv Web site application directory located on CLIENT1 to SERVER1 using XCOPY. At the DOS prompt, type in the following command (the first argument of the XCOPY command is the source directory to copy from; the second argument is the destination directory to copy to):

    

   XCOPY \\CLIENT1\wwwroot\demowebsrv 
   \\SERVER1\wwwroot\demowebsrv /E /K /R /O /H /I

3. Create a virtual directory named DemoWebSrv under the Default Web Site on SERVER1 and mark it as an application. Map it to the newly created C:\INETPUB\WWWROOT\DEMOWEBSRV directory.

Next, you'll find the explanation of the switches used at the end of the XCOPY command. To view a more complete listing, type XCOPY /? at a DOS command prompt.

• / E copies directories, subdirectories, and files of the source argument, including empty ones.
• / K copies all the existing file and folder attributes.
• When you use XCOPY to copy files or a directory tree structure, XCOPY strips off file attributes by default. That is, if a file had the read-only attribute set, once it is copied, that attribute is lost. To keep (apply) the original attributes with the copied files, use the / K parameter.
• / R overwrites files marked as read only.
• / O preserves all security-related permission ACLs of the file and folders.
• / H copies both hidden and system files.
• / I tells XCOPY to assume that the destination is a directory and creates it if it does not already exist. Because the destination argument, , is a directory that doesn't exist, XCOPY creates it.

That's all there is to it. XCOPY successfully deploys the XML Web Service to SERVER1. XCOPY is ideal for simple deployments like these and for on-the-fly updates. XCOPY is also useful for deploying desktop applications on the client.

As with any technology, there are limitations as to how and when you should use XCOPY to deploy .NET-built applications. Typically, XCOPY is only useful in deployment scenarios that are simple and manually executed. Listed below are some cases where XCOPY would not suffice; these would require a more robust deployment method.

• Automated deployment of COM components for .NET applications to interoperate with. Registration is still required.
• Pre-compiling an assembly to native code on the remote computer.
• Installing assemblies into the remote computer's Global Assembly Cache.
• Updating files that are exclusively locked. For instance, a Windows NT Service used to host a .NET Remoting solution.
• Installing .NET-built Windows NT Services.
• Automated configuration and creation of IIS directory settings, NTFS security settings, network shares, and Active Directory User and Group accounts.
• Automated creation of desktop shortcuts, adding to Add/Remove Programs, creation of start menu entries, etc.

Although XCOPY works well for simple solutions, there are obviously many cases where a more robust deployment solution is warranted. Such an option is provided by Visual Studio .NET Installer, which is built on top of the Windows Installer 2.0 technology. Let's look at that next.

Windows Installer

Often, application setup requirements are far more complex then those that can be handled by a simple XCOPY deployment strategy. In many cases, the final deployment solution is targeted towards end users who lack the necessary skills to manually configure an application. In other cases, there may be so many configuration requirements (such as the creation of users and groups, configuration of security, creation of directory structures, and so on) that an automated setup program becomes necessary to ensure accuracy and consistency in the final application's installed behavior. In either case, an XCOPY deployment is usually insufficient to meet such requirements.

For more robust application and deployment needs, Visual Studio .NET can be used to build setup and deployment packages. Visual Studio .NET deployment is built on top of Windows Installer technology. Windows Installer is a software installation and configuration service that ships with the Microsoft® Windows® 2000 and Windows XP operating systems and is freely distributed to all Win9x and NT4 platforms. Windows Installer Service maintains a record of information about every application that it installs. The Windows Installer runtime (MSI) inspects these records during the execution of deployment packages. When an application is uninstalled, the records are checked to make sure that no other applications rely on its components before removing it. Windows Installer 2.0 has been extended to provide the following features to support .NET assemblies:

• Installation, repair, or removal of assemblies in the global assembly cache.
• Installation, repair, or removal of assemblies in user-defined locations.
• Rollback of unsuccessful installations, repairs, or removals of assemblies.
• Install-on-demand of assemblies in the global assembly cache.
• Install-on-demand of assemblies in user-defined locations.

In addition to these features, Visual Studio .NET deployment projects allows all of the conveniences of other setup programs, like reading and writing registry keys, directory creation, registration of components, collecting user-entered data during installation, and so on. Other included features are:

• The ability to set launch conditions, such as checking the current user name, computer name, physical environment, current operating system, existence of .NET CLR, and so on.
• The ability to run a custom program or script after the actual installation is complete. Data collected by the installation can be passed to the program and the entire installation can be rolled back if the program generates an error. The program can be located in a .dll, .exe, script, or in an assembly.

To illustrate a Visual Studio .NET deployment, let's walk through deploying the XML Web Service that was previously deployed using XCOPY.

1. To begin, open an existing XML Web Service project named DemoWebSrv with Visual Studio .NET.
2. On the File menu, click Add Project, and then New Project. This should bring up the New Project dialog box (see Figure 2).

   

   Figure 2. The Visual Studio .NET New Project dialog box displaying the available deployment templates

3. Under Project Types, click the Setup and Deployment Projects folder, and then double-click the Web Setup Project template. The Web Setup Project (WebSetup1) is added to the existing solution and the File System Editor opens.
4. In the File System Editor, click the Web Application folder.
5. On the Action menu, point to Add, and then click Project Output.
6. In the Add Project Output Group box (Figure 3), select DemoWebSrv from the Project list.

   

   Figure 3. The Add Project Output Group dialog box is used to add specific files from one project to another

7. Select the Primary Output and Content Files groups from the list and click OK. This adds the content files and the compiled assemblies and their dependencies to the compiled Windows Installer program (.msi file).
8. In the File System Editor, click the Web Application folder. In the Properties window, set the VirtualDirectory property to DemoWebSrv. Set the DefaultDocument property to Customers.asmx. Windows Installer uses the information to create a virtual directory under the Default Web Site of the target server and set its default document property.
9. On the Build menu, click Build WebSetup1. This will create a WebSetup1.msi Windows Installer setup file.
10. Copy the WebSetup1.msi file to the target Web server computer and double-click the file to run the installer. To access the Web Service that was just deployed, start Internet Explorer and type the URL /DemoWebSrv>.

What's New in Visual Studio .NET?

• The nature of .NET assemblies make XCOPY a feasible deployment option.
• Windows Installer technology has been extended to handle the deployment needs of the .NET Framework.
• Visual Studio .NET deployment tools are built on top of the Windows Installer technology.
• Visual Studio Installer is built into Visual Studio .NET. Installer templates are added as new projects and offer greater configuration options.

Summary

The self-describing nature of .NET-built assemblies makes it feasible to use XCOPY to deploy and update simple applications. XCOPY can easily handle those deployment scenarios that require manual installations with few dependencies and configuration options. XML Web Services and ASP.NET Web Applications lend themselves particularly well to this type of deployment, especially during the development stage of the application.

Visual Studio .NET also provides other deployment tools, based on Windows Installer, that allow more flexible and robust configuration and automation requirements. Using Visual Studio .NET to create Windows Installer programs allows developers to create sophisticated installation programs for the most demanding applications.

Which deployment option to use is ultimately determined by the scope and depth of the application's configuration requirements.

About the Author

Marty Wasznicky is a Senior Systems Engineer with Microsoft Corporation, focusing on Enterprise Application Integration, Business to Business, and E-Commerce. He has more than ten years of experience architecting and implementing solutions in the IT industry, in both corporate and consulting capacities. He is a Microsoft Certified Solutions Developer, Microsoft Certified Systems Engineer, Microsoft Certified Database Administrator, and Certified Novell Engineer. He has authored numerous articles in the Visual Basic Programmer's Journal and the Access/VB/SQL Advisor magazines and is currently working in Microsoft's Southern California District.

About Informant Communications Group

Informant Communications Group, Inc. (www.informant.com) is a diversified media company focused on the information technology sector. Specializing in software development publications, conferences, catalog publishing and Web sites, ICG was founded in 1990. With offices in the United States and the United Kingdom, ICG has served as a respected media and marketing content integrator, satisfying the burgeoning appetite of IT professionals for quality technical information.