Team Development with Visual Studio .NET and Visual SourceSafe

ASP.NET Web Application Development Models

Microsoft Corporation

January 2002

Summary: This chapter describes the approach you should adopt to build Web applications within a team development environment.

This is Chapter 2 of the Team Development with Visual Studio® .NET and Visual SourceSafe™ guide. Start here to get the full picture.

This chapter describes how you should approach Web application development in a team environment. It recommends an isolated model for Web development but contrasts this with alternate approaches.

There are three main models for developing Web applications:

• Isolated (recommended)
• Semi-Isolated
• Non-Isolated

Isolated

With this model you develop (edit, debug and run) in complete isolation on your own development workstation using your local Web server (https://localhost). Access to the master source files is controlled via a Microsoft® Visual SourceSafe™ (VSS) database located on a network file share. You may or may not choose to allow developers to check out the same file simultaneously. For more information, see Multiple Checkout in Chapter 6, "Working with Visual SourceSafe."

Semi-Isolated

With this model, you use a common Web server (http://remoteserver) for application development and debugging. You check files in and out via a VSS database located on a network file share. Your working copy of the project is located on the common Web server in a specified project folder, which is also a Microsoft Internet Information Server (IIS) virtual root. Each developer has a unique project folder on the common Web server.

Note   When you obtain a Web project from VSS for the first time, Microsoft Visual Studio® .NET does not allow you to place working files in a folder that already contains another Web project.

Developers can check out and edit the same file simultaneously if the VSS multiple checkout feature is enabled, but only one developer can debug the application on the Web server at any one time. This is because when you debug an application, IIS is blocked. This prevents other Web requests for any other application being serviced.

Non-Isolated

With this model, you again use a common Web server (http://remoteserver) for application development and debugging. However, you do not have your own working copy of files and all developers use a single folder and virtual root on the server; for example, http://remoteserver/projectname.

When you save changes to a file, the in-memory version of the file on your workstation is transferred to the server using Hypertext Transfer Protocol (HTTP). This overwrites the existing copy on the server. When you subsequently check in your changes by using the Visual Studio .NET integrated source control services, Microsoft FrontPage® Extensions are used to update the master copy of the file within a VSS database.

The three models are illustrated in Figure 2.1:

Figure 2.1. Web Development Models

Use an Isolated Development Model

You are strongly advised to adopt the isolated development model for team developments because it offers a number of significant advantages.

Advantages of Isolated Development

Adopting an isolated development model provides the following advantages:

• You and your fellow team members develop independently of one another using separate (local) instances of the Web application.
• You can both develop and debug the application without inadvertently interfering with one another.
• It provides superior support for source-code control (compared to the non-isolated model that uses FrontPage Extensions).
• It is slightly faster in a local area network (LAN) environment (compared to FrontPage Extensions).

Avoid Semi-Isolated and Non-Isolated Development Models

It is difficult to use semi-isolated and non-isolated models in a team development environment. These should be avoided whenever possible.

Disadvantages of Semi-Isolated and Non-Isolated Models

Semi-isolated and non-isolated models suffer from the following disadvantages:

• It is very easy to inadvertently affect another developer. For example, when you debug an application, the debug process locks the common Web server and impacts other team members.
• In a non-isolated model, developers can also impact each other as there is only a single code behind dynamic-link library (DLL) per Web application.
• FrontPage Extensions (with no VSS integration) offer only limited source control capabilities. With the non-isolated development model, all developers work with a master copy located on the Web server. The source control functionality of FrontPage Extensions offers a "last check-in wins" development model. If users A and B both check out the same file in close succession, user A makes changes and then saves them, and then user B saves changes, user A's changes are lost.

The one occasion where you might be forced to adopt a semi-isolated or non-isolated model is when specific resources required by your Web application are available only on the common Web server. You may encounter this situation if you develop with Microsoft .NET Passport.

If you are forced to use FrontPage Extensions, you can configure Visual Studio .NET to use this mode of operation for all new Web projects and you can change the mode of an existing Web project.

To configure Visual Studio .NET to use FrontPage Extensions

1. On the Tools menu, click Options.
2. Click the Projects folder.
3. In the Projects folder, click WebSettings.
4. In the right pane, select the FrontPage Extensions option.
5. Click OK to accept the changes.

To change the access mode of an existing Web project

1. Right-click the project within Solution Explorer, and then click Properties.
2. Expand the Common Properties folder, and then click Web Settings.
3. Change the Web Access Mode setting.
4. Click OK to accept the changes.

For more information about developing source-controlled Web projects in Visual Studio .NET, see Web Projects and Source Control Integration in Visual Studio .NET.

This is Chapter 2 of the Team Development with Visual Studio .NET and Visual SourceSafe guide. To read the next chapter, please see Chapter 3, "Structuring Solutions and Projects."

© Microsoft Corporation. All rights reserved.