This guide provides team-development guidelines for lead developers, developers, configuration controllers and system administrators. Read this guide if you plan to, or are currently work on, a team-based development project with Microsoft Visual SourceSafe and Microsoft Visual Interdev.
What You Must Know
To use this guide to establish a team development environment and a development process suited to Microsoft Visual SourceSafe and Microsoft Visual Interdev, you must have some development experience with Microsoft Visual SourceSafe and Microsoft Visual Interdev.
Note: This guide focuses on the integration of Microsoft Visual SourceSafe version 6.0 (the version that ships with the Enterprise editions of Visual Studio 6.0) with Microsoft Visual Interdev 6.
The following is a step-by-step introduction to installing and setting up Visual SourceSafe along with integration to Visual Interdev. I have tried to also include in this article the problems that my team and I faced during the integration along with their possible solutions.
The first half of this article covers the installation steps of Visual SourceSafe and the administration setup. Although most of this content would be available in the MSDN library, we found it very scattered and not sequential enough. The second half is divided into steps towards integration with Visual Interdev and the trouble-shooting steps taken.
The key purpose of this article is to bring together the information related to this topic and provide a means of smooth installation and integration of Visual SourceSafe with Visual Interdev.
Steps to Set Up Source Control in Visual InterDev
|Sr. No.||Main Tasks||Related Area|
|1||Use Visual SourceSafe Setup to install Visual SourceSafe on the server.||Installing Visual SourceSafe (on same server as web server / on separate server).|
|2||In Visual SourceSafe, grant Visual SourceSafe permission to users.|
For Web servers on Windows NT®, add permissions to the anonymous user account.
|Visual SourceSafe Admin|
|3||In Visual InterDev, add a Web project to source control.||Visual Interdev|
Installing Visual SourceSafe
To install Visual SourceSafe on the same Web server running IIS:
- Run the Visual SourceSafe setup program.
- In the Setup wizard, choose Custom and select at least the following components:
- Create SourceSafe Database.
- Administrative Programs.
- Enable Visual Studio Integration.
To install Visual SourceSafe on a separate server:
After you've installed Visual SourceSafe on a Web server, you must grant read/write permissions to all users whom you want to be able to author files using Visual InterDev or FrontPage.
To grant permissions to a user:
In addition to granting read/write permissions to specific users, if you have installed Visual SourceSafe on a Windows NT server, you must also add permissions for the anonymous user account.
To add permissions for the anonymous user account:
When Visual SourceSafe tracks changes, it uses the operating system to identify and record who made the changes.Certain operating systems can only recognize and record the anonymous user name for changes. If your Web server is running Windows 95, or Windows NT using the File Allocation Tables (FAT) file system, then all files checked out through Visual SourceSafe will always be checked out to the same user account. This user account might not represent the user performing the operation. On a Windows NT FAT system, the anonymous user account performs all source control operations on the server. On a Windows 95 system, the user account specified when Windows 95 was started performs all source control operations on the server.
Enabling Source Control
Once you've installed and set up Visual SourceSafe, you can enable source control for your Web pages using any Web project that references those pages. Only one developer needs to enable source control for the application.
To enable source control for Web pages:
- In Visual InterDev, open or create a Web project that refers the Web pages you want to place under source control.
- In the Project Explorer, select the project you want to use with source control.
- From the Project menu, select Source Control, and choose Add to Source Control.
- In the Enable Source Control dialog box, verify that the project name is the one you want for the Source Control Project, and then click OK.
Note: It's recommended that you use a different name than that of the Visual InterDev project such as $/MyWebApplication_Web. The name must be preceded by the dollar sign ($) and forward slash (/).
After a developer has enabled source control for Web pages, other developers with open projects that refer the Web pages must either refresh or reopen their Web projects for source control to take effect on their projects.
How FrontPage and Visual InterDev Work with Visual SourceSafe
The FrontPage Server Extensions use OLE automation to connect to and interact with Visual SourceSafe. All Visual SourceSafe operations are performed by FrontPage Server Extensions on the Web server itself, not client machines. The Web server can be Internet Information Server (IIS) or Personal Web Server using the DCOM extensions.
Permissions to the Visual SourceSafe Directory Structure
To view Directory permissions, right-click the Directory in the Windows NT Explorer, click Properties, click the Security tab, and then click Permissions. To view Share permissions, right-click the shared Directory in the Windows NT Explorer, click Properties, click the Sharing tab, and then click Permissions.
Assign "CHANGE" permissions to all Visual SourceSafe logon accounts for all files and subdirectories under the Visual SourceSafe server installation directory.
It is assumed that the Administrators and System accounts will be granted full control to the entire Visual SourceSafe directory hierarchy. Although tighter file restrictions might be possible, full Visual SourceSafe functionality might be jeopardized by tighter restriction.
Accounts in the Visual SourceSafe Administrator
Add the actual FrontPage or Visual InterDev user(s) (password optional). Under the Tools menu, click Options, click the General tab, and make sure that "Use network name for automatic user log in" is selected.
The Anonymous Account (if applicable)
Do the following on the computer running IIS:
- Ensure that the anonymous account has Log on Locally privileges. Use the following steps to do this:
- Run the User Manager For Domains.
- On the Web server machine, select "User Rights..." from the Policies menu.
- From the right drop-down list, select "Log on locally." Make sure that the anonymous account is listed either individually or as a member of one of the groups.
- Check that the anonymous account has the same password in both IIS Service Manager and User Manager for Domains. You might have to re-enter the password in both these places. The following are two potential pitfalls:
- In User Manager for Domains the password always appears padded out to 14 characters. This can be confusing if you have entered a shorter password.
- After changing the password in IIS you should stop and restart the service to clear out any password caching.
Trouble-Shooting Integration of Visual SourceSafe and Visual Interdev
Error: Source Control System failure: User <USERNAME> not found
Cause: The user
<USERNAME> has not been added to the Visual SourceSafe database.
The default database used by VID to add a project is the Common Database. The Anonymous User (
IUSR_<MACHINENAME>) was not added to this common VSS database and so the above error.
Resolution: Add Anonymous User to VSS common database with read/write access and no password. Ensure that Anonymous user is not part of the Admin group.
Error: FAT Partition Vs NTFS
The Web server used for this integration was partitioned using File Allocation Tables (FAT) and not NTFS. The files therefore appeared to be checked out or modified by the system's anonymous user when they were actually checked out to valid SourceSafe accounts.
Resolution: Convert the partition from FAT to NTFS and set appropriate web server permissions. On the web server to convert, use the following at the dos prompt:
CONVERT [driveletter]: /FS:NTFS
Refer to MSDN article Q214579.
Error: Permission settings
IUSR_<MACHINENAME> account is the anonymous user account that Internet Information Server uses when someone browses to the Web server anonymously. That account should only have browse permissions as far as the Web permissions go and that's through the Everyone group.
By default, the Everyone group will have browser permissions and that's how it should be basically so that they can read the files. If the IUSR account has author or administer permissions, you'll start running into problems with files being checked in and out by the IUSR account rather than by the developer that you expect them to be checked in and out by.
On the VSS file share, you'll need Change permissions. And this isn't always the case, but sometimes you'll find that the IUSR account needs those permissions just to be able to contact the VSS Admin database. The account that you'll have to look at is a user that's developing on a project that's already been added to source control. And basically that person is connecting to an existing project, creating files, checking files in and out of SourceSafe. That person needs Author and Browse permission in the Web permissions, also needs Change permission on the VSS file share (and that's an absolute requirement), and that person needs to have an account in the SourceSafe database under VSS Admin. It can have a password or not. Generally most people leave it with a blank password because you're already going through the security either NTLM or basic authentication to IIS and through the Web permissions of the FrontPage Server Extensions. The last scenario is a user creating a new project or adding an existing project to source control that's not already added to source control. And really, the only additional permission that user needs is the Administer permissions on the Web permissions so that they have basically permissions to make changes to the project as a whole.
Error: Visual InterDev Projects Do Not Appear or Are Added to Wrong VSS Database
This sometimes happens when Visual SourceSafe is installed during the Visual Studio setup, which provides two distinct setup opportunities. The option to install Visual SourceSafe occurs both in the Client and Server portions of the installation of Visual Studio 6.0. The two installations are slightly different, and install to different paths.
The Visual SourceSafe installation in the server portion of Visual Studio setup installs Visual SourceSafe Server into \Program Files\Microsoft Visual Studio\VSS. This version contains tools for setting up Source Control on remote computers that utilize a centralized Visual SourceSafe database. The Visual SourceSafe installation from the client portion of Visual Studio setup installs to \Program Files\Microsoft Visual Studio\Common\VSS. This version of Visual SourceSafe is intended for developers to use locally on their computers and does not have the support to set up remote computers to utilize this Visual SourceSafe database, specifically Netsetup.exe support. When Visual InterDev is used to put a Web project under Source Control, it makes requests to the FrontPage Server Extensions (FPSE) to check files in to and out of Source Control on the users' behalf. The FrontPage Server Extensions attempt to locate a Visual SourceSafe database they can use by searching the registry for the location of Ssapi.dll. Since both installations of Visual SourceSafe install and register this DLL, the setup program that was run last is the DLL that is found. The server extensions then move up one folder and read the contents of the Srcsafe.ini file for detailed information on implementing Visual SourceSafe. Note that this activity occurs on the Web server and not on the client where Visual InterDev is installed.
Resolution: Look in the two paths cited above, or search the hard disk drive for multiple versions of the Ssapi.dll. Uninstall multiple copies of Visual SourceSafe, and reinstall the version that you want to use. The Server version of Visual SourceSafe can be uninstalled from the Add/Remove control panel. The Client version of Visual SourceSafe can be uninstalled by running the Visual Studio Setup program. Choose Workstation Tools and Components, and then cancel the Visual SourceSafe selection in the Add/Remove section. If you require multiple Visual SourceSafe databases on the Web server and the FPSE do not find the database you want, you can either reinstall the version of Visual SourceSafe you want the FPSE to use, or you can manually register \VSS\Win32\SSAPI.dll for the appropriate installation of Visual SourceSafe for the FPSE to use.
To register the DLL manually, click Start, Run and type:
regsvr32 <full path to dll>\ssapi.dll
You should receive a success dialog box if the DLL is registered correctly.