Deploying ASP.NET Applications


ASP.NET Developer's JumpStart
By Paul D. Sheriff, Ken Getz
Table of Contents
Chapter 26.  Development and Deployment Techniques

Once you've created your ASP.NET application, you'll most likely need to deploy it onto a different server than your development server. Somehow, all the pages and DLLs used by your application need to be placed onto the public server where your application will be hosted.

The .NET Framework supplies two different ways to deploy your applications:

  • XCOPY deployment. This Microsoft-generated term doesn't require the XCOPY DOS utility; Windows Explorer will do fine. You don't use XCOPY, really. The name simply implies that you can copy a folder and all its subfolders to a root on the new server, and your application should run. You'll need to create the virtual root(s) yourself.

  • Windows Installer technology. The Microsoft Windows Installer technology allows you to create full executable installation packages. You can create an installation project in Visual Studio that will handle the installation details for you. Using this technique, you can perform a totally "hands-off" installation any user can install your application onto a server, with no manual intervention required.

The following sections compare the two techniques and dig into using the Windows Installer to create an easy-to-install MSI file for your project.

XCOPY Deployment

Because of the self-describing nature of .NET assemblies (all the information about the contents of the assembly is included within the assembly itself), it's really possible to deploy an ASP.NET application to a new virtual root without requiring any tedious installation or registration. In this section, you'll create a new virtual root and test deploying your sample application by simply copying it into the new folder.


One really big issue we haven't discussed is that of replacing existing components while your Web site is running. In the bad old days, if you had created components called by ASP pages, you were required to shut down IIS in order to update the components. With ASP.NET, it's simpler because ASP.NET doesn't lock the files it has in use, you can place the new components into the site right on top of the existing, running components. The next time a request comes in for the page requiring the component, ASP.NET will spin up the new component. When the last current user finishes using the existing component, it's removed from memory.

Although your development server contains all the source files for your site (*.aspx, *.vb, and so on), as well as the compiled version of your source code (the Northwind.dll file in the bin folder), you don't need to deploy (nor should you deploy) the source code (that is, the *.vb files). The files you will need to deploy include, at least, the following:

  • *.aspx

  • global.asax

  • web.config

  • *.dll from the \bin folder

  • images\*

When you build your project, Visual Studio .NET compiles the code into Northwind.dll for you that's the file that contains the event handlers and other procedures you've written.

Imagine that you'd like to copy the site from Jumpstart\Northwind to a new virtual root, NorthwindSales, so that you can browse to the site directly by typing this URL:



Although it isn't required, we recommend that you create new virtual roots outside of the inetpub\wwwroot folder. By placing the site at a different location, you take complete control over the accessibility and availability of your site. In this example, we'll instruct you to create a new folder for the sample project outside this folder.

Follow these steps to test XCOPY deployment of your sample site:

  1. Using Windows Explorer, create a new folder somewhere in your file system. For the sake of discussion here, we'll refer to the folder as C:\NorthwindSales. (You may use this path, if you like.)

  2. Start the Internet Information Services console. (You may find this under the Windows Start, Administrative Tools menu, or you may find it within the Windows Control Panel.)

  3. Drill down into the nodes in the left pane of the console, until you locate the Default Web Site node.

  4. Right-click the Default Web Site node and select New, Virtual Directory from the context menu.

  5. Create a new virtual directory named NorthwindSales, pointing to the folder you created earlier in these steps. Accept all the default options. Once you're done, the IIS console should look something like Figure 26.6.

    Figure 26.6. Create a new virtual root in IIS.


  6. Using Windows Explorer, browse to the folder where you intend to deploy your project (C:\NorthwindSales, if you've followed the suggestion).

  7. Open a separate copy of Windows Explorer and browse to the folder containing your sample Northwind project.

  8. Sort the Explorer window by file type and then select and copy the following groups of files to the new folder:

    • *.aspx

    • *.ascx

    • *.resx

    • *.rpt

    • styles.css

    • global.asax

    • web.config

    • images\*.*

  9. Copy the \bin folder to the new location. (You don't actually need the debugging files, *.pdb, within the bin folder. You can delete those, if you like.)

  10. Open a browser window and browse to http://localhost/NorthwindSales/main.aspx. If you've copied all the files correctly, you should see the sample page, deployed without any special tools to a new location.

That's all there is to XCOPY deployment just copy the necessary files (and perhaps subfolders) to the new location. In this example, you deployed to a new virtual root on your local machine, but you could just as easily have deployed your site to a remote server using the same technique.


If you want to set up the site so that users don't have to specify the start page, you can add main.aspx to the list of default documents within IIS. Right-click the NorthwindSales root, select Properties from the context menu, and select the Documents tab on the NorthwindSales Properties dialog box. Add main.aspx to the list, and you'll be able to browse directly to http://localhost/NorthwindSales.

Although XCOPY deployment is simple, it's not perfect for every scenario. If your folder structure is complex, or if you need several virtual roots as part of your project, it's more trouble than it's worth. In particular, here are several scenarios in which you'll want to consider not using this simple deployment technique:

  • If your application uses COM components. In that case, you'll still need to register them in the Windows Registry.

  • If you want to precompile an assembly to native code on the target machine. By default, the .NET CLR compiles your assembly into native code the first time it runs the code is distributed in Microsoft Intermediate Language (MSIL) format. Precompiling it on the target machine requires extra work not possible in XCOPY deployment.

  • If you want control over the placement of the assemblies. By default, ASP.NET's assemblies are private in the same folder tree as the application. You can also make assemblies global by placing them into the Global Assembly Cache, but that requires running extra utilities. XCOPY deployment simply can't do this.

  • If you want to update files that are locked by the operating system. For example, if your application includes databases or a Windows service, you can't simply copy the files to their new locations.

  • If you need to automatically create IIS virtual roots or set properties of these roots as part of your installation.

If you need to handle any of these situations, you'll need to investigate using the Microsoft Installer technology, which is covered in the next section.

Windows Installer Deployment

If your Web application requires any extra handling or needs to be installed by a user (rather than by an administrator or developer), you'll want to investigate using the Windows Installer technology provided by Windows 2000 and later. You can create a Setup and Deployment project in Visual Studio .NET to walk you through creating the deployment package, in the form of an MSI file. You can give the MSI file to end users, who can simply click and install.

Introducing Microsoft Windows Installer

Microsoft Windows Installer is an installation and configuration service that originally shipped as part of Windows 2000 (later operating systems incorporate the technology, as well). The Microsoft Windows Installer Service keeps track of all the applications that it has installed on a computer, as well as all the components of the applications. When it comes time to uninstall an application, the installer can detect whether no other application is using a shared component, and only then will it delete the component.

In addition to standard installation duties, Microsoft Windows Installer has been extended to support these requirements of .NET assemblies:

  • Installation, repair, and removal of assemblies in the Global Assembly Cache.

  • Installation, repair, and removal of private assemblies.

  • Transacted installs, repairs, and removals. If an entire set of steps fails, all intermediate steps can be rolled back to the original state.

  • Install-on-demand for both public (in the GAC) and private assemblies.

In addition to the features supplied by Microsoft Windows Installer's technology, Visual Studio .NET's Setup and Deployment projects supply standard setup functionality, such described here:

  • Reading and writing Registry keys

  • Directory (and virtual root) creation

  • Registration of components

  • Managing conditional deployments based on operating system, rights of the users, and more

  • Running a custom program after installation is complete

To demonstrate the use of Visual Studio .NET's Setup and Deployment projects, the next section will walk you through packaging the Northwind sample project into a Microsoft Installer (MSI) file.

Selecting Output Content for the MSI File

To illustrate creating an MSI file, this section walks you through adding a Setup and Deployment project to your Northwind solution as well as adding content to the file. Once you're done with the following sections, you can try deploying the sample ASP.NET Web application. Again, in this case, you'll create a virtual root named NorthwindSales.


If you want to really test out the installation capabilities, before you start this exercise, you'll need to delete the C:\NorthwindSales folder and remove the virtual root from within IIS. Everything will continue to operate correctly if you skip this step, but you just won't prove much. You may need to pause Internet Information Server, using the IIS console, in order to delete the folder.


There are seemingly millions of options when creating Setup projects. In this example, you'll take a linear path through one possible set of options, simply building an installation file for your sample project. Digging into the intricacies of creating Setup projects could fill an entire book (and probably does). If you're interested in all the details, start with the online documentation and then research from there.

Follow these steps to creating the MSI file:

  1. Make sure the Northwind.sln sample solution you've been creating throughout this book is open within Visual Studio .NET.

  2. Select the File, Add Project, New Project menu item.

  3. From the Project Types list, select Setup and Deployment Projects.

  4. From the Templates list, select Web Setup Project.

  5. Set the name of the project to NWSetup. Figure 26.7 shows the Add New Project dialog box, with all options selected. Click OK when you're done.

    Figure 26.7. Select these options to add a new Setup project.


  6. At this point, you should see the File System window (see Figure 26.8). You'll add the files you want to deploy to this window in the next few steps.

    Figure 26.8. The File System window allows you to add content to your Setup project.


  7. In the File System window, select the Web Application Folder node in the left pane you'll be adding content to the Web application itself, represented by this node.

  8. Select the Action, Add, Project Output menu item, which displays the Add Project Output Group dialog box, shown in Figure 26.9.

    Figure 26.9. Use this dialog box to select output groups.


  9. Select the project you want to deploy (Northwind, in this case) from the Project drop-down list.

  10. Select both Primary Output (DLL/EXE files) and Content Files (*.aspx, *.ascx, *.xml, and so on) from the list of content groups. Click OK when you're done. Now the File System window should look like Figure 26.10.

    Figure 26.10. After adding the output, you should see the listed content files from your site.



    Just as with other Windows lists, click to select the first item and then Ctrl+click to select additional items.

  11. To add ProductsReport.rpt (which isn't included in either content or primary output), select the Action, Add, File menu item and then select ProductsReport.rpt from the Add Files dialog box. Click Open when you're done.

  12. Verify the list of files to be deployed by right-clicking the Content Files from Northwind (Active) item and selecting Outputs from the context menu. You should see a dialog box like the one shown in Figure 26.11. Repeat this for the primary output files, as well.

    Figure 26.11. You can peruse the list of pending output files.


Configuring the Web Site Information

Once you've selected the content to be deployed by your Setup project, you can set up the name of the virtual root you'll want to use for your application. Follow these steps to input this important information:

  1. Select the Web Application Folder node in the File System window.

  2. Right-click and select Properties Window from the context menu.

  3. In the Properties window, set the DefaultDocument property to main.aspx.

  4. Set the VirtualDirectory property to NorthwindSales. When you're done, the Properties window should look like Figure 26.12.

    Figure 26.12. Set the VirtualDirectory property.


The Windows Installer uses the properties you set to create the virtual directory and set the start page on the target server.


You can use relative paths in the VirtualDirectory property to create a virtual directory under an existing virtual directory. For example, imagine that you've already created a virtual root named CustomApps on your server that points to the physical path D:\CustomApps. You could set the Web Application Folder's VirtualDirectory property to CustomApps\NorthwindSales. Now the NorthwindSales project files would be installed under D:\CustomApps, and the NorthwindSales virtual root would be a child of the existing virtual root CustomApps.

Building and Testing the MSI

Now that you've added all the output and properties settings, you can build and test the MSI file. Follow these steps to finish your Setup project:

  1. Select the Build, Build NWSetup menu item. This may take a few minutes, as Visual Studio .NET rebuilds all the projects in your solution.


    By default, the output MSI file won't contain the .NET Framework. If you need to install your site on a server that doesn't yet include the .NET Framework, you'll need to include it with your installation. When you create your MSI file, the exact warning looks like this:

    This setup does not contain the .NET Framework which must be installed on the target machine by running dotnetfx.exe before this setup will install. You can find dotnetfx.exe on the Visual Studio .NET 'Windows Components Update' media. Dotnetfx.exe can be redistributed with your setup.

  2. Visual Studio .NET creates NWSetup.msi in the JumpStart\Northwind\NWSetup\Debug folder. (It also creates other subsidiary files, which you don't need to distribute.)

  3. To test out the MSI file, double-click to run it from its current location. The installation program walks you through setting up the virtual root, and you should be able to run the application by simply browsing to the site, like this (if you've installed the MSI file on your local computer):



If you run NWSetup.msi again, it will offer to repair or remove the files and settings it installed originally. You can get the same effect using the Control Panel options to add or remove software.


    ASP. NET Developer's JumpStart
    ASP.NET Developers JumpStart
    ISBN: 0672323575
    EAN: 2147483647
    Year: 2002
    Pages: 234 © 2008-2017.
    If you may any questions please contact us: