Professional ASP.NET 3.5 in C# and Visual Basic Part 157 pdf

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 ❑

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

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)

Chapter 33: Administration and Management

Figure 33-39

Summar y

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 theweb.configfile 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

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 appliappli-cations 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

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.aspxpages (.aspx.vbor.aspx.csfiles)

❑ User controls (.ascx)

❑ Web service files (.asmxand.wsdlfiles)

❑ htm or html files

❑ Image files such as jpg or gif

❑ ASP.NET system folders such asApp_CodeandApp_Themes

❑ JavaScript files (.js)

❑ Cascading Style Sheets (.css)

❑ Configuration files such as theweb.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 theweb.configfile You do this by setting the

debugattribute in the<compilation>element tofalse, 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 thedebugattribute totruewhen 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

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 theweb.configfile, 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 constructed 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 components 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 will 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]

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 behave as you want it to

The following table details these parameters

/w Displays the message: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 process

/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

Chapter 34: Packaging and Deploying ASP.NET Applications

/l Displays a list of 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/kensures 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 turns 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 isexclude:

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

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 This 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 the 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

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 direcdirec-tories 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 provide 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)