.NET Deployment Guide

By Fernando G. Guerrero

On This Page

	Introduction
	Overview of the .NET Framework
	Creating a Deployment Project Plan
	Deployment Projects in Visual Studio .NET
	Deploying the .NET Framework
	Server-side Deployment
	Client-side Deployment
	Deploying Web Services
	Deploying SQL Server Databases Used by .NET-Connected Applications
	Summary

Introduction

This .NET Deployment Guide is designed primarily for IT Managers, Solution Architects, and IT Support Engineers to help them deploy applications and components developed for the .NET Framework. In addition to providing technical details about the deployment procedures, the guide offers architectural guidelines and examples to help Solution and System Architects efficiently support this new platform.

However, this guide does not provide comprehensive information about the .NET Framework and Visual Studio. NET-programming environment. You can access this information from the .NET Framework SDK and Microsoft Visual Studio .NET documentation and from the MSDN Library.

Top of page

Overview of the .NET Framework

The .NET Framework is a new development platform that provides consistent and efficient support to distributed enterprise applications over local area networks (LANs) and the Internet. Key features of this new platform include the following:

• Provides a consistent language-independent, object-oriented development environment to leverage the developer's programming knowledge
• Provides hassle-free software deployment, avoiding versioning problems with related components
• Is a rich execution model, independent of storage location, where components can be stored and executed locally, or stored remotely and executed locally, or stored and executed remotely from an Internet location
• Provides safe code execution, with superior security settings to match the security needs of today's organizations
• Provides a consistent programming environment for both Windows and Web applications
• Improves execution performance of Windows and Web applications by efficient code compilation in both environments
• Is compliant with communication standards to ensure that .NET-connected applications can coexist and integrate with other applications and other platforms

The .NET Framework has two main components:

• The Common Language Runtime (CLR)
• The .NET Framework Class Library

The CLR is the system agent that runs and manages .NET code at runtime. This agent is responsible for basic system services such as memory management, threading, error control, and type safety.

Developers can use any .NET-compatible programming language to write their applications, and their particular compiler converts their code into Intermediate Language (IL) code. The CLR uses efficient Just In Time (JIT) compilation to convert language-independent IL code into machine code of the device on which the code is intended to run.

Managed code always runs in compiled mode and is optimized for the current platform; however, the code is still managed to prevent common execution errors. This new programming model offers tighter control over program execution, which provides a more robust platform on which to run distributed applications.

The .NET Framework Class Library is a comprehensive collection of object-oriented types that you can use to develop any application, service, or component. This class library supersedes the Microsoft Foundation Classes (MFC) commonly used in C++ development, and it is designed to be easily extensible to provide object-oriented programming support to other services, such as Microsoft Windows Server System products that currently provide proprietary-only Application Programming Interfaces (API).

The .NET Framework opens the door to sharing components over the Internet. The technology uses Web Services that can be consumed not only by Windows-based applications but also by applications running on other platforms if the applications use Internet standards such as TCP/IP, HTTP, XML, and SOAP.

Applications developed for the .NET Framework can still use COM components, which leverages the investment already made in previous developments. However, this compatibility comes with a performance cost due to the inherent translation between both standards. Therefore, the migration of COM components to managed code that .NET-connected applications use natively can greatly improve performance.

Architecture Diagram

The diagram that Figure 1 shows is available in the .NET Framework Developer's Guide and is also part of MSDN.

The diagram shows three different scenarios for application development:

• Applications running managed code under the CLR
• Applications running unmanaged machine code
• Web applications and Web Services running managed code under ASP.NET

.NET Framework managed applications can co-exist with unmanaged applications in the same computer. And depending on the programming language selected, you can write both managed and unmanaged code to meet your requirements.

Developers can design many different types of applications with the .NET Framework, such as:

• Windows applications
• Class libraries
• Windows Control libraries
• ASP.NET Web applications
• ASP.NET Web Services
• Web Control libraries
• Console applications
• Windows Services
• Setup projects
• Web setup projects
• Visual Studio .NET add-ins

These application types require different deployment procedures, and this paper addresses the main alternatives.

.NET Assemblies

To simplify the deployment of applications and components, the .NET Framework introduces the concept of assemblies. In the Windows Server System, an assembly is the unit of reuse, versioning, security, and deployment. In other words, an assembly is a group of files, of any type, that must be deployed together. In some cases, an assembly is only a single file, such as a component packaged as a DLL or an executable application. However, an assembly might contain other files, such as HTML pages, XML files, multimedia files, or any other type of file.

Developers can use assemblies to decouple the logical unit of deployment from the physical composition of the package to deploy. These assemblies can be part of a single application and deployed with it, or they can be shared assemblies used by multiple applications.

The assembly metadata information is stored in the manifest, which is included automatically on every assembly. The Visual Studio .NET IDE builds solutions automatically into .EXE or .DLL files, and you can use the ildasm.exe tool (part of the .NET Framework SDK) to see the assembly manifest, as in the following example (applied to a simple HelloWorld VB.NET application).

XCOPY .NET Deployment

The deployment of .NET assemblies is so easy compared with previous versions that we could talk about XCOPY Deployment. XCOPY Deployment means that in many cases, it is possible to deploy .NET-connected applications by simply copying application directories to the destination location.

The following .NET features make this simple deployment procedure possible.

• Every assembly is self-described because the assembly contains the metadata that defines its contents. This feature eliminates the need for endless registry entries defining the public interface of every component.
• Every component involved in any .NET assembly uses standard locations, so it is unnecessary to define them in specific entries in the registry.
• Configuration files can modify the location of specific components, but the assembly finds these configuration files in standard locations, avoiding unnecessary registration processes.

However, there are other scenarios in which the deployment process is more complex, such as:

• The interoperation of .NET-connected applications with COM components still requires registration.
• Pre-compiling an assembly into native code on the remote computer requires more processing than simply copying files to the destination directory.
• Installing assemblies into the remote computer's Global Assembly Cache requires further steps to make this assembly a global shared assembly
• When you install Windows Services developed with the .NET Framework, the service needs to be registered as such in the target system.
• The setup process for .NET-connected applications that require setting up objects in other services, such as Active Directory, Internet Information Server, and Windows Server System integrated server software, needs to run some further applications or scripts to create and configure those objects
• When you customize a user environment, such as Start menu entries, desktop shortcuts, control panel applets, customized folders, and Office add-ins, the settings require a setup application to create all these customization entities.

.NET Deployment with Windows Installer

Windows Installer provides a consistent solution for deploying all types of applications and components. The deployment is completed through Windows Installer files, which have the .msi extension and which contain descriptions for installing applications, including:

• All application files, in compressed mode
• All options available through the installation process, when using either a graphical user interface or automatic unattended mode
• Location of application files
• User environment settings, such as Start-menu entries and desktop shortcuts and icons
• Uninstall information
• Registration requirements, if necessary
• Other configuration settings required to successfully install and register the application

Deploying .NET-connected applications requires Windows Installer version 2.0 or later, which is provided with all editions of Windows 2000, Windows XP, and Windows Server 2003. Detailed instructions about obtaining the updated version of the Windows Installer for other platforms are provided later in this paper.

To create .msi files, you need to use a third-party tool. Independent software vendors, such as Altiris, Inc. (www.wise.com), provide different products you can use to author .msi packages. An alternative to these tools is to use Microsoft Visual Studio .NET, which is addressed later in this paper

MSI Database Utilities

The Windows Installer SDK (included in the Windows Platform SDK) lets you view and edit pre-existing .msi packages with the ORCA.EXE tool. This SDK is available for download from http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en.

This SDK includes the msidb.exe tool, which you can use to export and import database tables and streams, merge .msi databases, and apply transforms to Windows Installer databases. For further information about the ORCA and MSIDB tools, refer to the Windows Installer SDK documentation.

.NET Deployment with Microsoft Application Center

Application Center 2000 provides tools for deploying .NET-connected applications in a load balanced Web farm or a failover cluster of servers. All servers in a cluster are managed as a single server in Application Center 2000. Cluster synchronization guarantees that application images are replicated automatically to all participating servers.

It is possible to upgrade server applications without shutting down any services, which improves availability. Application Center 2000 facilitates the deployment of new applications or new versions from development workstations and the rollback of these changes in case of a failed deployment. It is also possible to use scripting languages to automate the deployment process through Application Center 2000, thanks to its comprehensive API.

Further description of the functionality of Application Center 2000 is beyond the scope of this paper. For additional information about this product, visit http://www.microsoft.com/applicationcenter/.

.NET Deployment with Microsoft System Management Server

Microsoft System Management Server (SMS) can provide additional features to Windows Installer packages, especially with regard to distributing Windows Server 2003 applications to client computers and ASP.NET and Web Services to multiple .NET Web servers.

Using SMS, you can get additional change and configuration benefits, such as:

• Intelligent software distribution to target users and computers based on predefined administrative rules
• Pre-emptive hardware and software requirements checking on target systems
• Advanced software metering to track software usage, which could help in the design of your infrastructure to deal with actual and predicted workload
• Advanced diagnostic and troubleshooting tools to fine-tune your system and network infrastructure

To deploy Windows Installer setup packages using SMS 2.0, you need to perform the following tasks:

Verify Windows Installer runtime availability on all target computers.

• Set up a package source directory using Windows Installer's administrative installation.
• Create a package.
• Configure resilient resources (optional).
• Create a program for the package by using Windows Installer command-line syntax.
• Specify distribution points for the package.
• Specify access accounts for the package (optional).
• Create an advertisement.

However, using Microsoft Application Center to deploy Web Services and ASP.NET applications in a cluster or Web farm is the recommended practice.

Top of page

Creating a Deployment Project Plan

Planning your deployment project is an important step in the logical progression of deploying a .NET-connected application. You need to design your project plan to meet your business infrastructure and requirements. The Microsoft Operations Framework (MOF) provides guidelines for the deployment process. For additional information about MOF, visit the MOF Web site at www.microsoft.com/mof.

Some steps to consider when building a project plan are:

• Creating a project plan outline:
• Defining the project scope and purpose
• Deciding the appropriate timeline for the deployment
• Planning your deployment, as defined in the general MOF guidelines:
• Determining resource/personnel requirements
• Creating project teams
• Gathering information about your current environment
• Establishing standards and guidelines
• Managing risks
• Training
• Testing and piloting overview
• Determining technical considerations and dependencies
• Finalizing a project plan

The process of deploying .NET solutions is often a repetitive task because the deployment of a new .NET solution is not very different from the previous one. However, despite the fact that most solutions will follow a very similar process, following an appropriate deployment plan will ensure a successful deployment with minimum risk to your business.

The deployment management structure should integrate painlessly with your current management structure, but the management structure should be appropriate to manage the following phases:

• Planning the deployment of the .NET solution
• Designing and managing a .NET Test Lab to test the deployment of the .NET solution
• Completing final deployment to the production environment

Developing Your Project Planning Process

Deploying a .NET solution follows a life cycle, from the definition of goals and objectives to the final deployment in the production environment. Planning a deployment project should provide a reasonable guide to follow during the deployment process, detailing how to design, implement, test, modify, and execute every activity.

Determining Goals and Objectives

During this phase in the planning process, you need to decide the main logical configuration of the .NET solution to deploy and give special emphasis to security and availability of features. Network infrastructure plays a crucial role in this phase because this infrastructure is designed to serve the security and functionality required to run your business.

The purpose of this phase is to define the framework of the deployment project to ensure that you obtain the necessary executive approval to progress in the deployment process. This first phase should answer questions related to your specific deployment project, such as:

• Why is your organization deploying this particular .NET solution?
• When does this solution need to be available?
• What is the detailed scope of this project?
• Who will be affected by this project?
• What can be considered a successful deployment?
• Are there any .NET solutions implemented in the system already? If so, is there any potential interaction between them and the solution being deployed in this project?
• Are there any other applications, systems, or software that could be affected by deploying this solution? If so, it is necessary to integrate them with the new solution? How will you achieve this integration?
• What are the risks?
• Who will be involved in the process?

Some of the documents you might create for this milestone include:

• Goals and objectives document
• Outline of current environment
• Risk assessment

This phase is important for creating your deployment roadmap. You need to provide all involved teams with a clear idea as to why this solution is going to be deployed, how it affects the current environment, and how is going to be deployed.

Logical Project Outline: Political Issues

A typical .NET solution involves several different entities:

• Back-end servers
• Application servers
• Web servers
• End user applications
• Users

Figure 3 illustrates a typical network topology for a .NET solution.

Users could be internal or external users, and for either case, it is extremely important to determine how much functionality they should be able to access from this solution. Internal users should be grouped in roles depending on the access level that they have related to this particular solution. For external users, the situation is a bit more complex because you must differentiate among customers, suppliers, and partners— even employees connecting from outside the network. Defining what is and what is not available to every group requires careful planning.

In many cases, end-user applications will be ASP.NET-based applications hosted on a Web server. Therefore, you need to determine what functionality should be available from internal Web servers behind the inner firewall and which functionality should be available to external users from outside the internal firewall.

These ASP.NET and/or Windows applications can use functionality that .NET Web services provides. In this case, it is extremely important to determine which services will be local only (providing service only to intranet users) and which Web services will be available from outside the intranet.

However, the decision process does not stop there. Having a Web Service available does not mean that it needs to be available to any kind of utilization. You need to determine what means "private" and "public" services in this context. Therefore, you can group Web Services into several main groups:

• Private Web Services available only to pre-defined ASP.NET applications running on selected Web servers.
• Private Web Services available only to pre-defined .NET-connected applications. This case is conceptually equivalent to the previous one because you can consider ASP.NET and Windows applications as mere consumers of the same Web Service.
• Private Web Services available to any application designed to run on the intranet.
• Public Web Services available only to pre-defined ASP.NET applications running on selected public Web servers but not available to other applications.
• Public Web Services publicly available to any application able to access the sever hosting the service.

Web Services serving infrastructure and platform components should be placed on the local intranet. They can have full discovery enabled, as access to them is protected already inside the intranet. However, public Web Services placed outside the private LAN should expose limited discoverability. Similar considerations apply to private and public .NET-connected Web applications because you must agree as to which ones will be available only to corporate users and which ones will be available to external users.

In some situations, you might want to use .NET Remoting instead of Web Services for intranet applications. For a comparison of the Remoting and Web Services capabilities, see the Microsoft Web site http://msdn.microsoft.com/library/ms978420.aspx). Web Services could be the ideal choice for communication between applications running in different platforms, although Remoting can be more efficient and reliable between applications based on .NET.

In any case, deciding which authentication method every component will use and how to authorize which resources to use is also extremely important. You can make the decision programmatically, in which case these settings will not be available for changes during the deployment phase. However, during the deployment phase, you can customize these settings by modifying configuration files, as this paper will address

Designing and Managing a .NET Test Lab

To test a deployment plan's feasibility, it is convenient to run a pilot deployment project. The purpose of this is pilot project is to track and resolve any potential issues and fine-tune the deployment process without interfering with the production environment. This phase is vital to achieving the deployment goals and to remaining on schedule and within budget boundaries.

The .NET test lab should be a logical replica of the production environment, including all network layers and systems involved in the rollout. The closer to the production environment, the more efficient the pilot project will be.

After the pilot project is stable, the deployment team can meet to assess the feasibility of the final rollout. The main milestones during this phase are:

• Functional specification completed and stable
• Proof-of-concept completed
• Pre-production test completed
• Pilot completed
• Risk management plan updated

You might want to develop additional deployment documents to assist the operations team that will take over the deployment. Such documents might include:

• Training plan
• Support or Help desk plan
• Operations transfer plan
• Disaster recovery plan

During this phase, the deployment plan will be a dynamic plan subject to continuous changes based on testing performed during the pilot program. You should pay special attention to a disaster recovery plan, which should be fully tested and that should try to predict and resolve all known potential issues.

Obtaining Feedback

To help you decide whether to go beyond the pilot project, you need to obtain feedback from all groups involved in the pilot. You can use different techniques to obtain this feedback, such as:

• Web-site feedback forms
• Sessions with business managers
• Problem reports
• Surveys
• Observations of the IT project and network operations team

Try to obtain as much information as possible about all angles of the deployment of this particular .NET solution, such as:

Production Rollout

The final phase of the deployment project is production rollout. At this point, you have tested all tasks in the test lab as part of the pilot program and defined all risks and contingency plans as well. Due to dissimilarities between the test lab and the actual production environment, you need to continue the testing and adjusting process initiated in the pilot project.

The production Rollout process should be fully documented in the Production rollout plan, which will include detailed information about how the different components have been deployed. Special care should be paid to dependencies between components, if they exist, specifying clearly the order of deployment. The disaster recovery plan, which you should have tested already in the test lab, could be fine-tuned at this point in the process to match the reality of the production environment.

After your deployment is complete and you have prepared your project closeout report for the executive sponsor, you might decide to conduct a project review. Your project review can assess the strengths and weaknesses of your entire project objectively and analyze how you could improve on future infrastructure deployments with the knowledge you have gained from hands-on experience.

Top of page

Deployment Projects in Visual Studio .NET

To deploy .NET applications using Windows Installer, you can use one of the Setup and Deployment Projects in Visual Studio .NET, as Figure 4 shows:

• The Setup Project creates a Windows Installer project for a Windows-based application.
• The Web Setup Project creates a Windows Installer Web project to which files can be added manually during the development process.
• The Merge Module Project packages components that might be shared by multiple applications.
• The Setup Wizard assists developers step by step during the creation of a setup project.
• The Cab Project prepares a cabinet file for downloading to a legacy Web browser.

After you create a project for Web deployment (called Web Setup Project in the VS.NET IDE), you cannot change it to a Windows Installer project (called Setup Project in the VS.NET IDE), or vice versa. To have this dual functionality, you must create two different setup projects. Use the Setup Wizard to create a straightforward setup program; however, all the other project types provide greater flexibility.

A Setup project provides several editors. You can view these editors by selecting the correspondent menu entry from the Setup Project context menu, as Figure 5 shows

The following are the available editors that you can choose from for your particular application:

File System Editor. With this editor, you can customize the user desktop and Start menu and add files and shortcuts to the application folder.

Registry Editor. Use this editor to add keys or values to the registry, which could be used to store default settings.

File Types. Use this editor to add file types and actions to apply to these file types, which are defined by their extension. For example, in the following figure, the file type FGG (with extension .fgg) that will have the action Open is defined.

User Interface. Use this editor to tailor the appearance of the setup application. These settings can hide some screens from the setup wizard or can add more screens from a collection of template styles. In the following figure, you can see that it is possible to define which texts to show or specific parts of the wizard (note that texts in the figure are too long to be shown completely, but you have access to edit them in full).

Custom Actions. Use this editor to specify which programs to execute when a specific action has been selected. This feature can be very useful to install further components or to create specific database objects. These actions can run under specific events, such as:

• Install the application
• Commit
• Rollback the installation
• Uninstall the application

Launch Conditions. Use this editor to specify which conditions to check on the target machine.

Setup Project Configuration

The Setup Project Property Pages gives you access to the configuration settings. To access these pages, select Properties in the Project's context menu, as Figure 12 shows:

Using this configuration page, you can determine the build configuration and the folder in which the resulting files will be created. These files can be created in different ways, as shown in Figure 13.

Using the bootstrapper option that Figure 14 shows, you can select what kind of Widows Installer bootstrapper will be provided (in case this was required in the target machine).

And as is the case for any .NET project, this Setup project could be optimized for size or for speed, as Figure 15 shows.

Setup Files

The process of building the Setup project creates the following files in the Debug or Release folder (depending on the type of build selected), which Table 1 shows:

Table 1 Files created during setup

Top of page

Deploying the .NET Framework

To execute applications or services designed for the .NET Framework in a specific computer, the computer needs to have .NET Framework installed. Because none of the current Microsoft platforms include the .NET Framework, one of the first steps is to make sure that the .NET Framework is available in the target computer.

Computers running any edition of Microsoft Windows Server 2003 have the .NET Framework installed, as it is part of the standard operating system setup process. Computers running Microsoft Windows XP can install the .NET Framework through the Microsoft Windows Update Web site. Using the Microsoft Windows Update Web site is the recommended procedure to update the .NET Framework with the latest service packs and releases.

For computers running other platforms, the .NET Framework redistributable is available as the Dotnetfx.exe application. This redistributable is currently available from the following places and products:

• The Microsoft Download Center.
• The .NET Framework SDK, under the dotNETRedist directory. You can download the .NET Framework SDK from the Microsoft Download Center.
• The Microsoft Visual Studio .NET Windows Component Update CD in the dotNetFramework directory.
• The Microsoft Visual Studio .NET DVD in the \wcu\dotNetFramework directory.

Do not make available the .NET Framework redistributable on your intranet or Web site. Pointing users to the Microsoft Windows Update Web site provides them the most up-to-date version of this component.

This redistributable installs all files required by server and client components. The redistributable package for the .NET Framework supports the following platforms:

• Windows 98
• Windows 98 Second Edition
• Windows Millennium Edition (Windows ME)
• Windows NT 4.0 (Workstation or Server) with Service Pack 6a
• Windows 2000 (Professional, Server, or Advanced Server)
• Windows XP (Home and Professional)
• Windows Server 2003

To run .NET Framework components, you also need:

• Internet Explorer 5.01 or later. You can download the latest Internet Explorer version from:
• The Microsoft Update Web site at http://update.microsoft.com/microsoftupdate/v6/default.aspx
• The Internet Explorer download site at http://www.microsoft.com/windows/ie/downloads/default.mspx
• Windows Installer 2.0 or later. You can download the latest version of Windows Installer from:
• The Microsoft Update Web site at http://update.microsoft.com/microsoftupdate/v6/default.aspx
• The Microsoft Download Center:
  • Windows 95, 98, 98 SE, and ME
  • Windows NT 4.0 and Windows 2000
    Note that Windows XP and Windows Server 2003 already include this new version. However, it is a good idea to check for updates on the Microsoft Windows Update Web site.
• Data access components on the server (recommend MDAC 2.7). You can get the latest version of these components from http://msdn.microsoft.com/data/downloads/.
• Internet Information Services (IIS) installed on Windows 2000, Windows XP (Professional), and Windows Server 2003 (to run ASP.NET applications).

Top of page

Server-side Deployment

ASP.NET applications and Web Services are designed to run as server components, which often run in a central computer somewhere on a local or remote network. To run these applications and services, you must ensure that all prerequisites are met. Servers running the Windows Server 2003 operating systems include all the prerequisites to run .NET-connected applications.

If the application to deploy does not use client-side components, server-side deployment is the only deployment that you need to implement. In this case, the functionality provided by these applications will be used by Internet browsers or Windows applications, and "hosting" applications will not be involved with any process related to the .NET-connected application.

Determining Requirements

To make sure that the .NET-connected server application runs with adequate performance, you should observe the following requirements that Table 2 lists:

Table 2 Server requirements to deploy .NET-connected applications

Top of page

Client-side Deployment

ASP.NET applications and Web Services are designed to run as server components. The client device uses a host application, such as Internet Explorer, to run these .NET-connected applications, or it will run a .NET-connected application to use these services remotely. Servers running the Windows Server 2003 operating systems include all prerequisites to run .NET-connected applications as client devices.

In some cases, .NET-connected applications will require client-side components to deploy, in which case the deployment considerations will be very similar to the deployment of .NET-connected server applications.

Determining Requirements

To make sure that the .NET-connected application runs in the client device with adequate functionality and performance, you should observe the following requirements that Table 3 lists.

Table 3 Client requirements to run .NET

Security Considerations

Authentication and authorization on Web Services follow exactly the same rules as authentication and authorization of ASP.NET applications. Table 4 summarizes the different Authentication methods.

Table 4 Authentication methods

Security configuration files. The security configuration files for .NET-connected applications are installed in the following locations that Table 5 lists.

Table 5 Where to find the configuration files

To avoid security file corruption, you should use one of the following tools:

• .NET Framework Configuration tool (Mscorcfg.msc)
• Code Access Security Policy tool (Caspol.exe)

Configuring .NET-connected Applications

.NET-connected application configuration resides on several files, which we will detail in the following sections. The purpose of this section is to provide information about where to find these files and to explain their purpose and their main sections.

Configuration files are standard XML files. Configuration settings are arranged as a pre-defined set of elements defined using XML tags. You need to be familiar with XML if you want to directly edit the configuration files, and remember that XML tags and attributes are case-sensitive.

Every configuration file uses exactly one <configuration> Element in the format:

<configuration> <!-- configuration settings --> </configuration>

This element might contain several child elements as Table 6 lists. This table shows the different sections you can find in these configuration files and which elements define these sections.

Table 6 Contents of the .NET configurations files

Machine configuration files. The machine.config file is available in the %runtime install path%\Config directory and contains settings that affect the entire machine on which .NET is installed. For this reason, it is more convenient to store applications settings in a different place, as we will discuss later in this paper.

Using Windows Installer to deploy .NET-connected applications can apply required changes to the machine.config file automatically, but using XCOPY deployment does not.

Application configuration files. The CLR searches for application settings first in the application configuration files, and then it goes to the machine configuration files. The name and location of the application configuration file depend on the application's host, which can be one of the following:

• Executable-hosted application. The configuration file for an application hosted by the executable host is in the same directory as the application. The name of the configuration file is the name of the application with a .config extension. For example, an application called myApp.exe can be associated with a configuration file called myApp.exe.config.
  This is an example application configuration file (caspol.exe.config):
  <?xml version ="1.0"?>
<configuration>
<startup>
<requiredRuntime safemode="true" imageVersion="v1.0.3705" version="v1.0.3705" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<publisherPolicy apply="no"/>
</assemblyBinding>
</runtime>
</configuration>
• ASP.NET-hosted application. ASP.NET configuration files are called Web.config. Configuration files in ASP.NET applications inherit the settings of configuration files in the URL path. For example, for the URL www.nwtraders.msft/marketing/year2002, where www.nwtraders.msft/marketing is the Web application, the configuration file associated with the application is located at www.nwtraders.msft/marketing. ASP.NET pages that are in the subdirectory /year2002 use both the settings that are in the configuration file at the application level and the settings in the configuration file that is in /year2002.
• Internet Explorer-hosted application. If an application hosted in Internet Explorer has a configuration file, the location of this file is specified in a <link> tag with the following syntax: <link rel="Configuration" href="location">.
  In this tag, href gives Internet Explorer the URL of the configuration file. The configuration file must be located on the same Web site as the application.

Top of page

Deploying Web Services

All previous comments apply to any kind of .NET-connected application and service. However there are a few special considerations to note regarding Web Services.

Deploying an XML Web Service involves copying the .asmx file and any assemblies used by the XML Web Service, but not part of the Microsoft .NET Framework, to the Web server. For example, if you have an XML Web Service named StockServices to deploy the XML Web Service, you create a virtual directory on your Web server and place the XML Web Service .asmx file in that directory. The virtual directory should also be an IIS Web application, although it is not required. The typical tree structure of such an application could be:

\Inetpub
\Wwwroot
\StockServices
StockServices.asmx
\Bin

Under \Bin, you can add references to all assemblies used by your XML Web Service that are not part of the Microsoft .NET Framework.

Items Deployed with a Web Service

When you publish an XML Web Service, the following items in Table 7 are deployed to a Web server.

Table 7 Items deployed with a Web Service

Top of page

Deploying SQL Server Databases Used by .NET-Connected Applications

Some .NET-connected applications and Web services use a SQL Server database to store application data. The deployment process should be defined to automatically install all required storage elements, and it could use any of the following strategies:

• Use any available SQL Server. If SQL Server is running already on a server available from the .NET-connected application, this application could be configured to store its data on that server. In this case, the setup program should provide an option to specify the following settings (either through user interface or configurations settings):
• Server on which SQL Server is running, including the instance name if required. It should be possible to write directly the name of the server instance to connect to (in ServerName\InstanceName format) or the IP address and port number (in nnn.nnn.nnn.nnn, pppp format). Optionally, the program could provide a search button to search for available SQL Server instances.
• Database name. Depending on the application requirements, this could be an existing database or a new one. If a new database is required, the setup program could attach an existing database file (which is deployed as part of the setup program).
• Authentication method. It should be possible to select SQL Server authentication (supplying username and password) or Windows Integrated authentication.
• Install a new SQL Server instance. This installation could be based on specific input during setup or configuration settings. For specific directions about setting up SQL Server, refer to the SQL Server Deployment Web site at http://www.microsoft.com/technet/prodtechnol/sql/2000/deployment.mspx.
• Install a new SQL Server Desktop Engine. If the only purpose of the database to deploy is to serve the .NET-connected application that is being deployed, it could be convenient to install the SQL Server Desktop Engine. Subject to usage guidelines defined in the license, this SQL Server edition does not require any server- or client-access license. As long as the developer holds a valid license to develop applications using the SQL Server Desktop Engine and the required performance of the .NET-connected application is compatible with the limitations of the Desktop Engine, this could be an excellent solution. For more information about the SQL Server Desktop Engine, visit the following Web site: http://www.microsoft.com/sql/msde/default.mspx.

Attaching a SQL Server Database

If the deployment of a .NET-connected application includes a SQL Server database, the simplest method to achieve such deployment is to use the attach database feature in SQL Server. These are the steps to follow for deploying a SQL Server database that is to be attached to an existing, or newly installed, SQL Server:

• Create the complete SQL Server database during the development phase of the application. This database should contain all objects, users, permissions, and default data to required to start the application. Use any existing SQL Server 2000 instance to create this database.
• Detach the database. Use the sp_detach_db stored procedure to disconnect the database from SQL Server.
• Include the database file in the deployment project. For deployment purpose, only the data file (or files) needs to be deployed. These files usually have an extension of .mdf for the primary file and .ndf for any secondary file, if there is any secondary file. The log files, with extension .ldf, are not necessary for this deployment because the attach database process will create an empty transaction log file.
• Design the setup application to attach the database in the destination system. Follow the guidelines detailed earlier in this document to select which SQL Server instance to attach the database to. Attach the database to the target server using the sp_attach_db stored procedure

Top of page

Summary

The Microsoft .NET Framework provides developers with a powerful and extensible platform to build secure and scaleable solutions. The .NET Framework also extends the capabilities already available in Windows 2000, IIS, and SQL Server, but the deployment of these new solutions is very different from their predecessors. This paper offers detailed instructions about how to prepare .NET-connected applications to be deployed using Windows Installer and XCOPY deployment. However, the most important goal of this paper is to emphasize the importance carefully designing and testing the deployment process to achieve a successful deployment in the final production environment.