Team Development with Visual Studio .NET and Visual SourceSafe
|This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Setting Up and Maintaining the Team Environment
Summary: This chapter describes the infrastructure and the hardware and software requirements for all of the workstations and servers within the team environment. It also provides guidance on how to create and maintain a VSS database.
This is Chapter 7 of the Team Development with Visual Studio® .NET and Visual SourceSafe guide. Start here to get the full picture.
This chapter provides guidance to help you set up your team development environment. In summary, the environment building blocks consist of all of the following:
- Developer workstations
- A Microsoft® Visual SourceSafe (VSS) server to maintain the source code control database or databases
- A backup server to maintain VSS database backups
- Computers running Microsoft SQL Server for development and test databases
- Web servers for development and test Web services
- A build server on which an automated build script is used to generate daily builds
You will also typically require one or more separate test environments; for example, a physically isolated stress test environment that can be used to run scalability and performance tests. The test environments are out of the scope of this document and are not discussed further.
The infrastructure for a team development environment is illustrated in Figure 7.1:
Figure 7.1. Team Development EnvironmentInfrastructure
Creating a Development Domain
Defining the development environment for your organization is not a simple task. You want to adhere closely to your existing corporate standards for user accounts and workstation builds, but at the same time you know that developers need more privilege on their workstations in order to:
- Install updates or operating system service packs.
- Manage Microsoft Internet Information Services (IIS) locally for application testing and fine-tuning.
- Debug ASP.NET Web applications.
The first step is to decide whether or not to put the development team in the corporate domain or in its own domain. There is no single right or wrong answer. To a large degree, the decision depends upon your corporate security policy. The desirable model is one that your organization is willing to accept and invest in and one that can be maintained properly by existing systems administrators.
Use the following scenarios as guidance to help you during your design process:
Standalone Domain with No Trust Relationship
The following are some of the features of using a standalone domain with no trust relationship:
- This offers the best security model because your corporate users are not able to access the development environment.
- A separate network means that you have flexibility and isolation when you need to perform load testing for capacity planning. You don't need to worry about impacting critical services.
- To use services in the corporate domain, for example e-mail and the intranet, developers can use a virtual private network (VPN) connection to connect to the corporate network.
- You can create a VPN server with Microsoft Windows® 2000 operating system and Routing and Remote Access Services, or you can deploy Microsoft Internet Security and Acceleration (ISA) Server, or third-party solutions.
- This model is more expensive because separate infrastructure serversdomain controllers, DNS, WINS, DHCP, and so on, are required (possibly with additional redundancy configurations).
Standalone Domain with Trust Relationships
The following are some of the features of using a standalone domain with trust relationships:
- This model is more convenient because no VPN solution is necessary.
- If you set up development user accounts within the development domain, the corporate domain has to trust the development domain in order to give access to services, which may be against your corporate security policy. Corporate users cannot access the development environment.
- If you set up development user accounts within the corporate domain, the development domain has to trust the corporate domain, which opens up the potential for hacking.
- With proper planning and pilot-testing, this option should work in most organizations.
Part of the Corporate Domain
The following are some of the features of using the corporate domain:
- This is the most convenient option because there is no domain separation.
- Developers can use all of the existing corporate infrastructure and services.
- Users might not be granted local administrator rights on their workstations under corporate security policy. This causes problems for developers because you must be a local administrator in order to be able to debug an ASP.NET Web application on your development workstation.
- Standard corporate network and security policies could hinder the development process. For example, developers may be not be allowed to install service packs unless they pass the corporate operations model.
The remainder of this section describes the roles of each of the computers in the development environment.
The VSS Server
This server is used to maintain one or more VSS databases that contain the source controlled solutions, project files, and source files for all of your team developments.
The VSS server is also a good candidate to host the Microsoft MSDN® Library for developer reference material. For more information, see article Q271776, "HOWTO: Create an MSDN Library Shared Install Point on the Network," in the Microsoft Knowledge Base.
The minimum recommended system specification for a VSS server is documented in the VSS readme file. However, in anything but the very smallest team environments, you will want a more powerful system, closer to the recommended specification for a Visual Studio .NET developer workstation. This is documented in the Build Server section later in this chapter.
Remember that the amount of time taken to perform routine VSS database administration tasks is greatly affected by the processor speed and amount of available RAM. You should also aim for a hard disk capacity approximately twice the size of your VSS database.
The following software is required on the VSS server:
- VSS version 6.0c. This ships with Visual Studio .NET Enterprise Architect and Enterprise Developer versions. It is also available via MSDN on CD/DVD or as a subscriber download.
- Appropriate backup software. The VSS database must be backed up on a regular basis, due to its critical role in the team development process. Use your current backup software and procedures to backup the VSS database.
The build server hosts the build script that allows you to generate specific versions of your system. In addition to the build script, the build server also maintains a set of shared folders that contain the latest output from the most recent build operation, together with previous versions, organized by build number. This allows developers to reference the latest inner-system assembly versions.
For more information about how developers must reference assemblies in a team development environment, see Referencing Assemblies in Chapter 4, "Managing Dependencies."
A recommended folder structure for organizing build output is discussed in Chapter 5, "The Build Process." The local folder structure used to maintain Visual Studio .NET solutions, projects, and source files should be consistent across the build server and developer workstations. For more information, see Chapter 3, "Structuring Solutions and Projects."
The following table lists the minimum recommended requirements for Visual Studio .NET that the build server must meet.
|Build Server||Minimum Requirements|
|Computer/Processor||PC with a Pentium II-class processor, 450 MHz |
(recommended: Pentium III-class, 600 MHz)
|Memory||Microsoft Windows NT® 4.0 Workstation64 MB, Windows NT 4.0 Server160 MB |
(recommended: 96 for Workstation, 192 for Server)
Windows 2000 Professional96 MB; Windows 2000 Server192 MB
(recommended: 128MB for Professional, 256 MB for Server)
Windows XP Professional160 MB
(recommended: 192 MB)
|Available Hard Disk Space||600 MB on system drive, 3 GB installation drive|
|Display||800 x 600, 256 colors (recommended: high color 16-bit)|
|Operating System||Windows 2000, Windows XP, and Windows NT 4.0|
|Peripherals||CD-ROM or DVD-ROM Drive. Microsoft mouse or compatible pointing device|
The following software is required on the build server:
- Visual Studio .NET
- Visual SourceSafe 6.0c (client)
- Any additional resource required by the system, such as IIS or Message Queuing.
Individual developer workstations must be set up with a consistent file system folder structure and one that matches the build server structureparticularly for the folders that contain Visual Studio .NET solutions and projects.
Use Imaging to Create Developer Workstations
To save time with the configuration of multiple identical development workstations, after you install all of the required applications and tools, consider using Sysprep.exe to create an image of the workstation. You can then deploy the workstation image to other computers with third-party disk-imaging software. The advantage of using Sysprep.exe is that it includes a mini-setup wizard, which detects the actual hardware installed in the new workstation, and can therefore handle hardware inconsistencies, such as different video adapters or network adapters.
It is recommended that you store all user data (including solutions and projects) on a separate partition or physical disk. This way, when there is a major update to the image, you can re-install the image over the existing drive C. You can deploy minor updates and additional software through Group Policy in Windows 2000 Active Directory Services.
Workstations must meet the minimum recommended requirements for Visual Studio .NET. As a result, developer workstations have the same hardware requirements as the build server, as discussed in the Build Server section earlier in this chapter.
The following software is required on development workstations:
- Visual Studio .NET
- Visual SourceSafe 6.0c client components
- SQL Server 2000 Developer Edition
- MSDN Library (Client)
Note If your development workstations run Windows XP, make sure IIS is installed to allow local Web development. A default installation of Windows XP doesn't result in the installation of IIS.
Visual Studio Enterprise Templates
You can use Visual Studio Enterprise Templates to help encourage good development procedures and standard practices across development projects. They are particularly useful when applied to large scale distributed system developments in situations where multiple projects will be constructed using a common application architecture.
Enterprise Templates provide architects with three capabilities they can use to help developers be more successful building applications with the .NET Framework:
- Package an architect supplied framework of existing code and components in a way that integrates it into Visual Studio .NET, providing developers with a familiar design experience. Architects can use this capability to provide application infrastructure that should be common and consistent across projects, in areas such as security, error handling, and application instrumentation.
- Capture architecture and implementation rules and apply them as "active" guidance while developers are building the application. Architects can use these rules to filter out options that are not relevant to the project at hand. These rules can provide immediate reminders when developers add items, references, interfaces, class members, or property values to inappropriate parts of the application, helping them avoid common problems.
- Help architects provide developers with relevant Help topics on a "just-in-time" basis to reduce the need to read mountains of documentation before they can begin to write code.
For more information about Enterprise Templates, see the "Enterprise Templates for Distributed Applications" topic in the Visual Studio .NET section of the MSDN library.
The backup server is used to maintain a backup of the VSS database. You should backup your VSS databases on a regular (for example, daily) basis.
SQL Server 2000 Enterprise Edition is installed on these servers. They are used to maintain the individual databases required by the systems that are currently under development, support, and maintenance.
Note that an individual server may be used to host several database instances, for example an integration test and a user test database. This depends to a large degree on the size of your databases and the capacity of your servers.
For further information about how database versioning issues should be addressed and how developers are recommended to connect to databases on this server, see Referencing Databases in Chapter 4, "Managing Dependencies."
Web servers host XML Web services that are currently under development. While the development teams responsible for Web services develop them on their local workstations using local instances of IIS, the Web server allows the services to be published centrally, for other developers or development teams to access from client projects. For more information about working with Web services, see Referencing Web Services in Chapter 4Managing Dependencies.
Web servers within the team development environment are also used to host Web applications to support integration, system testing, and user testing.
Operating System Requirements
The operating system requirements for a Web server that hosts ASP.NET Web applications and Web services developed with Visual Studio .NET are the following:
- Windows 2000, Windows XP, or Windows Server 2003.
- It is also recommended that you install the Web server on a computer formatted with the NTFS file system.
- The Web server must be running IIS 5.0 or 6.0.
For further details, see setup\WebServer.htm on the Visual Studio .NET CD1 or DVD.
Installing and Administering VSS
VSS 6.0c is supplied on a separate disc within the Visual Studio .NET Enterprise box and is not installed by default. You must install VSS on the server and then install the VSS client components on each computer that requires access to a VSS databasetypically the development workstations and build server.
The following sections outline guidelines you should follow when installing VSS on your server.
Create a Shared Database on the Server
Run the Setup program on your server and select the shared database installation option. This installs administration tools and the network setup program (NetSetup.msi) that allows VSS users to install the client software.
Share the VSS Installation Folder with Read Access
Share out your VSS installation folder with read access. This allows developers to run NetSetup.msi from the VSS folder. Note that the default VSS installation folder is \Program Files\Microsoft Visual Studio\Vss.
Create at Least One New Database for your .NET Development Project
Use the VSS Administration tool to create a new database for your .NET development project. It is recommended that you create a new database (rather than use the default one) so that you can secure the default database and administration tools (located in the Vss\Win32 folder) separately. This allows you to restrict who has access to the administration tools. Most users should be allowed to connect only to the new database and should be prevented from accessing the administration tools.
Don't create new databases beneath \Program Files. Create VSS databases beneath a separate shared folder, such as \VSS Databases.
Consider Creating Additional VSS Databases
Consider creating additional VSS databases (on the same server but within separate file shares) when the size of a single database approaches 5 GB in size. With this size of database, the administration tools begin to take an excessive amount of time (several hours) to perform their work.
You should also consider using separate databases for completely independent development projects. If you split your Visual Studio .NET solutions and projects into separate VSS databases, you benefit from the following advantages:
- It allows you to improve security by more precisely defining which users can access which projects. A user that has access to a single VSS database is able to view and manipulate all of the VSS projects it contains.
- Routine maintenance does not impact all projects. Maintenance such as backup requires that the database be locked, which prevents regular (non-administrators) from accessing the database.
- If you experience corruption within a database, you need to take it offline to rectify the corruption. With separate databases, you impact only the developers who access the affected database and you do not stop the workflow of all of your developers.
- When a development project ends, you can easily archive the project's database.
Share the Database Folder and Establish the Appropriate Permissions
Share the new database folder and grant your VSS users the full control permission. Your VSS users include developers and an account used by the automated build process.
Create a Windows group for all users who are allowed access to the VSS development database. Allow members of this group to access the development database, by securing your database folder.
If you don't want to grant users the full control permission and require tighter security control, see article Q131022, "INFO: Required Network Rights for the SourceSafe Directories," in the Microsoft Knowledge Base.
Consider Using VSS Project Security
Consider using the VSS Administration tool to enable project security and remove the Destroy right for all developers. This prevents developers from permanently destroying projects within VSS. The VSS administrator is able to recover any project that a developer may delete.
With project security enabled, the administrator must purge the database of all deleted items as part of regular maintenance, although this can be automated by a maintenance script.
For more information about default and project security, see Security Access Rights.
Add User Accounts for Developers and the Build Script
Use the VSS Administration tool to open the new database or databases and add the required users with appropriate passwords.
Remember to set up one VSS user for each developer and another for the build process. If you are in a domain environment, it is recommended that you make the user name the same as the domain name. Be sure the network name is used for user login. On the Tools menu, click Options, and then select the Use network name for automatic user login check box.
Restrict Access to Administration Tools
Create a Windows VSS administration group and use this to restrict access to the Vss\Win32 folder. This folder contains the VSS administration tools and you should restrict developer access to these tools.
Finding and Repairing Data Corruption
VSS ships with the Analyze tool (located in the Vss\Win32 folder) that can be used to check for and correct data corruption problems. You should use Analyze as frequently as is practicalonce a week is recommended, or at a minimum, once a month. Analyze checks all the files in the VSS Data directory for corruption or disconnected links and often repairs these with proper switch settings.
There are a number of reasons why you may experience database corruption. The most common reasons include:
- General network problems, such as using an unreliable remote connection and dropping the connection mid-way through a file check in.
- Running out of disk space.
Analyze can be slow to run although this depends on the content and structure of the database, such as the amount of sharing and branching, and the total number of files. For best performance, all users should log off VSS before you run Analyze.exe. If you use the -F switch to repair problems, users must log off.
Note Due to the amount of file I/O required, you can dramatically improve performance by running Analyze locally (that is, on the server) rather than across the network. You should also ensure that no virus protection software is currently running.
Consider Installing Fault Tolerant Storage
Redundant array of independent disks (RAID) technology minimizes data loss due to problems accessing a hard disk. RAID is a fault-tolerant disk configuration in which part of the physical storage capacity contains redundant information about the data stored on the disks. You can regenerate the data using this redundant information if one of the disks or the access path to it fails, or if a sector on the disk cannot be read.
- Install RAID Level 1 for the operating system and logs.
- Install RAID Level 5 or RAID 0+1 for data such as your VSS database.
For information about how to make your server more reliable, see the following resources:
Installing VSS on Clients
To install the VSS client, simply run NetSetup.msi from the network share on any computer that requires VSS access (for example, development workstations and the build server). This enables the integrated source control features within the Visual Studio .NET integrated development environment (IDE). This also enables the Source Control menu on the File menu.
Consider Using VSS Shadow Directories
A VSS shadow is a directory on a central server that mirrors the latest contents of a VSS project. Whenever a developer updates a file within the VSS project, it is automatically copied to the shadow directory.
If you need users who do not have access to VSS to be able to view source code, consider using shadow directories. For example, you may want members of your test team to be able to view source code to assist with the testing process.
For general VSS best practices, see http://msdn.microsoft.com/library/?url=/library/en-us/dnvss/html/vssbest.asp?frame=true.
Microsoft occasionally updates the Analyze tool to include more checking or to improve performance. For the latest version of Analyze, visit the Microsoft Visual SourceSafe Web site located at http://msdn.microsoft.com/en-us/library/aa302175.aspxdefault.asp.
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.