Deploying ASP.NET applications

Microsoft with its .NET Framework brings in some novel, flexible and easy way to deploy the developed Windows and Web applications. Principally Visual Studio presents a simplified mechanism for deploying applications to local or remote servers. In ASP.NET simply Xcopying (Plainly copying files to the target location) is adequate to deploy an application because components register themselves. The self-describing assemblies make it pragmatic to employ XCOPY to deploy simple applications. By means of .NET Framework�s simplified deploying techniques and assemblies there is no more registry entries and maintenance as we do in ASP of registering and maintaining COM and COM+/MTS components.

Assemblies[1] are the building blocks of .NET Framework applications. In CLR, assemblies are the basic unit for deployment and version control. Assembly provides a solution to �DLL Hell�[2] problems; Versioning problems in component based applications and simplify application deployment.

If the application is copied locally, we can simply delete the file to remove an application. It doesn�t break any other application and it leaves a "zero footprint" on the computer. In enterprise or component based applications, we have to be aware that the assembly have to be stored either in a common subdirectory or in assembly cache[3]. Then only it facilitates the various related applications to utilize the same needed assembly. In this article we will discuss about the various deployment techniques such as Windows Installer and XCOPY in ASP.NET. We then discuss which one is preferable based on the circumstances. Finally we explore how the present deployment techniques differ from the Package and Deployment Wizard for Visual Basic Projects. The .NET Framework offers many characteristics that make it easier to deploy the applications. These features are as follows:

� No-touch deployment: .NET Framework gets rid of DLL conflicts. Installing or removing of components does not affect other applications. Thus it provides a solution to �DLL Hell� problem. No-impact applications, which offers application isolation and purge DLL conflicts.

� XCOPY deployment and reproduction: XCOPY deployment is appropriate to be used in certain specific simple deployment scenarios. With Self-described and self-contained components and applications there is no need for registry entries or dependencies. This facilitates to install desktop applications on client machines using a remote web server.

� Integration with the Windows Installer: Advertisement, publishing, repair, and install-on-demand are all on hand when deploying the application. In Visual Studio.NET the deployment tools are built on the groundwork of Windows Installer, which offers rich capabilities for swift deploying and easy maintenance of applications.

� Private components by default: By default the components are deployed to the application directory.

� Side-by-side versioning: We can run one version of the application side-by-side (The CLR can manage multiple versions of a software component to be run concurrently) with another version. We can also decide which versions to employ, and versioning policy is enforced by the common language runtime.

In conventional method we employ script based setup programming tools such as Install Shield for deployment. These tools are difficult to handle and take time to learn it. But in Visual Studio.NET we utilize the Microsoft Windows Installer technology to create installers that provide full control over the installation.

In Visual Studio.NET if you compile a project, the code-behind class file (.aspx.vb, or .aspx.cs) is compiled into a .dll file along with all other class files which are incorporated with the project. If a request is made for that ASP.NET page, then the .dll file is instantiated and executed. You can modify the visual elements of Web form pages without recompiling and redeploying. But you can�t change the code without recompiling. Usually the .dll file is stored in the web application�s bin directory. The following figure shows the general structure for the project named DeploymentProject in the virtual directory ASP.NET. The .dll file is stored in the bin directory.

Figure 1: General Structure and the location (bin) in which *.dll file is stored by VS.NET.

The easiest method to copy a project or application from one location to another is to employing Xcopy[4] MS-DOS command. XCopy deployment is a trouble-free technique to install simple .NET applications. Usually this method is not employed in the Windows due to the convolution and COM/COM+ Component registrations. In the past, for registering the components we have to employ Regsvr32.exe utility etc. Typically for deploying an application we copy the application or component into the virtual directory of the Web server. With self-describing assemblies and versioning to the .NET Framework, there are no more registry entries, which facilitate to make use of XCOPY for deployment.

In ASP.NET, Xcopy deployment refers to copy required files from one location to another location (Virtual directory on the Web server) by employing the drag-and-drop feature in Microsoft Windows Explorer, File Transfer Protocol (FTP), or the DOS Xcopy command. If you type �Xcopy /?� in a command-prompt window you can notice all the options for the Xcopy command as shown in the figure 2.

XCopy only copies the files it doesn�t configure IIS directory settings. Copying does not automatically configure Internet Information Services (IIS) directory settings. Hence we have to configure the IIS properly for the project to be deployed to work properly. But if you employ Visual Studio.NET deployment features which we will discuss soon to deploy your project it facilitates you to take advantage of extensive deployment project management features, such as registration and IIS configuration. Set up the virtual directory as follows:

� In the control panel click Administrative Tools, and then click Internet Services Manager.

� In the left pane, right-click the name of your virtual directory, and then click Properties.

� Verify whether the name of the virtual directory is listed in the Application Name box under Application Settings as shown in the figure 3. If it is not, click Create.

You can easily create virtual directory and configure the IIS by employing the Internet Services manager console and Virtual Directory Creation Wizard as shown in the figure 4 and figure 5 respectively. You will typically not go for Xcopy file transfer deployment in following situations:

� Shared Assemblies to be stored in Global Assembly Cache (GAC): If the project is involved with shared assemblies, then the assemblies have to install in the Global Assembly Cache by employing the Gacutil.exe utility to register those assemblies into the GAC. Similarly during unregisteration you have to re-register the assemblies each time during deployment process.

� COM Interop: If the ASP.NET application employs any Component Object Model (COM) components through COM interop, then you have to register those COM components with COM+ Services.

� Serviced components: In your ASP.NET applications if any classes employ COM+ services (Derived from the System.EnterpriseServices.ServicedComponent class) then you have to utilize the Regsvcs.exe utility to register the classes that use COM+ services.

� Xcopy Deployment is extremely simple, easy, and quick because you make no registry entries and no need for special installation requirements.

� If you have be in charge of client and deploying server, then this method is okay.

� We cannot employ this method for a deployment project which is complex and requires some automation.

� Xcopy does not register or verify the location of assemblies, and for Web projects it does not automatically configure IIS directory settings.

Case Study: Continental Airlines − Deployment in Hours, Not Weeks by using Xcopy Deployment.

Let us discuss a real time case study showing how Xcopy deployment saves time in deployment. Continental Airlines developed a new mobile travel-planning application with the Microsoft .NET Framework and Visual Studio .NET. They deploy their project using Xcopy deployment and it significantly facilitates them to reduce the deployment time. According to Continental Director of Application Development Ferdy Khater, the .NET Framework is helping his team to save close to 90 percent off deployment time by using "XCOPY deployment," which means that developers design, code, and debug on the development platform, and then simply copy their code to a staging server. Khater also mentioned that compared to similar projects in the past, they deploy their project in hours instead of weeks. For more info about the other real time case studies take a look at the following link

[1]. Assemblies can be deployed as either private or shared and can comprise either a single file or multiple files.

[2]. As different applications can share certain DLLs, installing a new application can overwrite a DLL that an existing application depends on; as a result the existing application will be broken inadvertently (DLL Hell).

[3]. Usually Shared assemblies are installed in the Global Assembly Cache (GAC). The GAC is a machine-wide store of assemblies.

[4]. The name Xcopy is acquired from the DOS command Xcopy which is used to copying folders and its subfolders to a different location.