- Configuring Your ASP.NET Solutions
- Deploying Your ASP.NET Applications
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
TIP
If you are using Microsoft Visual Studio.NET to build and deploy your solutions, you may not need to go into the details of creating virtual folders, and copying files to your target server. Instead you can use one of the many built-in deployment features of Visual Studio.NET.
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)
){kind=link}
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.
TIP
If you can reach the target machine via mapped drives, you can probably just use the Windows File Explorer to simply drag the proper files and folders from the source machine to the target machine.
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.
TIP
If you have a valid FTP account that supports uploads for your Webs, you can probably use the Microsoft Internet Explorer to FTP your files to the target. Just load Microsoft Internet Explorer and enter the FTP site you wish to contact. You can then drag and drop your files into place.
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:
Locate the desired folder on the machine using Microsoft File Explorer.
Right click over the desired folder to view the context menu.
Select 'Properties' from the context menu.
-
When the dialog appears, select the 'Web Sharing' tab (see Figure 21.3).
Click on the 'Share this folder' radio button.
When the 'Edit Alias' dialog appears, verify that the proper name appears and press the OK button until you dismiss all dialogs.
){kind=link}
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).
){kind=link}
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.