The location of a Web application during development changes depending upon the state of the project. It begins its life on the developer's workstation and often lives on a test server and ends up in production (if everything goes according to plan). The move from one server to another can be time consuming, but Microsoft makes it easy with ASP.NET applications. You can utilize a Web setup project or copy a project option in Visual Studio .NET (VS.NET) or copy the files directly.
A different kind of project
A Web setup project acts like any other project within the VS.NET environment. You may create a Web setup project by selecting Add New Project. You'll find the Web Setup Project type within the Setup And Deployment Projects option. You may assign it a name; then, when you click OK, it will add the Web setup project to the VS.NET solution.
I like to include the setup project within the solution file containing the project to be rolled out, but you can easily create it in its own solution file. Once you create the new project, you begin the process of establishing setup options. By default, the project includes a Web application folder that corresponds to the Internet Information Services (IIS) virtual directory created during setup. The folder properties are used to assign a name to the virtual directory.
In addition, you may add additional Web folders under the virtual directory, as well as individual files, assemblies, and project output. The project output option allows you to include the files associated with the Web application that is rolled out. You may include content, documentation, and source files, as well as localized resources and primary output (.dll or .exe files). This makes sure the setup project is in sync with the associated Web application.
The setup project goes even further by allowing you to customize the installation interface and add additional system resources. This includes registry entries, COM components, and global assembly cache (GAC) entries. Also, you can execute command-line tools during setup as well as perform system checks (IIS version and .NET Framework version). These are available via the View | Editor file menu or by right-clicking the project and selecting View. Lastly, you can include special folders like the user's startup, desktop, favorites, and custom folders. This allows you to place files wherever necessary on the target system. I like adding a link to the new application within the target Favorites folder.
Once you have set up the project to suit your needs, you must compile it. The results of compilation are .exe, .ini (configuration), and .msi (Microsoft Installer Package) files that you may use to install the application on another system. The automation is great, but I find that some manual intervention is usually required. The most common requirement is editing the web.config file where applications require specific settings.
Other ways to roll out
While the Web setup project is a great feature of VS.NET, it's not an essential piece of Web application roll-out. Many developers prefer the nostalgic days of command-line DOS. The DOS xcopy command allows you to copy all files in a directory (and all subdirectories) from one location to another. The xcopy command is a recursive copy, so nothing is left out. You will, however, still need to set up the site on IIS. The registration of any COM components will be manual as well. Also, you may need to install assemblies in the GAC. The xcopy command receives a lot of attention because it demonstrates the simplicity offered by ASP.NET—where deployment is as simple as copying files.
Lastly, the VS.NET environment provides the Copy Project option within an ASP.NET Web application. The Project drop-down menu provides access to the Copy Project action. Once you select it, you must specify the destination folder (URL) for the project. Also, you may use FrontPage extensions or a File Share when copying the project. Finally, it allows you to specify all project files that should be copied (only copy files necessary for application execution or all files in the source folder). This is an excellent solution for developers moving an application to a test server, however, production roll out usually doesn't include the developer. (Administrators are picky about who they let access a server.)
The roll-out approach may depend on the situation, but each has its drawbacks. The Copy Project option requires access to the destination folder, and many administrators categorize this as a security risk. The xcopy approach requires more legwork with every step. Web setup projects are great, but it doesn't allow you to install the Web application outside of the default IIS folder (inetpub\wwwroot). Microsoft recommends installing a site outside of this directory on a different drive (and pointing a virtual directory to it) for security reasons, but the option isn't available in Microsoft's installer. IIS may be configured to use another directory, but this is in the hands of the system administrator and may not be configured from a Web project.
Base your choice on the situation
If you're a developer in a small company with complete access to all servers, then you can use either method described. Unfortunately, not everyone is so lucky.
For example, I just finished working on a Web application for a large company, and moving the application to production involved working with their data center. The data center houses all servers with administrative personnel available around-the-clock. The data center required complete documentation of the Web application installation, as well as install procedures. In this scenario, the Web setup project provided a simple solution and greatly simplified my documentation work.
TechRepublic's free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.