Anyone who has created a Web project using Visual Studio .NET 2002 is aware that VS.NET ties the location of the Web project to a virtual directory on Internet Information Server (IIS). The name of the project folder must be identical to the name of this virtual directory so that the project can be accessed from http://localhost/<projectname>. This strict mapping between the project folder name and virtual directory name has some undesirable consequences, as we shall see, especially when multiple developers are sharing a .NET development server (e.g., by connecting remotely through Terminal Services).

For example, we have established a shared development server running Windows 2000 Server with Sharepoint Portal Server 2001, which allows our developers to independently develop, test, and integrate code into our Web application by connecting remotely through Terminal Services. Our security is integrated with Active Directory. Developers log on to the Windows 2000 Server and develop their code directly on the server. As part of the development life cycle, we needed the ability to have our team members develop, integrate, and maintain individual parts of the application. This means that one developer may need to check out, modify, and test a part of the application that was originally created by another developer.

In such a shared development environment, we needed the ability to separate the various developers' source trees and allow them to test their individual code using http://localhost/<projectname>. However, since every Web project in VS.NET must map to a virtual directory with the same name, it was not possible for us to separate developer source trees without giving up the use of VS.NET. We had to find another way to set up our projects if we wanted to continue to use VS.NET for development and debugging.

We also found another problem with using the Web project approach. Since each Web project in VS.NET is an IIS application with a virtual root, and since virtual roots are not allowed to share application state, this means that VS.NET Web projects cannot share the same session. If we wanted to have projects share session information, we would have to lump all our code into one big VS.NET Web project, which was unacceptable. We wanted the ability to create multiple projects supporting discrete functionalities, and contain them in one VS.NET solution. For example, UI-related code could be placed in a project called ui; database-related code could be placed in a project called db; etc. This facilitates component-based development and deployment. Surprisingly, VS.NET does not directly support multiproject Web applications.

This article presents a solution to these two problems, offering:
1.   The ability to support multiple developers using VS.NET for developing Web applications on the same server
2.   The ability to create multiproject Web applications using VS.NET while sharing the same IIS virtual root, hence sharing the same session state.

Both problems can be solved quite elegantly using the same development approach. Note that wherever we use the term "Web project," we refer to any of the various Web projects that can be developed with VS.NET, like ASP.NET Web Application project, ASP.NET Web Service project, and Empty Web project.

A More Flexible Approach
VS.NET undoubtedly offers a great environment for .NET development. It provides rich features like IntelliSense, and does some of the plumbing for you so you can be more productive. However, you can very well develop your .NET applications without it. You must realize that whether you create your VS.NET project as a Web project or as a Windows application or as a Class Library, the resulting underlying code structure is almost the same, with only minor plumbing differences. So the choice of the project type is mostly superficial.

For example, if you create your VS.NET Web project not as an ASP.NET Web Application, but as a C# Class Library (or a VB Class Library if you are a VB developer), VS.NET does not enforce the virtual directory binding. This gives you great freedom while creating a virtual directory mapping to the VS.NET project folder. You can use this to your advantage while solving the two problems.

First let's create two projects using this approach. Assume two developers, developerA and developerB, will be working on a VS.NET solution containing multiple projects. Only one developer needs to set up the project structure initially. Other developers can simply use the source tree created by the first developer. Let's say developerA sets up the projects initially, as follows:
1.   On the File menu, click New, and then click Project. The New Project dialog box appears as shown in Figure 1.
2.   In the Project Types pane, click Visual C# Projects, and in the Templates pane, select Class Library.
3.   Give a name to the project, e.g., project1, and set the location to c:\developerA\dotnetapp.
4.   Click OK.
5.   Add ".aspx" and other files to the project.
6.   Optionally, add Web.config and Global.asax files to the project. If needed, copy these files from another project and then make the appropriate changes.
7.   Repeat steps 1-6 to create project2 and project3.
8.   Create a blank solution in c:\developerA folder. Name this solution dotnetapp. This should create a file called dotnetapp.sln in c:\developerA\dotnetapp.
9.   Add the three projects (project1, project2, project3) to this solution.

Create a virtual directory on IIS called A_dotnetapp and point it to c:\developerA\dotnetapp, which is the folder for the VS.NET solution. Now developerA can test the code in project<n> using http://localhost/A_dotnetapp/project<n>/. This URL now points to c:\developerA\dotnetapp\project<n> folder.

Once developerA checks in his code (say into a Visual SourceSafe database), developerB can check it out into another folder called c:\developerB\dotnetapp. DeveloperB can then create an IIS virtual directory called B_dotnetapp pointing to c:\developerB\dotnetapp, and test his projects using http://localhost/B_dotnetapp/project<n>/. This URL now points to c:\developerB\dotnetapp\project<n> folder. This way, each developer can maintain his or her own version of the VS.NET solution in a separate folder (in this case bearing the same name as the developer), with an IIS virtual directory mapped to this folder (see Figure 2).

During deployment, create a virtual directory called dotnetapp, and map it to c:\<deploymentfolder>\dotnetapp so that the VS.NET solution is accessible from http://<servername>/dotnetapp/. In this way the solution name and the project names always remain the same for all developers, and it is only the virtual directory names and their mappings that need to be configured.

Figure 3 compares the Web project approach with the Class Library (non-Web) project approach. With the Web project approach, every project folder is a virtual root, whereas with the Class Library approach, only the VS.NET solution folder needs to be made a virtual root. In the latter approach, since the project folders are within the same IIS virtual root, they are able to share session information using the in-process session mode.

Now you can start developing your projects as usual, as long as you're aware of the differences between the two approaches (see Table 1)

Following are some similarities between the two approaches that are probably most relevant for a developer.

ASP.NET Session State, MSDN Library: http://msdn.microsoft.com/library/en-us/ dnaspnet/html/asp12282000.asp

Published May. 28, 2003— Reads 18,128 — Feedback 1
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Stories

▪ SharePoint 2010 Development with Visual Studio 2010 Expert Cookbook

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

About Amit Goel
Amit Goel has been developing object-oriented applications for several years using Java, C++, and recently C#. He holds a master's degree in computer science from Virginia Tech. You can learn more about him at www.amitgoel.com.