Configuring and Deploying Your ASP.NET Solutions

This chapter is from the book

ASP.NET for Developers

Learn More Buy

This chapter is from the book

This chapter is from the book 

ASP.NET for Developers

Learn More Buy

Deploying Your ASP.NET Applications

Deploying ASP.NET solutions is actually quite easy, even if you are using compiled components in your solution. In the past, in order to completely install Web solutions, you needed to have access to the Internet Information Server Manager, COM+ Services, and even have the rights to update the registry. This was made even more difficult if you needed to deploy your solution on one or more remote servers.

Now, with ASP.NET, you can simply create the target folder(s) and copy the files directly to the target. If you have compiled components in your solution, you only need to be sure to place them in the proper subfolder. The rest is handled by ASP.NET. There is no need to attempt to register the components using the old REGSVR32.EXE.

Even better, if you need to update these compiled components on a production server, you no longer need to stop Internet Information Server or bring down the actual machine. All you need to do is copy the new component(s) over the existing one(s) and all will be taken care of for you.

In this section, you learn how to successfully move your Web pages and components to the target server and ASP.NET is able to automatically register and update your solution components. You also learn how to create scripts that handle most all of these tasks remotely.

The New Deployment Model for ASP.NET Solutions

The ASP.NET deployment model is based on simple file copy technology. This means that you don't need any special utilities or packaging tools in order to deploy ASP.NET Webs to the target server. This "minimal deployment" model is made possible by some special services running with the .NET platform. These services are smart enough to handle the process of locating and managing compiled components on the ASP.NET server. These services are so effective that you no longer need to register your components in the Windows registry at all.

The heart of this deployment model is that all DLLs for your Web need to be placed in a special folder, the BIN folder, which is a subfolder off the root folder of your solution. For example, imagine you have a root folder called DEPLOY that contains the documents DEFAULT.ASPX and SPORT.ASMX. You also have a single compiled component, called SAMPLE.DLL that is called by both the DEFAULT.ASPX and SPORT.ASMX documents (see Figure 21.2)

Figure 21.2. Sample Web files and folders.

Notice in Figure 21.2 that the SAMPLE.DLL file is in a subfolder called BIN. Since ASP.NET does not use the Windows Registry, the only way that ASP.NET can locate your custom DLLs is for you to place them in the BIN subfolder of your solution. If you fail to place them in the correct place, you'll receive a runtime error telling you that ASP.NET cannot locate your component.

This is the only requirement that ASP.NET puts on the physical layout of your solution. You can add as many folders and files as you wish to the solution as long as all compiled DLLs are always placed in the same folder.

Now that you know how easy it is to deploy compiled components, you're ready to learn the details of how you can create the folders and copy the files to both local and remote ASP.NET Web servers.

Copying the Application to the Web Server

The first step in deployment is to create the proper folders on your target ASP.NET machine and copy all the proper files from the source machine to the target machine. This can be done using a simple XCOPY command or, for remote server, you can use FTP commands. If you have a GUI file explorer, you can even use simple drag and drop steps to complete the work. The important thing to keep in mind is that you only need to copy the files to the target machine in order to properly build and register the ASP.NET solution.

The files you need to copy depend on the types of components you have in your solution. These include your ASPX (and related) files along with all images and other resource files.

Following is a list of commonly used ASP.NET files that you should deploy to your target server if they exist in your source project:

• .ASPX: Web forms files

• .ASMX: Web services files

• .ASCX: user control files

• .ASHX: ASP.NET handler files

• .CONFIG: configuration files

• .VB or .CS: only if they are used as code-behind files for related .ASPX pages

• DLL: .NET compiled components (in the BIN folder)

Using an XCOPY Script

Probably the simplest way to deploy our ASP.NET solution is to use the command line program XCOPY to copy the files from your source machine to the target machine. This is a viable solution if you have a mapped drive or UNC path to the target server from the source machine.

For example, imagine you have a mapped drive Z: that represents the root of the Web server and you want to copy files from the DEPLOY folder on your machine to the TARGET folder on the Web server. Here is an example XCOPY script that can handle the task:

xcopy c:\deploy\*.* z:\target /V/Q/Y
xcopy c:\deploy\bin\*.* z:\target\bin /V/Q/Y
pause

This script first copies all the files from the DEPLOY folder of the local machine to the TARGET folder on the remote machine. Next, all the files from the DEPLOY\BIN folder are copied to the TARGET\BIN folder. Although you could actually use a single XCOPY command (xcopy c:\deploy\*.* z:\target /s) to copy all files from the source to the destination, the above command skips folders that might contain source code for components, design documents and other non-Web files. The PAUSE statement is included only to allow the user to view the results of the command line execution before dismissing the command prompt dialog box.

Using FTP Services

If the target machine is not reachable via a mapped drive, you can probably use FTP services to copy the files and folders to the target location. This requires that you have a valid FTP account at the target machine, that your account has rights to write new files on the target machine, and that the target machine publish an FTP entry point for you such that you can reach the target folder.

The following listing shows a sample set of FTP commands that can move the contents of the DEPLOY and DEPLOY\BIN folders from the local machine to the remote machine.

open localhost
user aspx4devs smart
prompt off
cd target
mkdir bin
mput d:\sharedspace\aspxbook\code\038x21\deploy\*.*
cd bin
mput d:\sharedspace\aspxbook\code\038x21\deploy\bin\*.*
bye

This example uses the FTP.EXE utility that ships with the Windows operating system. There are also a number of third-party FTP tools that offer rich user interfaces and scripting tools to make this process easier.

Creating the Virtual Directories on the Web Server

As mentioned earlier, all ASP.NET solutions require an entry point on the Web server. This entry point is called the "virtual directory." It is the starting point for your solution. Typically, the DEFAULT.ASPX page and many other documents are placed in this folder.

Also, if your solution has one or more precompiled components, you need to place them in a folder called BIN that is located just below the root folder of the virtual directory. This will make sure that ASP.NET can locate the compiled components at runtime.

The first step is to create the folders on the target machine. Once this is done, you need to mark the starting folder of your solution as virtual directory so that Internet Information Server will be able to route user requests to your ASP.NET application.

Creating the folders is easy. You can use simple DOS commands directly or through a script. Often you can just use your Microsoft File Explorer tool to browse to the target server and add folders as needed. You can also use FTP utilities on remote servers to do the same thing.

The important point to remember is that, once you create the folders and copy the files, you need to mark the base level as a "virtual directory." You can do this a number of different ways. The three ways covered in this chapter are:

• Using File Explorer

• Using Internet Information Server

• Using a WSH Script

Using File Explorer

The simplest way to create a virtual directory on your local machine is to browse to the selected folder using the Microsoft File Explorer and complete the following steps:

1. Locate the desired folder on the machine using Microsoft File Explorer.

2. Right click over the desired folder to view the context menu.

3. Select 'Properties' from the context menu.

4. When the dialog appears, select the 'Web Sharing' tab (see Figure 21.3).

5. Click on the 'Share this folder' radio button.

6. When the 'Edit Alias' dialog appears, verify that the proper name appears and press the OK button until you dismiss all dialogs.

Figure 21.3 shows how steps 4 through 6 would look on a Windows 2000 machine.

Figure 21.3. Using File Explorer to create a Web share on the server.

While this method is very easy, it has its limits. First, you can only do this if you are logged onto the machine locally. For example, you cannot perform this task on a shared network disk. Second, the dialogs only let you do the simplest kind of Web publishing. If you need to adjust Internet Information Server rights, apply certificates, etc. you need to use Internet Information Server Manager instead.

Using Internet Information Server Manager

Probably the most comprehensive way to create a new Web share is to use the Internet Information Server Manager utility. This very powerful utility walks you through the process of creating and managing multiple Webs on multiple servers. Also, if configured properly, the Internet Information Server Manager can be used to manage any number of remote servers.

The details of creating and managing Webs with Internet Information Server Manager are beyond the scope of this book. However, all you need to do is to load the Internet Information Server Manager, expand the desired server in the left-side tree and right-click over the machine, and select "New—Virtual Directory" from the context menu. This will call up the "Virtual Directory Creation Wizard" that will walk you through the process from start to finish (see Figure 21.4).

Figure 21.4. Using Internet Information Server Manager to create a Web share.

The WSH Script

While both the File Explorer and Internet Information Server Manager solutions are valuable, sometimes you need to create a new virtual directory on several servers at a time or you wish to create the directories without having to click through all the dialogs. For that you need a scripted solution. Luckily, Internet Information Server ships with a number of management scripts to handle just such tasks.

Listing 21.4 shows the start of an example WSH script that can create the desired Web on the target machine without using any UI at all. This is especially valuable if you need to deploy your solution to a series of servers in a Web farm.

Listing 21.4. MAKETARGETWEB.VBS—Sample WSH Script to Create a Web Share

Option Explicit
dim vPath, scriptPath,vName

vName="Target" ' name of web to create

' get current path to folder and add web name to it!
scriptPath = left(Wscript.ScriptFullName, _
len(Wscript.ScriptFullName ) -len(Wscript.ScriptName))
vPath = scriptPath & vName

'call to create vDir
CreateVDir(vPath)

'code taken from mkwebdir.vbs and changed for single vDir creation.
Sub CreateVDir(vPath)

  Dim vRoot,vDir,webSite
  On Error Resume Next

  ' get the local host default web
  set webSite = findWeb("localhost", "Default Web Site")
  if IsObject(webSite)=False then
    Display "Unable to locate the Default Web Site"
    exit sub
  else
    'display webSite.name
  end if

  ' get the root
  set vRoot = webSite.GetObject("IIsWebVirtualDir", "Root")
  If (Err <> 0) Then
    Display "Unable to access root for " & webSite.ADsPath
    Exit sub
  else
    'display vRoot.name
  End IF

  ' delete existing web if needed
  vRoot.Delete "IIsWebVirtualDir",vName
  vRoot.SetInfo
  Err=0 ' reset error 

  ' create the new web
  Set vDir = vRoot.Create("IIsWebVirtualDir",vName)
  If (Err <> 0) Then
    Display "Unable to create " & vRoot.ADsPath & "/" & vName & "."
    exit sub
  else
    'display vdir.name
  end if

  ' set properties on the new web 
  vDir.AccessRead = true
  vDir.Path = vPath
  vDir.Accessflags = 529
    VDir.AppCreate False
  If (Err <> 0) Then
    Display "Unable to bind path " & vPath & " to " & _ 
vRoot.Name & "/" & vName & ". Path may be invalid."
    exit sub
  end If

  ' commit changes
  vDir.SetInfo
  If (Err <> 0) Then
    Display "Unable to save changes for " & vRoot.Name & "/" & vName & "."
    exit sub
  end if

  ' report all ok
  WScript.Echo Now & " " & vName & " virtual directory " & vRoot.Name & "/"
   & vname & " created successfully."
End Sub

The script in Listing 21.4 is just the top-most routines of a much longer script. It is not important to understand all the details of this script. Instead, it's important to know that you can create a fully scripted solution for creating virtual directories on target servers.

Handling Component Registration, Versioning, and Replacement

Once you have your ASP.NET Web deployed and running in production, you're bound to discover that you need to update one or more documents or components on the production server. In the past, this meant that you needed to stop the Internet Information Server service on the machine. Sometimes you even needed to re-boot the server itself before you could complete your updates.

However, ASP.NET allows you to update both pages and compiled components without stopping any services on the machine at all. If you have new documents or DLLs to place on the production machine, all you need to do is perform an XCOPY or FTP PUT command to place the new files on the server. Once ASP.NET detects that you have placed new files on the server, the runtime services will flush the old components from memory and load the new components instead. From that point on, all site users will see the new pages and components.

ASP.NET is even smart enough to maintain a copy of the old components as long as there is at least one site visitor running the old components. In other words, when you copy new files over old, ASP.NET will not simply drop any existing users and cancel their sessions. Instead, ASP.NET will maintain existing user's paths through the old components until their current HTTP request is completed. At the same time, ASP.NET will route all new HTTP requests to the updated components. Once all existing HTTP requests are drained from the old components, these old files will be removed from memory and deleted from the machine.

This means you can safely update both pages and compiled DLLs on your production machine with minimum disruptions to your users.