The ASP Column

Deploying an ASP.NET App Using Visual Studio .NET

George Shepherd

Contents

File | New | Project
Default Directory Structure
Choosing Other Directories
Creating the Project Remotely
ASP.NET Execution Model
Deployment Projects
Manual Deployment
Conclusion

When Visual Studio® .NET was released back in February 2002, it included a number of new features that made it easier to create Web applications. The Microsoft® .NET Framework includes classes for intercepting and processing HTTP requests, and Visual Studio .NET includes facilities for designing interactive UIs over HTTP using HTML. In fact, once you've created a project in Visual Studio .NET, developing a Web application becomes as easy as developing a desktop application. Plus, ASP.NET is probably the easiest way to get a Web Service up and running quickly.

While there's a good deal of information available about most phases of ASP.NET application development, including architecture and programming techniques, there's barely any information out there about deploying your ASP.NET application. This month I'm going to examine what it takes to deploy an ASP.NET application that's been generated using Visual Studio .NET.

File | New | Project

Most software built using Visual Studio originates from the File | New | Project menu. If you've used Visual Basic® or Visual C++® for a long time, you're probably aware of all the files these tools spit out when you create a project. It's never just source code, but a plethora of other files, including workspace files, project files, resource files, make files, and so on.

Like the previous versions of Visual Studio, Visual Studio .NET emits a dizzying array of files. Deploying an application, especially an ASP.NET app developed in Visual Studio .NET, leaves you wondering which parts of the source code must be included in the deployment. For example, the line between program logic code and user interface code is fairly well defined because of the codebehind feature of ASP.NET. However, the delineation is not completely clear in all cases. For instance, you can add server-side script blocks (written in C# or Visual Basic) to an ASPX file. While you don't need the source code that's written in C# or Visual Basic to deploy your application, you still need the ASPX (Web Forms) files, which sometimes contain code. The same is true for ASCX (user controls), ASMX (Web Service implementations), and ASHX (handler) files. In addition, Visual Studio .NET produces such files as RESX files, project files, and solution files. When it comes to deploying an ASP.NET application, deciding what to include and what not to include is the real issue.

Let's look at exactly what Visual Studio .NET produces and where it goes in the directory structure of the development machine.

Default Directory Structure

Visual Studio .NET provides a default directory structure when you create a project. In earlier versions of Visual C++ and Visual Basic, you could usually count on the project files landing in one directory with perhaps a couple of subdirectories (for example, Visual C++ 6.0 included a \res directory within the projects it produced). In the case of ASP.NET, the Visual Studio .NET directory structure is all over the map.

First, because ASP.NET applications are Web-based, they have to work within the constraints of Microsoft Internet Information Services (IIS). That means ASP.NET applications need to have virtual directories. The ASP.NET Web Forms application wizard creates a virtual directory as part of the application generation process. By default, Visual Studio .NET puts most of the application code in a subdirectory underneath wwwroot. For example, if you generate an ASP.NET application named AppDuJour in Visual Studio .NET, this directory structure is created automatically in wwwroot, like so:

INetPub
    wwwroot
        AppDuJour
            AppDuJour.csproj
            \bin
            AppDuJour.
            FormDuJour.aspx
            FormDuJour.aspx.cs
            FormDuJour.aspx.resx
            Global.asax

This physical directory is mapped to a virtual directory named AppDuJour in IIS. Once you build the application, you can run it through Visual Studio .NET, or you can surf to it through the AppDuJour virtual directory.

By default, Visual Studio places the solution file (AppDuJour.SLN) within a directory named AppDuJour in the Documents and Settings directory on your machine. The solution file is like a workspace file and is used for managing the project (or projects). The directory structure looks like this:

Documents and Settings
GeorgeShepherd
    MyDocuments
        Visual Studio Projects
            AppDuJour
                AppDuJour.sln

If you want to change the default directory that the solution file will be placed in, change the default project directory before generating the project. Go to Tools | Options. Then choose Projects and Solutions from the Environment mode.

Finally, Visual Studio .NET adds a subdirectory to the VSWebCache directory on your machine, like so:

Documents and Settings
    GeorgeShepherd
        VSWebCache
            Hostname
                AppDuJour
                    Project files

The Visual Studio .NET Web project cache facilitates offline development (which I'll look at in just a minute). If you've decided to use Visual Studio to develop an application on a remote Web server, your files will be stored here while you develop the application.

Visual Studio creates a bunch of new files and subdirectories on your hard disk. It's important to understand their structure so you know where to find things. On the other hand, you may want to change the locations of these files.

Choosing Other Directories

While wwwroot will work fine as the hosting directory for your Web site, you may not want to develop the application in wwwroot (I know I don't want to). It's fairly easy to send your application source code to another directory.

Imagine you want to have the files of the AppDuJour app generated in an isolated subdirectory (and not have the files land in wwwroot). First, create a physical directory manually (perhaps named AppDuJour). Then map the subdirectory to a virtual directory (perhaps also called AppDuJour). When you create the project using Visual Studio .NET, the wizard asks you to type the path of virtual directory on your machine (the default is https://www.localhost/WebApplication1). To rename the application (unless you really like WebApplication1) and to have the application source files land in the AppDuJour directory, just type https://www.localhost/AppDuJour into the project's Location box.

Creating the Project Remotely

Another option is to create the Web Forms application on a remote server. If you point the project to a path on the Internet (like https://www.FlyByNightHosts.com/AppDuJour), Visual Studio will create the project on the remote host, assuming you have the correct permissions. To do so, you must enable FrontPage® extensions on the server. Then Visual Studio will put the project files in the VSWebCache subdirectory and keep the files synchronized between the server and the development machine. To enable FrontPage extensions, select Options from the Tools menu, then select Web Settings. You can choose between File Sharing or FrontPage extensions. Figure 1 shows the Web Access Mode settings on the project property page.

Figure 1** Web Access Mode Settings **

If the Web server is on your network and under your control, you can open the project using the Universal Naming Convention (UNC) path to the project. File sharing must be enabled on the virtual directory to make this work. Visual Studio creates the solution file locally on your development machine, and the solution file references the server remotely. Visual Studio manages the application files for you, synchronizing the files on your machine and the Web server. You can manage the online status of the application through the Web Project menu option under the Project. You can also synchronize the folders through this menu option.

ASP.NET Execution Model

Understanding the ASP.NET execution model is key to deploying your application effectively and deciding what files to include. Recall that ASP.NET supports codebehind, meaning the presentation code and the logical execution code for your Web site can be kept in separate files. In fact, Visual Studio .NET enforces this separation by default. For example, every ASPX file includes a corresponding source code file written in C# or Visual Basic .NET. Visual Studio .NET ties the ASPX page and the codebehind page together using the Codebehind directive in the ASPX file, like so:

<%@ Page language="c#" Codebehind="MainPage.aspx.cs" 
 Inherits="AppDuJour.MainPage" %>

The files for the ASP.NET application (in this case the ASPX file) reside in the virtual directory for the Web application. When you surf to the site and request the ASPX file for the first time (or if any of the files have changed since the last session), ASP.NET compiles the application files (the source code and the AppDuJour.DLL file created by building the project) into an assembly. ASP.NET then copies that assembly (and any other private components that the app depends on) to a temporary directory and runs the site. If you understand how ASP.NET sets up this staging area for execution, you can determine which files need to be included with your deployment. I'll list the necessary files shortly. You can set up a deployment project or a manual deployment. Let's look at deployment projects first.

Deployment Projects

Web applications require a different deployment model than standard desktop app deployment. Web development often involves quickly evolving software and frequent updates. Managing apps in .NET is much easier than managing COM components.

One of the most important goals behind the .NET component model is to simplify component installation. For example, managing complex Web applications written in classic ASP is difficult because it involves managing COM components. Installing COM components is usually complex and requires you to update the registry while making sure the changes don't affect any other applications on your server. The .NET component model is much simpler because .NET prefers private components to public components, meaning that most ASP.NET applications can be installed by simply copying an application's files using a utility like XCOPY. The upshot is that you just have to gather all of an application's files together. One way to do that is through the Visual Studio Web Setup Project Wizard. This wizard creates an entire setup program that you can carry around to all the servers on your site to install a Web application. Here's how it works.

When you create a Web Setup Project, you usually add it to an existing project. First, select File | Add Project | New Project. Then choose Setup and Deployment Projects. Select the Web Setup Project template. Doing so adds a new setup subproject to your application's solution file.

After creating the Web project, Visual Studio presents you with an Explorer-style interface for choosing which files to include with the Web Project. You get a default Web Application Folder (which will translate to a virtual directory when the application is installed). To add files to the install package, right-click on the Web Application Folder or subdirectory you want to use and choose Add | File. You can also add global assemblies to the setup project by right-clicking and choosing Add | Assembly. Visual Studio shows the Component Selector, which allows you to add components from your Global Assembly Cache. If you add an assembly (say FOO.DLL), Visual Studio will also add all the assemblies that FOO.DLL depends on to the setup project. Figure 2 shows a Web Setup project with some files added.

Figure 2** Web Setup Project with Added Files **

You'll need the following files for your application to run on your Web server: .aspx, .asmx, .ascx, .ashx, .css, and web.config. In addition, you'll need the contents of the \bin directory (most importantly the assembly produced by the build process) and the contents of auxiliary directories (like images). Be sure to include any shared assemblies your application might need. Note that you do not need to include source code written using C# or Visual Basic .NET, project files, or resource files.

After the files are included in the Visual Studio Web Setup Project, highlight that project in the Solution Explorer and build it. A Microsoft Install file (MSI) and a setup file you can run on the target machine will result.

Manual Deployment

You can also manually deploy the project by copying all the necessary files to the Web server. Because the .NET deployment model involves replicating an application's entire directory structure and dropping it at the target, you can easily zip up the application directory (and subdirectories) and unzip it on the target. This should work as well as creating a Web Setup Project, but of course it requires a bit more work.

Conclusion

Visual Studio .NET makes building Web-based applications feel almost like developing for the desktop. Features like server-side controls and Web Forms designers greatly simplify the process of developing an application for distribution over HTTP using HTML. However, as with previous versions of the visual development tools from Microsoft, there are a number of auxiliary files produced for the benefit of the development environment that aren't necessary for deployment. By understanding the ASP.NET compilation model, you can easily decide which files need to be placed on the deployment machine and which files you can ignore for deployment to streamline the process.

Send your questions and comments for George to  asp-net@microsoft.com.

George Shepherdwrites .NET development tools with SyncFusion (https://www.syncfusion.com) and teaches at DevelopMentor. He is the author of a number of programming books, including Programming with Microsoft Visual C++.NET (Microsoft Press, 2002) and Applied .NET (Addison-Wesley, 2001). George may be reached at georges@syncfusion.com or georges@develop.com.