Lesson 2: Deploying a Web Application

Lesson 2: Deploying a Web Application

Deploying a Web application means installing the application on the server where it will run. Because they run on servers, Web applications might not require an installation program. Instead, they can simply be uploaded to the Web server using the Visual Studio upload tools.

In this lesson, you ll learn how to deploy a completed Web application to a hosting service or to your own server. You ll also learn about IIS and security settings required by Web applications. This lesson does not cover creating an installation program for a Web application; for information about that task, see Lesson 3.

After this lesson, you will be able to

• Upload a completed Web application to a hosting service

• Create a virtual folder in IIS to host a Web application on your own server

• Copy a Web application to a virtual folder on your own server

• Install COM and .NET components used by your Web application

• Assign security privileges to the ASPNET user account

Estimated lesson time: 15 minutes

Using the Upload Tools

If you signed up with an ASP.NET host service, as described in Chapter 1, Introduction to Web Programming, you can install your Web application on the host s servers directly from Visual Studio .NET.

To install your application on a hosting service from Visual Studio .NET, follow these steps:

1. Open the project you want to install using Visual Studio .NET.

2. On the Online Resources tab on the Visual Studio .NET Start Page, click Web Hosting.

3. On the Web Hosting page, click the Premier Providers or Additional Providers tab.

4. In the section of the providers page that lists your host, click Upload Directly To Your Account. Visual Studio .NET displays your host s upload page, as shown in Figure 9-5.

   

   Figure 9-5. Uploading a Web application

5. Follow the upload instructions on the host s page. These instructions vary slightly among the different host services.

Hosting on Your Own Server

If your application is intended to run as part of a local network or if you have access to your own public Web server, install your application on the server by following these steps:

1. Use IIS to set up a virtual folder for the application.

2. Copy the Web application to the virtual directory.

3. Add any shared .NET components to the server s global assembly cache (GAC).

4. Set the security permissions on the server to allow the application to access required resources.

The following sections describe these steps in more detail.

Setting Up a Virtual Folder

ASP.NET Web applications run under IIS, so both IIS and the Microsoft .NET Framework must be installed on the server before that server can host Web applications. ASP.NET requires the following component versions:

• IIS version 5.0 or later.

• The .NET Framework using the same version number as you used to compile the Web application s assembly.

The Visual Studio .NET distribution disks include tools for setting up the required server components. When you have confirmed that the correct components are installed on the server, create a virtual folder for the application on the server by following these steps:

1. Using Windows Explorer, create a physical folder on the server to store the application.

2. Using IIS, start the Virtual Directory Creation Wizard to create the new virtual folder for the physical location created in step 1. Detailed instructions on using this wizard are covered in Chapter 2, Creating Web Forms Applications.

Copying the Application

Web application boundaries are defined by the application s directory structure. That means that an application starts at its root folder and extends to all of its subordinate folders. This makes installing a Web application as easy as dragging the application s files and subfolders from its development directory to its physical location on the server.

In general, a Web application s content files can be organized into subfolders any way you want. However, you should follow a couple of conventions:

• The application s assembly (.dll) is stored in the /bin subfolder.

• The start page for the application is generally named Default.aspx or Default.htm.

Whether or not your application uses a default start page is determined by settings in IIS. A default page enables IIS to display a page if the user does not specify one in his or her request. For example, a user might make a request using only your domain name, such as http://www.contoso.com. If a default page is enabled, IIS will respond with http://www.contoso.com/default.aspx.

NOTE
Don t confuse IIS default pages with the Web Forms application start page in Visual Studio .NET. Visual Studio .NET requires that you set a start page for each project so that the development environment knows which page to display first during debugging. This setting has no effect on the IIS default page settings.

Installing Shared Components

If your application uses components that are shared with other applications on the server, such as custom server controls, those components must be installed on the server. There are three ways to do this, depending on the type of component:

• For COM components

  Copy the component to the server and register the component using the COM registration tools.

• For weak-named .NET components

  Copy the component to the application s /bin directory.

• For strong-named .NET components

  Install the component in the server s GAC.

COM components generally provide a setup program to install or remove them from the system. If the component doesn t provide a setup program, you can copy it to the server and register it using the MFC RegSvr32.exe utility, as shown here:

RegSvr32 MyComp.dll

.NET component names come in two flavors: weak and strong. This distinction refers to how the names are stored within the assembly. Weak names are not guaranteed to be unique and thus cannot be shared without potentially causing conflicts. Strong names are digitally signed and provide a public key that ensures there are no conflicts. Furthermore, .NET components with strong names can t call unmanaged code (such as COM components) and thus avoid potential conflicts with dependencies.

Weak-named .NET components must be individually copied to the /bin directories of the Web applications where they are used. Strong-named .NET components can be copied into the server s GAC, as shown in Figure 9-6.

Figure 9-6. Viewing .NET components in the global assembly cache

The global assembly cache (GAC) is a special subfolder within the Windows folder that stores the shared .NET components. When you open the folder, Windows Explorer starts a Windows shell extension called the Assembly Cache Viewer (ShFusion.dll), as shown in Figure 9-6.

You can install strong-named .NET components by dragging them into the Assembly Cache Viewer, or by using the Global Assembly Cache tool (GacUtil.exe), as shown here:

GacUtil i MyServeControls.dll

Assigning Security Privileges

By default, the ASP.NET worker process runs using the ASPNET account, which is created when you install the .NET Framework. This account has limited privileges, which can cause permission-denied errors if your application writes files or tries to read files outside the current Web application s boundaries.

If your application requires additional permissions, you have three options:

• Grant the ASPNET user access to the required files. To use this option, the server must be using the Windows NT file system (NTFS).

• Change the group the ASPNET user belongs to.

• Use impersonation to run the process as another user.

To grant the ASPNET user access to a file or folder, follow these steps:

1. In Windows Explorer, choose Folder Options from the Tools menu. Windows Explorer displays the Folder Options dialog box.

2. In the Folder Options dialog box, click the View tab, and clear the Use Simple File Sharing check box at the bottom of the Advanced Settings list, as shown in Figure 9-7. Click OK to make the change and close the dialog box.

   

   Figure 9-7. Enabling full file permissions

3. In Windows Explorer, right-click the file or folder you want to grant access to, and select Properties on the shortcut menu. Windows Explorer displays the Properties dialog box.

4. Click the Security tab, and then click Add to add the ASPNET user to the Group Or User Names list, as shown in Figure 9-8.

   

   Figure 9-8. Adding the ASPNET user account

5. Select the check boxes in the permissions list to grant the required access. Click OK to make the changes and close the dialog box.

To change the group the ASPNET user account belongs to, follow these steps:

1. From the Start menu, point to All Programs, Administrative Tools, and then choose Computer Management. Windows displays the Computer Management console.

2. Expand Local Users And Groups in the console tree, and then select Users, as shown in Figure 9-9.

   

   Figure 9-9. Modifying the ASPNET user account

3. Right-click the ASPNET user account, and select Properties on the shortcut menu. The Computer Management console displays the Properties dialog box for the ASPNET account, as shown in Figure 9-10.

   

   Figure 9-10. Adding a group to ASPNET

4. Click the Member Of tab, and then click Add to open the Select Groups dialog box to add the ASPNET user to a new group. Click OK to make the changes and close the dialog boxes.

Adding the ASPNET user to the Administrators group gives your Web application full privileges on the server; however, it also poses a potential security risk because outside users might be able to manipulate your application to hack your server.

To use impersonation to run the ASP.NET process as a user other than ASPNET, set the identity element s impersonation attribute in the application s Web.config file. For example, the following entry sets the application to run as the WebFlyr user account:

<identity impersonate="true" name="localhost\WebFlyr" password="hpB14dQi" />

If your application uses Windows authentication, you can also use impersonation to pass the identity of authenticated users through to the server. For example, the following Web.config fragment tells the application to use the permissions of the user who signed on to the application:

<identity impersonate="true" /> <!-- Use impersonation. --> <authorization> <deny users="?"  /> <!-- Require authentication. --> </authorization>

For more information about authenticating users, see Chapter 8, Maintaining Security.