Web applications development is one of the most usual activities carried out by most software companies using Visual Studio. The IDE version 2005 introduced numerous improvements allowing working with this kind of applications. These improvements make working with Web applications more similar to conventional Windows applications. When it's about web development it is also essential to introduce parallel development and in order to do this the first step is to have a version control system to manage changes. This article will explain different solutions, as well as the right way of configuring Visual Studio to use it together with a version control system on web projects.
Although developing web applications with Visual Studio is quite similar to conventional applications development, there are some special features that impose certain constraints that should be taken into account. Visual Studio supports the following three working modes for version control on web projects:
This mode is the one that better adjusts to working with a version control and the one recommended by Microsoft. Each developer has his own web server (IIS) installed locally to enable executing and debugging applications. Code modifications are done on a local copy which works against the centralized version control. This is the usual working mode when using a version control.
Microsoft does not recommend to use this method if you pretend to work with a version control system. There is only one centralized server which will execute and debug the web application. This server will also host every source control copy. Workspaces will be placed on a remote machine and will be shared through net units or UNC paths. This working mode is no longer supported by Visual Studio 2005 and newer versions even though it was available on the 2003 version.
Microsoft does not recommend to use this mode but it is still used by many companies. There is only one web server configured to execute and debug web applications. Developers usually work from the server's FrontPage extensions. Programmers cannot work isolated with this type of development. Practically no version control supports this working mode.
In order to work with Visual Studio and Plastic SCM the isolated development working mode is mandatory. This way parallel development is possible, which are great news for users. The only disadvantage on isolated development is that the debugging and testing environment used by the developer is quite different from a real production system. Developers' computers are usually less powerful than the server where the real system will be actually executed, and they also have a different software configuration.
Nevertheless, the benefit of being able to make parallel changes and not being constrained to debug only a user at a time (as the other modes do, since there is only one web server) far out weights the possible disadvantages. Anyway, it is possible to sort out this limitation introducing a testing or preproduction server on which the application can be installed and tested.
The steps to create a new Project and associate it to Plastic SCM are described below. It is important to apply the following instructions on the indicated order:
The recommended directory structure to achieve the best performance under a version control is shown below:
We'll focus on 2005 version and newer versions. Also, we'll assume that Plastic SCM and the Visual Studio Package are installed on the computer.