Export (0) Print
Expand All
18 out of 22 rated this helpful - Rate this topic

Web Projects and Source Control Integration in Visual Studio .NET

Visual Studio .NET 2003
 

Korby Parnell and Martyn Lovell
Visual Studio Team
Microsoft Corporation

February 2002
Revised May 2002

Summary: This article proposes strategies for developing source-controlled Web projects in Visual Studio .NET. (30 printed pages)

Contents

Understanding Solutions and Projects
Establishing a Source Control Strategy
Collaborative Development Models
Choosing a Collaborative Development Model: Web Project Creation
Source Control Integration, Behind the Scenes
General Tips, Notes, and Guidelines
Frequently Asked Questions
FAQ for Visual InterDev Developers
Appendix A: Setting Up Dynamic URL Web References
Appendix B: Changing Web Access Methods
Appendix C: Deploying Web Projects
Additional Information

Introduction

No one person can master all the languages, techniques, tools, and processes required to create world-class software applications rapidly and consistently. That's why most professional developers work in teams. Efficiency and economy demand it. In the same way, most software development teams adopt a parallel development methodology that liberates individuals from the constraints of serial development, where one developer completes one task before the next can begin another. Parallel development allows multiple individuals to work in isolation, safely developing the same, or different parts and versions of a project at the same time. To realize the benefits of parallel development, teams must implement processes so that project contributors can expeditiously, incrementally, and sometimes automatically resolve small conflicts before they grow into big ones. Visual Studio .NET can improve a team's ability to cooperate by ensuring adequate developmental isolation.

When isolated, two or more developers can make conflicting changes and be assured that at least one team member will have an opportunity to review and select the preferred version at each individual point of conflict. In a departure from previously released Microsoft development tools, Visual Studio .NET now supports true isolation for both Web and non-Web projects.

This article proposes strategies for smoothly developing ASP.NET Web projects in teams. It describes Web project file management so that you can more easily understand how to set up, develop, and deploy source-controlled Web applications in teams. A solid collaborative development strategy consists of the following elements:

  • Source control
  • Procedural uniformity
  • Isolation

One of the easiest things you can do to ensure successful collaboration is to place solutions, projects, and other shared resources under source control. Source control protects team resources from accidental deletion, protects individual changes from being blindly or unknowingly overwritten, and maintains a version-by-version history of all project files. Visual Studio .NET reduces the complexity of source control by making it an extension of project file management. You can perform all source control operations without ever leaving the Integrated Development Environment (IDE) or opening another application.

Understanding Solutions and Projects

Visual Studio alleviates many of the more mundane or complex aspects of project file management and source control operations. For example, when you add a new item to a project, Visual Studio saves it somewhere in storage. You don't have to determine where the file is saved as long as it opens and is compiled with your project as requested. When developing Web applications, however, understanding how Visual Studio .NET manages your project files behind the scenes can save you and your team a great deal of time and money.

Solution

Whenever you create or open an existing Web project from storage, a solution is automatically created to contain it. All Visual Studio .NET solutions contain a solution file, solutionname.sln, which stores solution metadata, such as a list of projects and their locations in storage. Solutions include a second solution file, solutionname.suo that tracks user-specific information, such as the default save location for your Visual Studio projects. When you add a solution to source control, only the *.sln file is added. The *.suo file is not and should never be checked in.

From a source control perspective, there are two important points to remember about solutions.

  • Solutions are local. Solution and Web project files are stored in different locations. Unlike Web project items, solution files are never stored on a Web server, unless you put them there on purpose, which is not recommended. Web project files (.vbproj and .csproj) reside on a Web server, but solution files (.sln and .suo) and any items in the Solution Items folders are stored in a file system folder by default. This fact is important because it affects the organization and manageability of your Web projects under source control. For more information about what happens when you add a Web project's solution to source control, see What Happens When I Add a Web Project Solution to Source Control?.
  • Create solutions, not projects. By creating a solution first and then adding projects, you maintain the logical, parent-child relationship between a solution and its projects in storage. Doing so ensures the discoverability of secondary projects in a multiproject solution and helps you avoid some confusing issues that can occur with some of the more complicated source control operations, such as branching and merging.

Project

In the way it manages files, Visual Studio .NET has only two types of projects - Web and non-Web, or local.

Web project
Any project created at an HTTP location in the New Project dialog box. These projects are primarily used to provide content to Web browsers (projects known as Web Applications), but are also used when developers want to share data between servers (Web Services).
Local project
Any project created at a non-HTTP location (for example, C:/MyProjects or \\MyComputer\MyProjects). The most common local projects are used to create Windows applications.

Like the solution file *.sln, all projects contain a project file that identifies the physical location of its items in your computer's file system. For example, when you add a text file to a Visual Basic ASP.NET project, its relative path is inserted into the project file (*.vbproj).

Web Projects

An ASP.NET Web project is a rapid application development (RAD) template for Web-based, thin client applications. In an ASP.NET Web application, a Web forms page presents information to the user in a browser and implements application logic using server code. Web applications are built around ASP.NET, a platform that includes design-time objects and controls and a run-time execution context for developing and running applications on a Web server.

When managing Web projects under source control, you should:

  • Perform all available source control operations using Visual Studio .NET.
  • Do not manually force a file to be under source control. All files that should be source-controlled are placed there automatically when you use the Add to Source Control or Check In commands.

Access Methods

Visual Studio accesses and manages files on a Web server using one of two methods - File Share, which is new to Visual Studio .NET, or FrontPage, which was used in Visual InterDev. The new File Share access method is used by default.

File Share
Visual Studio accesses Web project files using Windows-based file management commands. File Share is the default Web access method and provides superior support for source control. For more information about the File Share access method and its implications for team development, see File Share.
FrontPage
All files are managed using the HTTP protocol. Source control requests from Visual Studio are forwarded through the FrontPage server extensions to the server installation of your source control provider (for example, Visual SourceSafe). The FrontPage access method does not support as many source control commands as File Share. For more information about the FrontPage access method, see FrontPage Server Extensions.

Project Files

Unlike local projects, a Web project cannot include items outside its project directory. When you add an existing file to a Web project, Visual Studio includes it in the project by copying it to the virtual application root, a directory on the Web server where all project items and build outputs are stored.

Configuration Files

The Web.config file is a special application configuration file whose settings can be defined when you design your application. After deployment, these settings can be changed without shutting down the Web server. Multiple configuration files, all named Web.config, can appear in multiple directories on an ASP.NET Web application server. Each Web.config file applies configuration settings (IIS authentication settings, for example) to source files in its own directory.

You can create custom configuration files in your Web projects that override settings in the default Web.config file (for example, mysettings.config). When working in a team development environment, creating such files is sometimes required. For more information about when to create custom configuration files, especially when developing shared projects, see Web References. For Web projects, the only *.config file that should be added to source control is Web.config.

Files Excluded from Source Control

Projectname.vbproj.webinfo is a special project file that keeps track of the virtual application root. The *.webinfo file does not appear in Solution Explorer and is not added to source control because each user's working copy of a project has to have its own virtual application root. Thus, if you share out the *.webinfo file, each developer's changes will be saved on top of your personal files without warning.

In addition to the webinfo file, Visual Studio .NET does not add certain project files to source control. Most excluded files contain user-specific settings that should not be shared. Along with the *.suo file, the following Web project files, among others, should never be added to source control:

  • Build outputs
  • *.vbproj.user, *.csproj.user
  • *.vbproj.webinfo, *.csproj.webinfo
  • *.scc (but not *.vspscc)
  • Any configuration file containing user settings that override the standard Web.config file. For an example, see Appendix A: Setting Up Dynamic URL Web References.

Normally, you should simply use the Add Solution to Source Control or Check In commands to add projects and files to the source control server. By using this method, you can ensure that all appropriate solution and project files will be added to source control.

Web References, Web Projects, and Source Control Integration

A Web reference is a generated proxy class that represents the exposed functionality of a deployed XML Web service. In your ASP.NET Web projects, a URL represents a Web reference, which can be either static or dynamic. The default value for the Web reference URL property is static. When developing Web applications in teams, changing this property to dynamic is sometimes necessary. Dynamic URLs are recommended for teams that use source control and develop solutions containing both ASP.NET Web application and Web service projects. In some situations, Web references might work for one user, but not for another. If this occurs, you can use a configuration file to define and store relative paths to these shared resources in a personal configuration file. For more information about dynamic URL Web references, and how to create them, see Appendix A: Setting Up Dynamic URL Web References.

Establishing a Source Control Strategy

Source control is as much a way of thinking about software development as it is a tool. It can facilitate parallel development and enable developmental isolation, but it can ensure neither. Only by establishing and following through on a strategy can a team use source control to its fullest potential. When developing a strategy for Web projects, you must choose one working method from each of the following categories:

Local Host vs Remote Host
Discusses the important difference between local and remotely hosted File Share Web projects.
Web Access Methods
Defines and compares the FrontPage and File Share access methods.
Shared Checkouts
Makes a case for disabling exclusive checkout mode so that developers can edit the same files at the same time.

Local Host vs Remote Host

In a team development environment, the location where you initially save a File Share Web project is extremely important. Web projects whose working copy you save to a subdirectory of http://localhost are referred to as local host projects. Projects whose working copy you save to a non-local host location (for example, http://teamserver/webapplication1) are referred to as remote host projects.

Local host projects are debugged locally. Remote host projects are debugged using remote debugging. You can debug a remotely hosted Web project only on a computer where a member of its Administrators group has given you Debugger User permissions.

Http://localhost is the default and recommended location for Web Projects in Visual Studio .NET. Save your project's working copy to a remote host location for one of the following reasons:

  • Your personal computer cannot be used as an IIS Web server.
  • You need to perform predeployment testing and debugging on a production server.

In most real-world situations, the production servers where a team deploys its Web applications are significantly more powerful than their development computers. Before deploying Web applications to such servers, you can open them from source control (on your own computer), set the working copy project location to a virtual directory on the production server, and then run and debug the project. On the production server, you can test for timing and concurrency issues that might not have appeared on a less powerful desktop computer. Applications that are developed on one computer and then debugged on another computer whose environment approximates or is identical to that of the production server are generally easier and less costly to deploy.

Note   When one user starts debugging, the debug process locks the shared Web server, effectively preventing other users from working on the server until they stop debugging.

Web Access Methods

A Web access method specifies how Visual Studio obtains write access to Web project files on a network. The method you select significantly affects the treatment of your Web projects under source control. Your team can avoid confusion by always using the same Web access method for each Web project.

Visual Studio provides two Web access methods, File Share and FrontPage. File Share is the new, default, and recommended Web access method for most Visual Studio .NET Web projects.

File Share

This is the default access method. A File Share Web application resides at a shared network location. When you create a Web application, you supply the HTTP address for the project, and Visual Studio resolves the address to a universal naming convention (UNC) share. Subsequent operations on the project use the UNC-addressable network share; you edit, save, compile, and run the project at the network location using a combination of direct file access and HTTP access.

When you open a Web project from source control, Visual Studio creates a working copy of the project's source-controlled master copy in your working folder (for example, http:/localhost/WebApp1). A working folder can be located on any Web server, but selecting the right location is extremely important when developing in teams. For more information, see Collaborative Development Models.

The following diagram illustrates how multiple developers can work in isolation, safely developing a master Web project in parallel using the File Share Web access method.

Figure 1.

Because each developer edits a working copy of the master Web project, the File Share Web access method supports shared checkouts. With shared, or multiple checkouts, many users can edit and save changes to project files concurrently without having to worry that they might overwrite another user's changes. For professional development teams, working in shared or multiple checkout modes is recommended because it facilitates parallel development. For more information and best practices related to working in shared checkout mode, see Shared Checkouts.

The File Share Web access method is preferable to FrontPage for the following reasons:

  • Supports shared checkouts. With shared checkouts, multiple users can check out and edit any file, even if another user has checked it out.
  • Supports advanced source control commands, such as branch, merge, pin, and label.
  • Allows for isolation. Team members can edit shared files on their personal computers and then safely merge those changes without overwriting the team's master copy.

Works with any source control provider that is Microsoft Source Code Control Interface (MSSCCI)-compliant. The FrontPage access method works only with Visual SourceSafe.

FrontPage Server Extensions

You can also configure Visual Studio to access Web project files using the FrontPage server extensions. On the server where you create the application, FrontPage is integrated with Visual SourceSafe. Source control requests from Visual Studio are forwarded through the FrontPage server extensions to the server installation of Visual SourceSafe.

When you develop a FrontPage Web project in Visual Studio .NET, there is working copy. A single version of the project resides on an IIS Web server where it is managed using the HTTP protocol. The following diagram illustrates how two developers interact in the context of a version-controlled FrontPage Web project.

Figure 2.

Note   You cannot use Visual Studio to add a project to source control through the FrontPage server extensions. You must add the project manually on the Web server where you create it.

For most applications, the FrontPage Web access method is not recommended for teams in Visual Studio .NET because it is not conducive to efficient parallel development. Source-controlled FrontPage Web projects are developed serially: one developer edits one file at a time. However, there are some situations in which you must use the FrontPage Web access method. For details, see Collaborative Development Models.

Note   If you work on a team that is connected by LAN or VPN, you can upgrade existing Web projects to the new File Share access method. For more information, see Upgrading from FrontPage to File Share.

Shared Checkouts

For most professional development teams, shared checkouts (or multiple checkout mode) is recommended. With shared checkouts, multiple users can check out and edit any file, even if another user has checked it out.

If you are accustomed to working in exclusive check-out mode, shared checkouts result in merge conflicts (overlapping changes that cannot be automatically resolved) less often than you might imagine. Even when they do, your source control provider typically provides an easy way to decide which changes to keep and which to discard.

If your team does work in shared checkout mode, never use the Check In command without first performing a Get operation on project items in the IDE. When you get the latest version from source control, you can merge your personal changes with a versioned master copy (if it has changed since last checkout), save the merged project to your working folder, and then test the project to make sure it still works. If you do not get the latest version of a Web project and attempt to check in files that have changed since last checkout, you could overwrite a working build with a broken one. In such situations, you have two options, neither of which is desirable:

  • You can debug the project on the Web server. For ASP.NET Web projects, however, doing so could block other developers from working on the project until your work is complete. For more information, see Local Host vs. Remote Host.
  • In source control, you can roll back to the last known good version of the master copy. Changes you made to your working copy since last checking out the project will be lost. This option involves data loss and is not recommended. Again, it is better to perform a Get operation and merge on your own computer if necessary than it is to perform a checkin and merge on the server.

Source control providers handle shared checkouts differently. If you use Visual SourceSafe 6.0c, exclusive checkouts are the default.

To allow shared checkouts in Visual SourceSafe 6.0

  1. On the source control server, click the Start button, point to Programs, point to Microsoft Visual SourceSafe, and then click Visual SourceSafe 6.0 Admin.
  2. Click Users, click Open SourceSafe Database, select the appropriate database, and then click Open.
  3. On the Tools menu, click Options.

    On the General tab, select Allow multiple checkouts, and click OK.

Collaborative Development Models

For Web projects, a collaborative development model is defined by the combination of each project's Web access method and the location where its contributors save their working copies. The three primary models are:

Isolated Development

In this model, each developer edits, runs and debugs, and saves incremental changes to a personal, working copy of the team's source-controlled master Web project. Developers save their working copies to a local host location on their personal Web servers. Individuals interact indirectly through a source-controlled master project. Team members can work on the same files at the same time because their source control provider mediates all version conflicts, either automatically or by prompting them to manually merge conflicts that cannot be resolved automatically. The following diagram illustrates how source control isolates the developers of a File Share Web project from each other's changes.

Figure 3.

Using the local host model, developers create Web projects at http://localhost/projectname. The first time project contributors open the project from source control, they save their working copies to the same relative URL, http://localhost/projectname on a personal Web server.

Tip   Even if you do not save your working copy to a local host location (for example, http://ProductionServer/WebApp1), you can still achieve complete isolation by ensuring that none of your teammates save their working copies to the same Web server. Save your working copy to a remote Web server to perform predeployment testing and debugging (looking for timing and concurrency issues) in the project's production environment.

Advantages

  • Web references are more easily created, accessed, and managed than projects created in a semi-isolated or non-isolated development environment.
  • Two or more developers can concurrently debug ASP.NET applications, each on their own servers.
  • Compared to the other collaborative development models, hardware, software, and server administration costs are very reasonable.
  • Supports advanced source control functionality, such as shared (multiple) checkouts, merge, branch, pin, and label.
  • Can be used with any MSSCCI-compliant source control provider.

Disadvantages

  • In some cases, testing is not as realistic (for example, where impersonation/delegation is being used and there is a one-hop limit or where the production server is significantly faster than the development computers).
  • Each developer is responsible for configuring IIS settings, which is not necessarily the case when a working copy is stored on a central Web server.
  • All developers must have access to the same LAN or VPN.

Semi-Isolated Development

In this model, one team member creates a File Share Web project and then adds it to source control using Visual Studio .NET integrated source control services. Other developers open the project from source control and edit working copies of the master Web project in isolation. However, they run and debug using the shared resources of a remote Web server. In contrast to the isolated development model, developers save their working copies to a common Web server. Multiple developers can still check out and edit the same files, at the same time, but only one developer can run and debug the application on the Web server at any one time.

The following diagram shows the relationship between developers and the location of their working copies on a shared Web server when developing a source-controlled File Share Web project.

Figure 4.

Using the semi-isolated model, a developer creates a Web project on a remote server (for example, http://teamserver/WebApp1_DevA), and then adds it to source control. The first time project contributors open the project from source control, they save their working copy to the same remote Web server, using a different project name and different save location (for example, http://teamserver/WebApp1_DevB). Unlike the simple isolated development model, developers cannot refer to their working copies using the same name as other developers.

Advantages

  • Requires less expensive hardware and only one set of enterprise software licenses per project.
  • Teams can have a network administrator who specializes in the management of shared developmental resources.
  • Does not require access to http://localhost. IIS need not be installed on every developer's computer.
  • Supports advanced source control functionality, such as shared (multiple) checkouts, merge, branch, pin, and label.
  • Can be used with any MSSCCI-compliant source control provider.

Disadvantages

  • When any one user is debugging, the debug process locks the shared Web server, preventing other users from working on projects on the same server.
  • Web references are not automatically shareable. For more information, see Appendix A: Setting Up Dynamic URL Web References.
  • All developers must have access to the same LAN or VPN.

Non-Isolated Development

In this model, developers do not work against a working copy of a Web project. Rather, all team members directly edit and save their changes to the master copy of a FrontPage Web project. Developers cannot work in parallel and cannot easily isolate themselves from other developers. The following diagram illustrates how two developers interact in the context of a non-isolated Web project that has been configured to use external version control in IIS.

Figure 5.

Unlike File Share projects, a FrontPage Web project cannot be added to source control in the IDE. Rather, its version control status must be changed in IIS. For more information, see Setting Up External Source Control. Both IIS version control options, Built in and Use External, enforce exclusive checkouts, limiting write access to a file to only one developer at a time. The difference between these version control options is that Built in does not send the latest version to source control on check in, but Use External does. For FrontPage Web projects, the Use External option is recommended.

Advantages

  • Team members do not have to be connected by LAN or VPN.

Disadvantages

  • Multiple checkouts are not supported.
  • Does not provide the same level of file security as the other models. For example, if an individual deletes a project file from the Web server when using Built in version control, the files cannot be recovered from a team member's development computer.
  • You cannot use the FrontPage access method to add a Web application to source control from within Visual Studio. For more details, see Setting Up External Source Control.
  • Does not support advanced source control features such as shared (multiple) checkouts, or commands such as merge, branch, pin, and label.
  • Can be used only with one source control provider, Visual SourceSafe.
  • Projects must be saved on an NTFS partition.
  • Any user with Administrator permissions in a FrontPage Web project can disable or enable source control, regardless of their source control provider-assigned permission level.

Choosing a Collaborative Development Model: Web Project Creation

This section can help you quickly choose and implement a strategy for developing ASP.NET Web projects in teams. Answer the questions in the following diagram to discover which collaborative development model is recommended for your team. After selecting a model, you can use the referenced procedure to create your Web project and add it to source control.

Figure 6. Deciding how to create a Web project

Isolated Development: Creating a Source-Controlled Web Project

Isolated development is recommended for creating most Web projects in Visual Studio .NET. To learn more about the advantages and disadvantages of this model, see Isolated Development.

To select the Web access method

  1. On the Tools menu, click Options.
  2. In the Options dialog box, click the Projects folder, and then click Web Settings.
  3. Under Preferred access method, click File share.

By creating blank solutions and then adding projects to them, you can improve the long-term manageability and discoverability of your projects. You can also maintain a close symmetry between local project files and their master copies on the source control server.

To create a solution directory

  1. On the File menu, point to New, and then click Blank Solution.
  2. In the New Project dialog box, type a name and location for the solution.
    Tip   Choose a name that clearly identifies this item as a solution (for example, SalesWeb_Solution or SalesWeb_Soln).

To create the Web project

  1. On the File menu, point to Add Project, and then click New Project.
  2. In the Add New Project dialog box, select either Visual Basic Projects or Visual C# Projects from the left pane.
  3. Select a Web project template in the right pane.
  4. In the Location box, type http://localhost/projectname, where projectname is your name for the new project, and click OK.

You can now add the Web project to source control, opening it for development by your teammates. For a conceptual description of the following procedure, see What Happens When I Add a Web Project Solution to Source Control?.

If possible, add the project to a source control database where shared or multiple checkouts are allowed. For more information, see Shared Checkouts.

To add the Web project (and its solution) to source control

  1. In Solution Explorer, right-click the solution node, and then click Add Solution to Source Control.
  2. If a message box appears, click Continue.
  3. Provide database location and user logon information as required by your source control provider.
  4. Create a root solution directory on the source control server by specifying the server location for the solution file.
  5. Under the root solution directory, type a name for the project folder that will contain the master copy of your Web project's files.
    Note   To add second and subsequent projects to source control in this solution, check in the solution after making your changes.

To capitalize fully on the advantages of the isolated development model, project contributors must independently specify the same relative address for the Web project's working copy (http://localhost/projectname) the first time they open this project from source control. For step-by-step instructions, see Opening an Existing Web Project for the First Time.

Semi-Isolated Development: Creating a Source-Controlled Web Project

While preferable to the non-isolated model, semi-isolated development is not as conducive to collaborative development as the isolated model. For a detailed description of this model and a brief discussion of its advantages and disadvantages, see Semi-Isolated Development.

To select the Web access method

  1. On the Tools menu, click Options.
  2. In the Options dialog box, click the Projects folder, and then click Web Settings.
  3. Under Preferred access method, click File share.

By creating blank solutions and then adding projects to them, you can improve the long-term manageability and discoverability of your projects. You can also maintain a close symmetry between local project files and their master copies on the source control server.

To create the solution directory

  1. On the File menu, point New, and then click Blank Solution.
  2. In the New Project dialog box, type a name and location for the solution.
    Tip   Specify a name that clearly identifies this item as a solution (for example, SalesWeb_Solution or SalesWeb_Soln).

To create the Web project

  1. On the File menu, point to Add Project, and then click New Project.
  2. In the Add New Project dialog box, choose either Visual Basic Projects or Visual C# Projects.
  3. In the right pane, select a Web project template.
  4. In the Location box, type http://servername/projectname, where servername is the name of a Web server and projectname is your name for the new project, and then click OK.

You can now add the Web project to source control, opening it up for development by your teammates.

To add the Web project to source control

  1. In Solution Explorer, right-click the solution node, and then click Add Solution to Source Control.
  2. If a message box appears, click Continue.
  3. Provide database location and user logon information as required by your source control provider.
  4. Create a root solution directory on the source control server by specifying the server location for the solution file.
  5. Under the root solution directory, type a name for the project folder that will contain the master copy of your Web project's files.

The project is now ready for development. Each project contributor must now open the project from source control using one of the procedures described in Opening an Existing Web Project for the First Time.

Non-Isolated Development: Creating a Source-Controlled Web Project

For a description of the non-isolated development model and a brief discussion of its advantages and disadvantages, see Non-Isolated Development. Use the following procedures to create a source-controlled Web project for non-isolated development.

To select the Web access method

  1. On the Tools menu, click Options.
  2. In the Options dialog box, click the Projects folder, and then click Web Settings.
  3. Under Preferred access method, click FrontPage.

By creating blank solutions and then adding projects to them, you can improve the long-term manageability and discoverability of your projects. You can also maintain a close symmetry between local project files and their master copies on the source control server.

To create a solution directory

  1. On the File menu, point to New, and then click Blank Solution.
  2. In the New Project dialog box, type a name and location for the solution.
    Tip   Specify a name that clearly identifies this item as a solution (for example, SalesWeb_Solution or SalesWeb_Soln).

To create the Web project

  1. On the File menu, select Add Project, and then click New Project.
  2. In the Add New Project dialog box, choose either Visual Basic Projects or Visual C# Projects from the left pane.
  3. In the right pane, select a Web project template.
  4. In the Location box, type http://servername/projectname, where servername is the name of a Web server and projectname is your name for the new project, and then click OK.

You can now add the project to source control. Visual SourceSafe is the only source control provider that can be used to manage your FrontPage Web projects. Depending upon the version of FrontPage Server Extensions (FPSE) that you have installed, use one of the following procedures to place your project in the default VSS database for its Web server.

To use external source control for a FrontPage Web project (FPSE 2000)

  1. Right-click My Computer, click Manage, and then click Services and Applications.
  2. Open Internet Information Services, and then expand Default Web Site.
  3. Right-click the Web to which your FrontPage Web project belongs, and then click Properties.
  4. In the Properties dialog box, click the Server Extensions tab, set the Version Control box to Use External, and then click OK.
  5. Click OK in response to all warning messages that might appear.
    Note   If the Use External option is not available, see Knowledge Base article Q296715.

To use external source control for a FrontPage Web project (FPSE 2002)

  1. Right-click My Computer, click Manage, and then click Services and Applications.
  2. Open Internet Information Services, right-click Default Web Site, and then click Properties.
  3. In the Default Web Site Properties dialog box, click the Server Extensions 2002 tab, and then click Settings.
  4. Click Administration in the upper left hand corner of the Change Configuration Settings page.
  5. On the Server Administration page, click Default Web Site.
  6. At the bottom of the Site Administration for Server page, click the appropriate Subweb name.
  7. On the Web Site Administration for Web Project page, click Configure version control.
  8. On the Configure Version Control page, select the Use external version control (Visual SourceSafe only) option, type the name of your project after "$/" in the Specify which Visual SourceSafe project to use box, and then click Submit.
    Note   If the Use External option is not available, use the SourceSafe Administrator program to open the default VSS database (either Microsoft Visual Studio or Common) and add your NT user name to the user list. If the Use External option still does not appear, return to SourceSafe Administrator and add IUSER_machinename, where machinename is the name of the host computer. For more information, see Knowledge Base article 171116.

The project is now ready for development. Each project contributor must now open the project from source control using one of the procedures described in Opening an Existing Web Project for the First Time.

Opening an Existing Web Project for the First Time

This section can help you decide how to open a Web project from source control and, for File Share Web projects, identify the best place to save your working copy. Answer the questions in the following diagram, and consult other project contributors to identify the best way to open an existing source-controlled Web project for the first time.

Figure 7. Deciding how to open a source-controlled Web project

Note   For developers opening File Share Web projects (you answered "Yes" to the first question), you should ask the project's owner where to save your working copy. For isolated development, use http://localhost/projectname. For semi-isolated development, use a non-local host URL.

Isolated Development: To open a Web project for the first time

  1. On the File menu, click Source Control, and then click Open from Source Control.
  2. Locate the Web project you want to open in the appropriate source control database, and then click OK.
  3. When prompted to provide a local working copy location, type http://localhost/projectname, where projectname is the same as the source-controlled master copy.
    Note   The next time you open this project, do not use the Open from Source Control command. Instead, open it like any other project using the Open Project command.

Semi-Isolated Development: To open a Web project for the first time

  1. On the File menu, point to Source Control, and then click Open from Source Control.
  2. Locate the Web project you want to open in the appropriate source control database, and then click OK.
  3. When prompted to provide a local save, or working copy location, type http://servername/projectname_myname, where servername is the name of a shared Web server, where projectname is the same as the source-controlled master copy, and where _myname is your name or initials.
    Note   The next time you open this project, do not use the Open from Source Control command. Instead, open it like any other project using the Open Project command.

Non-Isolated development: To open a Web project for the first time

  1. On the File menu, click Open, and then click Project from Web.
  2. If the Web Access Failed dialog box appears (as it normally does), click the Try to open the project with FrontPage Server Extensions button.
    Note   The next time you open this project, do not use the Project from Web command. Instead, open it like any other project using the Open Project command.

Source Control Integration, Behind the Scenes

The following sections explain what happens when you add a Web project to source control or open one from source control for the first time.

What Happens When I Add a Web Project Solution to Source Control?

When you add a File Share Web project to source control, the following occurs:

  • You receive the message: "You are attempting to add some File Share Web access projects to source control. If you continue, you will no longer be able to open these projects using FrontPage Web access." This is a routine, informational message. For more information, see Web Access Methods.
  • Master copy, solution files   Your source control provider prompts you to specify a source control server location for the master copy of your solution files. It then copies the appropriate solution items to that location. Solution files containing user-specific settings are never added to source control.
  • Master copy, project files   You are prompted to specify a second server location for your project files. Be sure to locate the project files in a subfolder of the solution. All shareable project files are then copied from their Web server location to the source control server.

    If more than one project exists in the solution, you are prompted to specify a different server location for each project.

  • Solution binding   The source control provider silently creates a binding or relationship between your solution files in their working folder and their master copies in the source control database. During this process, most source control providers create one or more data files at the root of your working folder to store source control information.
  • Project binding   The source control provider then repeats the preceding process for the project. Because its working copy does not reside in the same root directory as the solution's working copy, the source control provider creates a separate project binding.

The following diagram illustrates how a project's working copy is bound to its master copy under source control. Two bindings are created for a simple solution-Web project pair because their files reside in different root directories.

Figure 8.

What Happens When I Open a Web Project Solution from Source Control?

The first time you open a File Share Web project from source control in Visual Studio .NET, the following events occur:

  • A binding is created for solution files.   Your provider asks you to identify a personal working folder for your solution files. This action creates a relationship, or binding, between the working folder and its master copy in the source control database. Depending upon the provider, this process typically involves the creation of data files at the root of your working folder. The default location for such files is your personal Visual Studio project directory.
  • Solution files are copied to your working folder.   Your source control provider creates your working copy of all solution files in the working folder you just selected.
  • A location for Web files is set.   In the Set Project Location dialog box, your provider then prompts you to identify a personal working folder for each of the Web projects in the solution. This action creates a second binding between your working folder and its master folder on the source control server.
  • Project files are copied to your working folder.   Finally, your source control provider creates your working copy of all Web project files in the selected working folder.

General Tips, Notes, and Guidelines

  • Create blank solutions, and then add your projects to them. Doing so organizes your project files on disk (working copy) as they will be organized in the source control database (master copy). Enforcing a parallel organizational scheme improves the long-term manageability of project files and makes it easier to perform certain advanced source control operations, such as branching and merging.
  • When adding a Web reference from an ASP.NET project to a Web service project on the same Web server, use an absolute path, such as http://servername/WebService1.
  • After a project is added to source control, the Web access method for a project should not be changed.
  • Use the Open From Source Control command on the Source Control submenu of the File menu the first time you open a Web project from source control. Thereafter, open the project like any uncontrolled Web project from your local disk:
    • For both File Share and FrontPage Web projects, click File, point to Open, and then click Project.
  • To check out an existing source-controlled, File Share Web project, developers must have access to the LAN or VPN where the project's master copy resides.
  • If you take your laptop home for the night, always check out the files you plan to edit before disconnecting from the network. Never use offline checkout with Visual SourceSafe.
  • For FrontPage Web project development, the Use External version control option is superior to the Built in option. Use External prompts Visual Studio to save each checked-in version to a source control database. Built in does not. For more information, see Non-Isolated Development.
  • Allow shared checkouts whenever possible.
  • When performing a source control operation on a Web project-containing solution, you should perform the operation on the entire solution if possible. For example, when you want to check out an ASP.NET Web application project, check out its solution instead.
  • Use only the stand-alone version of your source control provider to perform operations that cannot be completed in the IDE (for example, branching and merging branches).
  • Use dynamic URL references. See Appendix A: Setting Up Dynamic URL Web References for more information.
  • If Visual SourceSafe is your source control provider, always save Web pages with ANSI encoding if possible.
  • Do not place the working copy of solution files on the IIS Web server.
  • If you create your Web application using FrontPage access on a server with a FAT or FAT32 partition, source control will not work correctly. Because the FAT partition cannot provide sufficient security context, all operations are performed under the same guest account, IUSR_Machinename. This can cause your files to erroneously appear to be exclusively checked out to another user when you attempt to perform check in or check out operations. It is possible to work around this problem by disabling anonymous access to the project in the IIS administrative tool, but this workaround is not supported. Instead, it is strongly recommended that you convert your FAT partition to the NTFS file system.

Frequently Asked Questions

What is the recommended way to deploy my Web application to the Web?
Get the latest version from source control, merge changes as required, check in your changes, and then copy the master copy of all project files to the appropriate production server location using the Copy Project command. For more information, see Appendix C: Deploying Web Projects.
How can my team avoid having to remove and then add the same Web Reference to a project every time the project location changes?
You can configure your Web project to accept dynamic URL Web references. For more details, see Appendix A: Setting Up Dynamic URL Web References.
When creating a Web project, why are there so many dialog boxes? Why do I have to set the project location twice?
As you've probably noticed, when you create a new project without a solution, Visual Studio creates a new solution for you. Solutions containing Web projects are no different from solutions containing non-Web projects. That is, they initially contain two files (solutionname.sln and solutionname.suo) and by default, are saved to your Visual Studio Projects location on disk. Web project files, on the other hand, must be saved to a virtual directory.

Whenever you add two or more items (solution files and project files, for example) your source control provider creates a linking file in the items' root directories. If the items share a root directory, the provider creates its linking file at the lowest common root. If the items do not share a common root directory, as is the case when some items reside on disk and other items reside in virtual memory, your provider creates linking files in two locations. Therefore, when you add a Web project solution to source control, your provider prompts you to identify a working folder twice — once for the solution and a second time for the project.

Is there any way to automate the notification of team members of changes to a Web service to ensure that all client references are refreshed in a timely manner?
Visual Studio .NET provides no such tool. Team members who edit a Web service must personally inform other team members of the change.
I work on a team of four developers, two of whom work outside the corporate network. Which collaborative development model should we use when developing Web application projects?
Use the non-isolated development model.

FAQ for Visual InterDev Developers

Can my team work in local mode in Visual Studio .NET. In VID, each developer worked offline, saving changes to a local working copy before updating the master server version. Can we do this in Visual Studio .NET?
Yes. While not explicitly identified as such in the IDE, local mode is the default method for collaborative Web project development in Visual Studio .NET. To work in local mode, use either the isolated or semi-isolated development models.
Can my team work in master mode in Visual Studio .NET?
Yes. You can set your Web access mode to FrontPage and use the non-isolated development model. In the compiled world of ASP.NET, however the non-isolated model is not generally recommended for team development. For details, see Non-Isolated Development.
How do I release my working copy or synchronize changes to the master server in Visual Studio .NET
Unlike VID, Visual Studio .NET does not have a Release Working Copy command. To update the production server (master server) in Visual Studio .NET, you must deploy it using one of several methods. The first step in deploying an ASP.NET project is to update the source-controlled master copy. The second involves copying project files to the production server. For more information, see Deploying Web Projects.
How do I remove my project from source control as I did in VID?
On the File menu, click Source Control, and then click Change Source Control. In the Change Source Control dialog box, select the project you want to remove from source control, and click Disconnect.
Does the term working copy have the same meaning in Visual Studio .NET as it did in VID?
Not exactly. In VID, working copy referred to the version of a Web to which you had write access. In local mode, your local version was the working copy. In master mode, the master copy was your working copy.

For File Share Web projects in Visual Studio .NET, working copy always refers to your personal version. For FrontPage Web projects (see Non-Isolated Development), all team members save changes to the same master copy.

While working on my working copy (the local version), how do I synchronize my changes to the server?
As previously noted, working copies exist only for File Share Web projects. Under File Share, the master copy resides in a source control database and cannot be accessed with a browser. To synchronize changes to your working copy with the source-controlled master copy, get the latest version from source control, build the project in Visual Studio, and check in the project.

Appendix A: Setting Up Dynamic URL Web References

If you create a solution that contains both XML Web service and ASP.NET Web projects, and then reference XML Web services from your ASP.NET project, the Web reference will work for you, but not for other users.

Web references cannot always be shared among team members because Visual Studio stores them as static, hard-coded strings in the Web.config file. This issue does not occur when all team members set the project location of their working copies to http:/localhost/projectname because doing so effectively assigns a relative path to a physical location - http://computername/projectname.

For non-local host projects, you can work around this issue by converting the static Web reference URLs in a project's Web.config file into a dynamic property. You use dynamic properties to configure your application so that some or all of its property values are stored in an external configuration file rather than in the application's compiled code.

Tip   Because you or any other user can change them at run time, dynamic properties can be used to test different Web services quickly and easily.

You can also use dynamic properties to make your Windows applications easier to test, deploy, and administer. For more information, see Introduction to Dynamic Properties.

The following procedures document how to share Web references effectively in a team development environment when referencing a Web service on the same server as the calling project. These procedures assume that you have created a File Share Web project called WebApplication1 and two Web services (WS1 and WS2) on a server called Server1. It also assumes that you have added a Web reference to WebApplication1 that references WS1.

Tip   You can create a Web service quickly by opening Service1.asmx, switching to code view, and then removing comments from the appropriate lines of code in the Hello World example. To differentiate between them at run time, change "Hello World" to "Hello World: WS1" and "Hello World: WS2" in their respective files.

To make a Web reference URL dynamically configurable and shareable under source control

  1. In Solution Explorer, expand the Web References folder, and select the appropriate service.
  2. In the Properties window, change the value for URL Behavior from Static to Dynamic.

    Assuming that your Web service is returning some type of content, Visual Studio automatically adds the following code to your project's Web.config file:

    ' Visual Basic
    // C#
    <appSettings>
       <add key="WebApplication1.Server1.Service1" value=" 
       http://Server1/WS1/Service1.asmx" />
    </appSettings>
    

    In this example, the key attribute identifies the name of the Web reference and the value attribute identifies its target.

  3. In Solution Explorer, right-click WebApplication1, point to Add, and then click Add New Item.
  4. In the Add New Item – WebApplication1 dialog box, select Text File.
  5. In the Name box, type User.config, and then click Open.
  6. In the User.config file, paste the following code:
    <?xml version="1.0" encoding="utf-8"?>
       <appSettings>
          <add key="WebApplication1.Server1.Service1.asmx"
          value="http://localhost/ws1/Service1.asmx"/>
       </appSettings>
    
  7. Open Web.config, change <appSettings> to <appSettings file="user.config">, and then remove all code between the opening and closing <appSettings> tags.

You now have a personal configuration file that overrides the public settings in the Web.config file.

Note   If your project is under source control, you should right-click User.config and click Exclude from Source Control. The User.config file contains your personal configuration settings.

When another user opens WebApplication1 from source control and attempts to build the application, WS1 appears to be inaccessible. The problem is that the public and source-controlled Web.config file refers to the location where your personal, working copy of WS1 is stored. To make WS1 automatically accessible to other users, instruct them to create their own personal configuration files (and make sure that they don't add them to source control). Each developer who opens your WebApplication1 project must perform the following procedure.

To share Web references across a team

  1. In Solution Explorer, right-click WebApplication1, point to Add, and then click Add New Item.
  2. In the Add New Item – WebApplication1 dialog box, select Text File.
  3. In the Name box, type User.config, and then click Open.
  4. In the User1.config file, paste the following code.
    <?xml version="1.0" encoding="utf-8"?>
       <appSettings>
          <add key="WebApplication1.Server1.Service1.asmx"
          value="http://localhost/ws1/Service1.asmx"/>
       </appSettings>
    
  5. Open the Web.config file and change <appSettings> to <appSettings file="user.config">.

Switching Between Web services at Run Time

Besides making Web references easier to share, dynamic URLs make it possible to switch between two or more Web services quickly. Dynamic properties are stored in a configuration file that anyone can access at run time. That is, you can change the behavior of an application at run time by editing a publicly available and uncompiled resource, the User.config file. Follow these steps for a short demonstration.

To switch between WS1 and WS2 at run time

  1. In WebApplication1, open WebForm1.aspx, and then drag a Label control from the Toolbox onto the designer.
  2. Switch to code view by double-clicking the designer, and then paste the following code into the Page_Load event handler:
    Server1.Service1 a = new localhost.Service1();
    Label1.Text = a.HelloWorld();
    
  3. Build WebApplication1.

    If you followed all of the steps in the preceding procedures, you should see Hello World: WS1.

  4. Open C:\Inetpub\wwwroot\WebApplication1\User.config in the code editor.
  5. Change "value="http:/localhost/ws1/Service1.asmx"" to "value="http:/localhost/ws2/Service1.asmx"" and save your changes.

The next time you run WebApplication1, you should now see "Hello World: WS2" rather than "Hello World: WS1."

Appendix B: Changing Web Access Methods

Changing a project's Web access method fundamentally alters the way that you and your teammates interact with the master copy under source control. Upgrading FrontPage projects to File Share is recommended. Convert File Share projects to the FrontPage Web access method only when absolutely necessary. Before performing any of the following procedures, ensure that all versions of the projects you are planning to change are checked into source control.

Select one of the following links to learn more about changing the Web access method for a Web project:

Upgrading Visual InterDev Projects to File Share

You can upgrade a source-controlled Visual InterDev (VID) Web to ASP.NET so that it can be accessed from source control using the File Share Web access method.

Note   This procedure effectively forks your VID project into two projects under source control. You can still view the history and perform source control operations on older versions of your project, but only by opening the VID project in source control.

To upgrade a Visual InterDev project to File Share

  1. Open Visual Studio .NET, click Tools, and then click Options.
  2. In the Options dialog box, click the Projects folder, and then click Web Settings.
  3. Under Preferred access method, click File share, and then close the dialog box.
  4. On the File menu in Visual Studio .NET, point to New, and then click Project.
  5. In the New Project dialog box, select a language (Visual Basic or C#) in the left pane, click ASP.NET Web Application in the right pane, type a location (for example, http://localhost/MyNewWeb), and then click OK.
  6. Minimize the Visual Studio .NET IDE, start the Visual SourceSafe Explorer, and then open the SourceSafe database containing your VID project files.
  7. Open your Web project folder, select all source files in the Contents pane, point to SourceSafe, and then click Get Latest Version.
  8. In the Get dialog box, replace all text in the To box with your ASP.NET Web application path (for example, c:\inetpub\wwwroot\MyNewWeb), select Make Writable, and then click OK.
  9. In Visual Studio .NET, select your project and, on the File menu, click Add Existing Item.
  10. In the Add Existing Item dialog box, open the Web project's working folder, select all of the files you just copied from source control, and then click Open.
  11. Right-click the solution node in Solution Explorer, and then click Add Solution to Source Control.

Upgrading from FrontPage to File Share

You upgrade FrontPage Web projects created in Visual Studio .NET to the recommended File Share Web access method to:

  • Improve the day-to-day manageability and integrity of your team's ASP.NET Web application resources.
  • Use a source control provider other than Visual SourceSafe. In the past, the only source control provider capable of managing Web projects was Visual SourceSafe. The File Share Web access method is now supported by a number of third-party source control applications.

In the following procedures, you use the Internet Information Services (IIS) management console to disable source control integration for your FrontPage Web project. You then use Visual Studio .NET to change the Web access method and rebind the project under source control.

To disable source control for your FrontPage Web project

  1. Right-click My Computer, click Manage, click Services and Applications, open Internet Information Services, and then expand Default Web Site.
  2. Right-click the Web to which your FrontPage Web project belongs, and then click Properties.
  3. In the Properties dialog box, click the Server Extensions tab, set the Version Control box to None, and then click OK.
  4. Click OK to all messages that might appear.

You now open Visual Studio .NET, change the Web access method to File Share, and rebind the project to your personal working folder under source control.

To change the Web access method and rebind your project

  1. On the File menu in the IDE, point to Open, click Project from Web, enter your Web project URL, and then click OK.
  2. In Solution Explorer, right-click the project, and then click Properties.
  3. Under Common Properties in the Project Properties dialog box, select Web Settings, and then change the value for Web Access Mode to File Share.
  4. In Visual Studio, close and then reopen the Web project and its solution.
  5. In Solution Explorer, select the project and, on the File menu, point to Source Control, and then click Change Source Control.
  6. In the Change Source Control dialog box, select your project, click Bind, and then click OK. Click OK to all warning messages that appear.
    Note   You must rebind your solution and project to locations where they were previously saved to maintain the continuity of your source control history.
  7. In Solution Explorer, right-click the project, click Check Out, and click OK to the warning messages that follow.
  8. When the message "Your folder contains a writeable copy of project path" appears, select Leave this file, and then click OK.
  9. In Solution Explorer, right-click the project, and then click Check In.

Converting File Share Projects to FrontPage

Before converting a File Share Web project to the FrontPage Web access method, carefully consider the alternatives. Convert to FrontPage to:

  • Access design time project resources that .NET Passport authentication helps to protect.
  • Connect to or allow access to projects behind a firewall. These include projects that one or more team members cannot access through a LAN or VPN.

To convert from File Share to the FrontPage Web access method

  1. Select the ASP.NET Web project in Solution Explorer.
  2. On the File menu, point to Source Control, and then click Change Source Control.
  3. In the Change Source Control dialog box, select your Web project, and then click Unbind.
  4. Repeat this step for each item in the Change Source Control list, accept all messages that appear, and then click OK.
  5. Right-click the Web project you want to convert in Solution Explorer, and click Properties.
  6. Under Common Properties in the Project Properties dialog box, select Web Settings, and then change the value for Web Access Mode to FrontPage.
  7. Select the solution, and on the File menu, click Close Solution.

You can now enable source control for your FrontPage Web. If you have installed FrontPage Server Extensions 2000, see Use External (FPSE 2000) for further instructions. If you use FrontPage Server Extensions 2002, see Use External (FPSE 2002) for further instructions.

Appendix C: Deploying Web Projects

Visual Studio .NET provides several powerful deployment tools, including Web setup and deployment projects. The following procedure documents an easy way to promote changes from the master copy (in the source control database) to its production server location. For more information about other Visual Studio .NET deployment alternatives, see Methods of Deployment.

For Web projects, the Copy Project command is available on the Project menu. Copying a project, rather than deploying it, is an easy way to move your project's content to a target Web server. However, copying does not automatically configure Internet Information Services (IIS) directory settings. Therefore, we recommend deploying your project in most cases because it allows you to take advantage of extensive deployment project management features, such as registration and IIS configuration.

By default, the Copy Project command creates a new Web application on the target server and copies only the files required to run to the application. FrontPage Server Extensions must be installed on the target server to use the Copy Project command. Also note that the Web access method you use to deploy a project is completely unrelated to (and does not change) the project's Web access method in Visual Studio. The following procedure deploys a Web application over HTTP.

To deploy an ASP.NET Web project

  1. On the Project menu, click Copy Project.
  2. Select a destination project folder and server.
  3. Click the FrontPage button.
    Note   FrontPage is the default and recommended option in this context. If you use the File share option, set the Path using the following syntax: \\servername\wwwroot$\projectname.
  4. Select the files to be copied.

The default option deploys only the files needed to run the application. You can also deploy all project files or all files in the project folder.

Additional Information

Team Development Guide

Authentication in ASP.NET: .NET Security Guidance

IIS Lockdown Tool

Walkthrough: Deploying a Web Solution

Upgrading Visual InterDev 6.0 Applications to Visual Studio .NET

Converting ASP to ASP.NET

Migrating to Web Forms

Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic .NET

Remote Server Configuration for Developing Web Projects Using Visual Studio .NET

Deployment Changes in Visual Basic .NET

XML Web Services Infrastructure

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.