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.)

Drawbacks

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!