• Recognize ways the Visual Studio project models affect deployment
• Build a Web setup utility

After completing this tutorial, you will be able to

• Recognize ways the Visual Studio project models affect deployment

• Build a Web setup utility

We've spent the last 19 tutorials figuring out how the various features of ASP.NET work. A major theme within ASP.NET has always been to solve the most common use cases as far as developing Web sites is concerned. We saw ASP.NET's

• rendering model, which breaks down page rendering into small manageable pieces via server-side controls

• support for databinding, easing the task of rendering collections

• new login controls covering the most common login scenarios

• session state that makes tracking users manageable

• support for creating a common look and feel for an application through Master Pages and Skins

After building a feature-rich application that streamlines your company operations or drives customers to your business, you need to be able to manage it effectively, and deploy it. That's the topic of this tutorial¡ªhow the various Visual Studio models affect your deployment strategy. In addition, we'll look at building a Web setup project.

Visual Studio 2005 gives you several options when building a Web site project (as opposed to earlier versions that depended upon IIS). These project models include the HTTP project, the FTP project, and the file project. Here's a summary of how each model works.

HTTP Project

The HTTP project is most like the model built into earlier versions of Visual Studio. Under the HTTP project model, Visual Studio creates a virtual directory under IIS and uses IIS to intercept requests during development time. Under this model, the solution file (the .sln file) resides in a directory specified under Visual Studio's project settings directory. The source code for the project is stored in the IIS virtual directory (that is, \Inetpub\wwwroot).

You may either have Visual Studio create a virtual directory for you, or you may create a virtual directory ahead of time. You may store the code for your Web site in any folder. The virtual directory just needs to point to that location.

Use this option if you want to work as closely as possible in the same mode as earlier versions of Visual Studio. In addition, using an IIS Web site during development lets you test the entire request path (not just the path through ASP.NET). This is important if you want to test an application that leverages IIS security, requires ISAPI filters, application pooling, or some other specific IIS features to run effectively. One reason to create a local Web site is to test your application against a local version of IIS. Using IIS as part of the development environment makes it easier to test these things. Of course, the downside to this approach is that you require IIS to be installed on your machine (it's not installed automatically¡ªyou have to take a deliberate step to install it). Having IIS on your machine may also compromise security.

FTP Project

The FTP project is meant for those projects you want to manage remotely through an FTP server. For example, this is a good option if you use a remote hosting service to host your Web site. The FTP site option represents a reasonable means of getting files from your development environment to the hosting site.

When creating this type of site, Visual Studio will connect to any FTP server for which you have reading and writing privileges. You then use Visual Studio to manage the content on the remote FTP server.

You might use this option to test the Web site on the live-deployed server where it will actually be deployed.

File System Project

The file project is probably the most developer-oriented project. File System projects rely upon the Web server inside Visual Studio instead of IIS. When you specify a file system Web site, you may tell Visual Studio to put it anywhere on your file system or in a shared folder on another computer.

If you don't have access to IIS, or you don't have administration rights to the system on which you're developing, then you'll want to create a file system-based Web site project. The site runs locally, but independently of IIS. The most common scenario in this case is to develop and test a Web site on the file system. Then when it comes time to expose your site, simply create an IIS virtual directory and point it to the pages in the file system Web site.

By default, Visual Studio does not precompile your Web application. Once you've developed a site using Visual Studio, you may decide to precompile it.

Earlier versions of Visual Studio (for example, Visual Studio 2003) automatically built ASP.NET applications when you hit the Build | Build Solution menu item. All the source code (the VB and the CS files) was compiled into a resulting assembly named the same as the project. This precompiled assembly went into the project's \bin directory and became part of the files used for deployment. ASP.NET will still precompile an application for you. However, now you have two choices as far as recompiling goes¡ªusing a virtual path (for applications already defined in IIS) and a physical path (for sites that live on the file system). In addition, you must be deliberate about precompiling. The two precompiling options include (1) precompiling for performance and (2) precompiling for deployment. Precompiling a Web site involves using command line tools.

Precompiling for Performance

The first option is also known as ¡°precompiling in place.¡± This is useful for existing sites for which you want to enhance performance. When you precompile the source code behind your site, the primary benefit is that ASP.NET doesn't have to run that first compilation when the site is hit for the first time. If your site requires frequent updates to the code base, you may see a small amount of performance improvement.

To precompile an IIS-based site in place, open a Visual Studio command window. Navigate to the .NET directory on your machine (probably Windows\Microsoft.Net\Framework\<versionnumber>). In that directory is a program named aspnet_compiler. Execute the aspnet_compiler program, with the name of the Web site as known by IIS following the ¨Cv switch. For example, if IIS has a virtual directory named MySite, the following command line will build it. The precompiled application ends up in the Temporary ASP.NET Files directory under your current .NET directory.

aspnet_compiler -v MySite

If the Web site is a file system Web site without an IIS virtual directory, use the ¨Cp command line parameter to specify the physical path.

This compilation option precompiles the code and places it in the bin directory for the application.

Precompiling for Deployment

Compiling for deployment involves compiling the code for a site and directing the output to a special directory from which it may be copied to the deployment machine or used in an install project (as we'll see momentarily). In this case, the compiler produces assemblies from all ASP.NET source files that are normally compiled at run time. That includes the code for the pages, source code within the App_Code directory, and resource files.

To precompile a site for deployment, open a Visual Studio command window. Navigate to the .NET directory. Run the aspnet_compiler command line program, specifying the source as either a virtual path or physical path. Provide the target folder following the input directory. For example, the following command builds the code in the MySite virtual directory and puts in c:\MySiteTarget.

aspnet_compiler -v MySite c:\MySiteTarget

If you add a ¨Cu command line parameter at the end of the command line, the compiler will compile some of the code and leave the page code files to be compiled just in time.

Once the code is compiled, one of the options you have is to build a Web setup program. The following example illustrates creating a Web setup program.

Creating a Web Site Installer

1. Start by creating a new site. Make it an HTTP site. Name the site DeployThis.

2. Create some content for the site. For example, add a few pages to the site, or borrow content from an earlier example.

3. Precompile the site for deployment. Tell the aspnet_compiler to use the Deploy this virtual directory as the source and to direct it to a target holding directory. The following graphic illustrates the command line. Use the ¨Cu option at the end of the command line to instruct the compiler to make an updateable Web site.

   

4. After the compiler runs, you'll have a target directory full of compiled code. The following graphic illustrates the results of the compilation.

   

5. Add a second project to the solution. Make it a Web Setup Project, as shown in the following graphic. Name the project SetupDeployThis.

   

6. Visual Studio will generate a new setup project for you. You should see a screen like this after Visual Studio is done churning:

   

7. Right-click on the Web Application Folder to add the Web files. Navigate to the target directory containing the site code. This will be the precompile directory.

   

8. Add the Web files from the precompile directory.

   

9. Add the dlls to the bin directory by right-clicking on the bin node to get the File Open dialog box. Then search for assemblies in the target directory's \bin directory.

   

10. After adding all the files, the directory structure should look like this. The bin directory will have the site DLLs:

    

11. The Setup project properties include a prerequisite dialog box that you may review to ensure that certain prerequisites are installed on the end computer. The following graphic illustrates the prerequisites dialog box. Notice that the .NET Framework box is checked.

    

12. Right-click on the SetupDeployThis project and select Build. The resulting MSI file goes in the debug directory of the project.

13. Try running the Microsoft Installer file (the MSI file). The MSI file will guide you through several steps as it installs the Web site, as shown in the following graphics:

    

14. Now examine IIS. Refresh the Default Web Site node and look for the SetupDeployThis virtual directory (unless you named it something else during the install process). IIS will have the SetupDeployThis site:

    

15. After the site is installed, you can surf to it as you can any other site.

    

Setting up Install packages is a good way to distribute a Web application across the set of servers. You can push the MSI file out to the server as necessary and run it. However, using an Install package isn't the only way to distribute the application. You may also literally copy the entire directory from a development machine to the server (XCOPY deployment), or you may use some other file transfer mechanism to move the bits.

In this tutorial, we looked at how the various Visual Studio projects affect the end deployment strategy for your Web site. Visual Studio provides several models, including

• HTTP sites that use IIS on the development machine

• File system sites that exist in the development file system, using the Web server built into Visual Studio

• FTP sites, where the bits are transferred to the target server via FTP

In addition to copying the software directly to the deployment machine, you may also precompile the application before copying it. By precompiling, you save the first end user to hit your site the few seconds it takes to compile the site. Of course, the subsequent hits take a much shorter time. However, if you foresee the site churning a lot, it may be worthwhile to precompile for performance. In addition, you may precompile the application so as to deploy it using an installer or a copying technique.

discuss this topic to forum