Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1525 Chapter 33: Administration and Management Figure 33-36 Figure 33-37 You can apply state management to your applications in a number of ways, and this dialog allows for a number of different settings — some of which are enabled or disabled based on what is selected. The following list describes the items available in the Session State Settings section: ❑ Session state mode: Determines how the sessions are stored by the ASP.NET application. The default option (shown in Figure 33-38) is InProc. Other options include Off, StateServer, and SQLServer. Running sessions in-process (InProc) means that the sessions are stored in the same process as the ASP.NET worker process. Therefore, if IIS is shut down and then brought up again, all the sessions are destroyed and unavailable to end users. StateServer means that ses- sions are stored out-of-process by a Windows service called ASPState. SQLServer is by far the most secure way to deal with your sessions — it stores them directly in SQL Server. StateServer is also the least performance-efficient method. 1525 Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1526 Chapter 33: Administration and Management Figure 33-38 ❑ Cookieless mode: Changes how the identifiers for the end user are stored. The default setting uses cookies (UseCookies). Other possible settings include UseUri, AutoDetect, and UseDevice- Profile. ❑ Session timeout: Sessions are stored for only a short period of time before they expire. For years, the default has been 20 minutes. Modifying the value here changes how long the sessions created by your application are valid. SMTP E-mail If you need to work with an application that delivers e-mail, then you must specify the settings to do this. Sending e-mail and the settings required are defined in the SMTP E-mail section (see Figure 33-39). 1526 Evjen c33.tex V2 - 01/28/2008 4:18pm Page 1527 Chapter 33: Administration and Management Figure 33-39 Summary This chapter showed you some of the new management tools that come with the latest release of ASP.NET. These tools make the ever-increasing size of the web.config file more manageable because they take care of setting the appropriate values in the application’s configuration file. The new IIS Manager console in Windows Vista is a welcome addition for managing applications that are configured to work with IIS. The ASP.NET Web Site Administration Tool provides even more value to administrators and developers by enabling them to easily manage settings. 1527 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1529 Packaging and Deploying ASP.NET Applications Packaging and deploying ASP.NET applications are topics that usually receive little attention. This chapter is going to take a more in-depth look at how you can package and deploy your ASP.NET applications after they are built. After you have developed your ASP.NET application on a devel- opment computer, you will need to deploy the finished product to a quality assurance or staging server, and eventually on a production server. An important reason to consider the proper packaging and deploying of your ASP.NET appli- cations is that many applications are built as saleable products, starter kits, or solutions. In this case you may have to allow complete strangers to download and install these products in their own — environments that you have absolutely no control over. If this is the case, it is ideal to give the consumer a single installer file that ensures proper installation of the application in any environment. But regardless of whether you will distribute your web application outside your company you still need a way to deploy it to another server where it can be tested before production deployment. You should never assume that it will be perfect just because it worked on your computer. Most of the time we just develop using the internal web server in Visual Studio, so we will need a full test using IIS before we assume all is well. Even if you do test with IIS on your computer there are still deployment related factors that need to be ironed out and fully tested before the application goes to production. Before you start, you should understand the basics of packaging and deploying ASP.NET applica- tions. In the process of packaging your ASP.NET applications, you are putting your applications into a package and utilizing a process of deployment that is initiated through a deployment procedure, such as using a Windows installer. Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1530 Chapter 34: Packaging and Deploying ASP.NET Applications Deployment Pieces So what are you actually deploying? ASP.NET contains a lot of pieces that are all possible parts of the overall application and need to be deployed with the application in order for it to run properly. The following list details some of the items that are potentially part of your ASP.NET application and need deployment consideration when you are moving your application: ❑ .aspx pages ❑ The code-behind pages for the .aspx pages ( .aspx.vb or .aspx.cs files) ❑ User controls ( .ascx ) ❑ Web service files ( .asmx and .wsdl files) ❑ .htm or .html files ❑ Image files such as .jpg or .gif ❑ ASP.NET system folders such as App_Code and App_Themes ❑ JavaScript files ( .js ) ❑ Cascading Style Sheets ( .css ) ❑ Configuration files such as the web.config file ❑ .NET components and compiled assemblies ❑ Data files such as .mdb files Steps to Take before Deploying Before deploying your ASP.NET Web applications, you should take some basic steps to ensure that your application is ready for deployment. These steps are often forgotten and are mentioned here to remind you of how you can ensure that your deployed application performs at its best. The first step you should take is to turn off debugging in the web.config file. You do this by setting the debug attribute in the < compilation > element to false , as shown in Listing 34-1. Listing 34-1: Setting debug to false before application deployment < configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" > < system.web > < compilation debug="false" / > < /system.web > < /configuration > By default, most developers set the debug attribute to true when developing their applications. Doing this inserts debug symbols into the compiled ASP.NET pages. These symbols degrade the performance of any application. After the application is built and ready to be deployed, it is unnecessary to keep these debug symbols in place. For those that have been coding ASP.NET for some time now, it is important to note that the Debug option in the drop-down list in the Visual Studio menu does not accomplish much in changing the 1530 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1531 Chapter 34: Packaging and Deploying ASP.NET Applications configuration file or anything similar (shown here in Figure 34-1). In the ASP.NET 1.0 and 1.1 days, Visual Studio .NET (as it was called at that time) actually controlled the compilation of the ASP.NET project to a DLL. Now, and ever since ASP.NET 2.0, it is actually ASP.NET itself that controls the compilation process at runtime. Therefore, while the drop-down with the Debug designation is present, it really has no meaning in the context of building an ASP.NET project. You completely control the compilation designation through what is set in the web.config file, as shown in Listing 34-1. Figure 34-1 Methods of Deploying Web Applications Remember that deployment is the last step in a process. The first is setting up the program — packaging the program into a component that is best suited for the deployment that follows. You can actually deploy a Web application in a number of ways. You can use the XCopy capability that simply wows audiences when demonstrated (because of its simplicity). A second method is to use Visual Studio 2008’s capability to copy a Web site from one location to another using the Copy Web Site feature, as well as an alternative method that uses Visual Studio to deploy a precompiled Web application. The final method uses Visual Studio to build an installer program that can be launched on another machine. After reviewing each of the available methods, you can decide which is best for what you are trying to achieve. Start by looking at the simplest of the three methods: XCopy. Using XCopy Because of the nature of the .NET Framework, it is considerably easier to deploy .NET applications now than it was to deploy applications constructe d using Microsoft’s predecessor technology — COM. Applications in .NET compile down to assemblies, and these assemblies contain code that is executed by the Common Language Runtime (CLR). One great thing about assemblies is that they are self-describing. All the details about the assembly are stored within the assembly itself. In the Windows DNA world, COM stored all its self-describing data within the server’s registry, so installing (as well as uninstalling) COM compone nts meant shutting down IIS. Because a .NET assembly stores this information within itself, XCOPY deployment is possible and no registry settings are needed. Installing an assembly is as simple as copying it to another server and you do not need to stop or start IIS while this is going on. We mention XCOPY here because it is the command-line way of basically doing a copy-and-paste of the files you want to move. XCOPY, however, provides a bit more functionality than just a copy-and-paste, as you w ill see shortly. XCOPY enables you to move files, directories, and even entire drives from one point to another. The default syntax of the XCOPY command is as follows: xcopy [source][destination] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g] 1531 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1532 Chapter 34: Packaging and Deploying ASP.NET Applications [/d[:mm-dd-yyyy]] [/u] [/i] [/s [/e]] [/t] [/k] [/r] [/h] [{/a|/m}] [/n] [/o] [/x] [/exclude:file1[+[file2]][+file3]] [{/y|/-y}] [/z] To see an example of using the XCOPY feature, suppose you are working from your developer machine ( C: \) and want to copy your ASP.NET application to a production server ( Z: \). In its simplest form, the following command would do the job: xcopy c: \ Websites \ Website1 y: \ Websites \ /f /e /k /h This move copies the files and folders from the source drive to the destination drive. Figure 34-2 shows an example of this use on the command line. Figure 34-2 When you copy files using XCOPY, be aware that this method does not allow for the automatic creation of any virtual directories in IIS. When copying a new web application, you also need to create a virtual directory in the destination server and associate this virtual directory with the application you are copying. It is a simple process, but you must take these extra steps to finalize the site copy actions. You can provide a number of parameters to this XCOPY command to get it to b ehave as you want it to. The following table details these parameters. Parameter Description /w Displays the me ssage: Press any key to begin copying file(s) . It waits for your response to start the copying process. /p Asks for a confirmation on each file being copied. This is done in a file-by-file manner. /c Ignores errors that might occur in the copying proce ss. /v Performs a verification on the files being copied to make sure they are identical to the source files. /q Suppresses any display of the XCOPY messages. /f Displays the file names for the source and destination files while the copying process is occurring. 1532 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1533 Chapter 34: Packaging and Deploying ASP.NET Applications Parameter Description /l Displays a list o f the files to be copied to the destination drive. /g Builds decrypted files for the destination drive. /d When used as simply /d , the only files copied are those newer than the existing files located in the destination location. Another alternative is to use /d[:mm-dd-yyyy] , which copies files that have been modified either on or after the specified date. /u Copies only source files that already exist in the destination location. /i If what is being copied is a directory or a file that contains wildcards and the same item does not exist in the destination location, a new directory is created. The XCOPY process also copies all the associated files into this directory. /s Copies all directories and their subdirectories only if they contain files. All empty directories or subdirectories are not copied in the process. /e Copies all subdirectories regardless of whether these directories contain files. /t Copies the subdirectories only and not the files they might contain. /k By default, the XCOPY process removes any read-only settings that might be contained in the source files. Using /k ensures that these read-only settings remain in place during the copying process. /r Copies only the read-only files to the destination location. /h Specifies that the hidden and system files, which are usually excluded by default, are included. /a Copies only files that have their archive file attributes set, and leaves the archive file attributes in place at the XCOPY destination. /m Copies only files that have their archive file attributes set, and t urns off the archive file attributes. /n Copies using the NTFS short file and short directory names. /o Copies the discretionary access control list (DACL) in addition to the files. /x Copies the audit settings and the system access control list (SACL) in addition to the files. /exclude Allows you to exclude specific files. The construction used for this is exclude: File1.aspx + File2.aspx + File3.aspx . /y Suppresses any prompts from the XCOPY process that ask whether to overwrite the destination file. /-y Adds prompts in order to confirm an overwrite of any existing files in the destination location. /z Copies files and directories over a network in restartable mode. /? Displays help for the XCOPY command. 1533 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1534 Chapter 34: Packaging and Deploying ASP.NET Applications Using XCOPY is an easy way to move your applications from one server to another with little work on your part. If you have no problem setting up your own virtual directories, this mode of deployment should work just fine for you. When the Web application is copied (and if placed in a proper virtual directory), it is ready to be called from a browser. Using the VS Copy Web Site Option The next option for copying a Web site is to use a GUI provided by Visual Studio 2008. This Copy Web Site GUI enables you to copy Web sites from your development server to either the same server or a remote server (as you can when you use the XCOPY command). You can pull up this Copy Web Site dialog in Visual Studio in two ways. The first way is to click in the Copy Web Site icon in the Visual Studio Solution Explorer. T his icon is shown in Figure 34-3. Figure 34-3 The other way to open the Copy Web Site GUI is to choose Website ➪ Copy Web Site from t he Visual Studio menu. Using either method pulls up the Copy Web Site GUI in the Document window, as illustrated in Figure 34-4. From this GUI, you can click the Connect To a Remote Server button (next to the Connections text box). This action brings up the Open Web Site dialog shown in Figure 34-5. 1534 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1535 Chapter 34: Packaging and Deploying ASP.NET Applications Figure 34-4 As you can see from this dialog, you have a couple of options to connect to and copy your Web applica- tion. These options include the following: ❑ File System: This option allows you to navigate through a file explorer view of the computer. If you are going to install on a remote server from this view, you must have already mapped a drive to the installation location. ❑ Local IIS: This option enables you to use your local IIS in the installation of your Web applica- tion. From this part of the dialog, you can create new applications as well as new virtual direc- tories directly. You can also delete applications and virtual directories from the same dialog. The Local IIS option does not permit you to work with IIS installations on any remote servers. ❑ FTP Site: This option enables you to connect to a remote server using FTP capabilities. From this dialog, you can specify the server that you want to contact using a URL or IP address, the port you are going to use, and the directory on the server that you will work with. From this dialog, you can also specify the username and password that may be required to access the server via FTP. Note that if you access this server with this dialog via FTP and p rovide a user- name and password, the items are transmitted in plain text. ❑ Remote Site: This option enables you to connect to a remote site using FrontPage Server Exten- sions. From this option in the dialog, you can also choose to connect to the remote server using Secure Sockets Layer (SSL). 1535 . changing the 1 53 0 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1 53 1 Chapter 34 : Packaging and Deploying ASP. NET Applications configuration file or anything similar (shown here in Figure 34 -1). In the ASP. NET. Evjen c 33. tex V2 - 01/28/2008 4:18pm Page 152 5 Chapter 33 : Administration and Management Figure 33 -36 Figure 33 -37 You can apply state management to your applications in a number of ways, and this. files and directories over a network in restartable mode. /? Displays help for the XCOPY command. 1 53 3 Evjen c34.tex V1 - 01/28/2008 4:20pm Page 1 53 4 Chapter 34 : Packaging and Deploying ASP. NET