Mark White from Microsoft Corporation
Summary:
This article provides guidance on how to use Visual Studio .NET Beta 2 in a team development environment. This article assumes that the same project needs to be developed by multiple developers, and they use the Visual SourceSafe to source control.
table of Contents
Introduction Settings File Sharing Access Mode Creating an item in Visual SourceSafe From Visual SourceSafe Access Project Modify File Announcement Change Get The latest version Offline Work Tips and Tips Visual Studio .NET Beta 2 Problem Summary
Introduction
The recommended method for WEB application team development in Microsoft® Visual Studio® .NET Beta 2 is based on "File Sharing" access mode. Each developer uses a copy of the file in the virtual root directory, but all users need to check and check out files from the Central Microsoft® Visual SourceSafe® project. This method has an isolation function to prevent changes in a team member from affecting the work of the entire team.
The method is different from the method adopted by Microsoft® Visual InterDev® 6.0, which uses Microsoft® FrontPage® Web Access. File Sharing Web Access is the default access mode of Visual Studio .NET Beta 2 and is recommended in team development.
Visual SourceSafe integrates the way to work together with Visual Studio .NET and it works with Visual Studio 6.0, Microsoft® Visual C ® and Microsoft® Visual Basic® projects. Developers can create their own projects locally (if using http: // localhost) and check out from a public Visual SourceSafe project. This is also different from Visual Interdev 6.0, which requires all the developers of the team to work in the same virtual root directory of the central server.
The discussion in this article is an example of the development of web applications, but this method also applies to developing non-web applications in Visual Studio .NET Beta 2.
Note that the application is appropriately divided into multiple independent projects and using ASP.NET user control, HTTP modules, and class libraries are effective ways to work in teamwork.
Set file sharing access mode
As mentioned above, in Visual Studio .NET Beta 2, file sharing is the default access mode. To confirm that the settings of the access mode are correct, click Options on the Tools menu, click "Projects", click "Web Settings". Then set the "preferred" access mode to "File Share", then click OK. Such a Web project can be added to Visual SourceSafe.
If the existing project uses FrontPage Access Mode, you can change the access mode to "File Sharing". Please open Solution Explorer, right-click the project, and then click Properties. Click "Common Properties" and click Web Settings. Set "Web Access Mode" to "File Share" and click OK. Now, please save, close and reopen the solution, make the changes to the project set into effect.
The rear section of this article assumes that you are using the File Sharing Access Mode.
Create a project within Visual SourceSafe
The first team member creates a solution that contains one or more items. (Due to the use of file sharing access, if you want to create a project on other computers, you still have to specify the project location as http: // myserver, but you need to access // myServer / C $ via General Naming Answers (UNC) / inetpub / wwwroot or // myserver / wwwroot $.) Solution is ready, the first team member should right-click the solution or project file in the Solution Explorer to right-click the solution or project file in Solution Explorer, then select "Add Solution To Source Control". In addition, the first team member can also click "Source Control" on the "File" menu, and then click Add Solution To Source Control. If the solution contains a web project using a file sharing access mode, the following warning will appear.
Figure 1: File Sharing Warning Dialog
This warning can be ignored. Click "Continue".
The Integrated Development Environment (IDE) will prompt you to specify the Visual SourceSafe database server and then ask you to specify where you want to store the solution files and the various items of the solution in the Visual SourceSafe.
The default behavior within Visual Studio .NET is to log in to the default Visual SourceSafe database as "admin user" (usually called "public"). The default user name and password are provided by Visual SourceSafe. Since the default admin user password is empty, you may not prompt you to specify the Visual SourceSafe database server when you add a solution to Visual SourceSafe, and you may automatically log in to the default Visual SourceSafe database and display "Add to SourceSafe Project" Dialog. By default, the login dialog will be displayed. (Visual SourceSafe, including version 6.0C beta, close the login dialog. The last release of Visual SourceSafe 6.0c will open the dialog and set it to the default settings.)
To avoid this problem, on the Tools menu, click Options, click Source Control, and then click SCC Provider. Change the login ID to the appropriate user. Click Advanced and click the Integration tab. Under "Choose SourceSafe Database", select "PROMPT".
Figure 2: Add item to Visual SourceSafe
In addition, the same dialog is also prompted to specify the Visual SourceSafe location for each item included in the solution. To reset, when prompted, you can set a Visual SourceSafe location for all non-Web projects on the same drive on the same drive. Next, you will be prompted to provide each web project in the solution for Visual SourceSafe. If you don't want to add a project to Visual SourceSafe, click Cancel and use "Add Selected Projects to Source Control" that controls the item to be added. This article will be added to the source code control later later. Solution Explorer displays the canceled item as a checkout, but the project file is not in Visual SourceSafe. In this case, the check-out identifier will be used to indicate that the item is not added to the Visual SourceSafe. When setting up a Visual SourceSafe location, you can place the solution file and item to the same Visual SourceSafe folder or multiple separate folders. It is best to let Visual Studio.net control all your non-Web projects. However, each Web project should be placed in their respective folders to ensure that the project is not conflicting with other Web projects. It is likely that several items will contain the same name file (for example, WebForm1.aspx). If you try to place multiple items in the same Visual SourceSafe folder, and the same name files are existing in the folder, the following dialogs appear, as shown in Figure 3:
Figure 3: Warning dialog that is trying to add the same file to the Visual SourceSafe project
Click Select Different Location and continue to operate as previously described.
If you want to add a new project in a solution that has been added to the Visual SourceSafe or existing projects within Visual SourceSafe, add your project to the solution. Then, right-click the solution in Solution Explorer and do one of the following:
Click "Add", then click New Project ... "or click" Add ", then click" EXISTING PROJECT ... "
Solution Explorer will display the item in a check-out, but the file is not in Visual SourceSafe. Now select the item in Solution Explorer and on the File menu, click Source Control. Finally, click "Add Selected Projects to Source Control ...", which will ask you to store the location of the project in the Visual SourceSafe, as mentioned earlier. For non-Web projects, it is best to use the "Check IN" command under the "File" menu by Visual SourceSafe location by Visual Studio.net.
Access from Visual SourceSafe
Each team member must be performed as follows from the Visual Source Safe to access the project, on the File menu, click Source Control, and then click Open Project from Source Control.
IDE will prompt the team member to specify the Visual SourceSafe database server and ask the team member to select the Visual SourceSafe project, and specify the local folder to copy the solution file and all non-Web projects. In my sample screen (Figure 4), I have opened myWebProjects and saved the solution file to D: / Documents and Settings / Marwhite / My Documents / Visual Studio Projects. Figure 4: Setting the local folder location of the Visual SourceSafe project
By default, the solution file will be copied to the C: / Documents and Settings /
If the solution files are stored in multiple separate folders, the following dialogs are not displayed in multiple separate folders. However, if the solution and project file is stored in the same Visual SourceSafe location, the IDE prompts the user to select the solution file.
Figure 5: Select the solution file
At this point, if the solution contains one or more file sharing web projects, the "SET Project Location" dialog is displayed.
Figure 6: "SET Project Location" dialog
You must use this dialog for each web project to specify the location of each individual website. You can place the web project on one server. For example: http: // myserver / myProject_myroot. Or, place the web project to your local computer. For example: http: // localhost / myproject. Visual Studio will create a virtual root directory for each independent web project.
Note: As mentioned earlier, just access the solution at the first time. (On the File menu, click Source Control, and then click Open Project from Source Control.) The solution file on the local disk is required for the next time. Please do not open the application from the web server or Visual SourceSafe.
If you want to add an existing project in Visual SourceSafe to a solution, do the following: On the File menu, click Source Control, then click Add Project from Source Control ..., IDE Displays the dialog as previously described.
Modify file
When team members handle their own code, their work is exactly the same as the usual work. When modifying the file, the development environment will automatically prompt team members to check out. Note that you need to check out the project file in your project.
Announcement
You need to make changes, test, and debug the source code to the team members of the team. Once the change is complete, you can select the file, right-click, click "Check IN", or on the File menu, click Source Control, and then click "Check IN". These changes are then displayed in Visual SourceSafe.
Get the latest version
Team members have to get the latest changes to the team, select the solution file in Solution Explorer, right-click, and then click Get Latest Version (Recursive). Team members need to execute the process when they need to generate the latest version of the application. Offline work
Visual Studio .NET Beta 2 is one of the major improvements to Visual Studio .Net Beta 1 is offline work. Offline work is very important for many developers, especially for most of the time and / or developers in the office.
Offline work allows team members to set up solutions and projects integrated with Visual SourceSafe. That is, team members can process files when connecting to their own corporate networks and Visual SourceSafe database. When team members return to the office, you can reconnect the solutions and projects, and the IDE keeps its copy between changes between the copies reserved in the Visual SourceSafe database.
Enter offline
To make the solution and its item offline, on the File menu, click Source Control, and then click Change Source Control .... IDE will display the following dialog:
Figure 7: Connections between connection and disconnection solutions and Visual SourceSafe
Clear the "Connected" checkbox to make the solutions and items offline.
Please note that the files you have signed out before the offline will remain check out for you. To avoid possible data loss, it is best to check out files to be processed offline before the offline.
Check out the file offline
When working offline, you can usually check out files. When you check out the file in the offline working state, the following dialog is displayed:
Figure 8: Check out the file when disconnected
This dialog is required (in Figure 8) to enable offline checkout. Please select "Don't Show this Dialog Again" and click "Check Out (Disconnected". Another error dialog as shown in Figure 9 will be displayed. This dialog can be ignored; click OK.
Figure 9: Error dialog box displayed when checking the file in the connection state
The next time I tried to check out the file in the offline working state. Note that the other error dialogs described above are small errors in Visual Studio .NET Beta 2, which will be resolved in the final version.
When the team member checks out the file in the offline state, the detailed information of the signed file will be stored as part of the project, and the signed file will be marked as read / write.
Check the file offline
It is impossible to check into the file offline; because you are not connected to the network, the check-in command is not enabled. This is intentionally set, so that it can be easily viewed when the project is re-online.
Enter online status
This is basically the same as the entry offline. To enable the solution and its project online, on the File menu, click Source Control, and then click Change Source Control .... The displayed dialog is the same as when entering the offline. Select "Connected" to enable the solution and project online.
Synchronous change
To synchronize the changes you made when the offline work is made with the solution and project files contained in the Visual SourceSafe database, you need to check out each file check out at the offline work from the Visual SourceSafe and change the file copy sigrase. Enter Visual SourceSafe.
After entering the online state, the following two dialogs are displayed for each file check out in the offline state:
Figure 10: Coordinating the files checked out in the connection state
First, click "Check Out" (as shown in Figure 10).
Figure 11: Check out the file from Visual SourceSafe
Select "Leave this file?" Prevents your modification from overwritten by the version contained in Visual SourceSafe. Then you need to check into the file you modified.
WARNING: If someone checks into this file, then you have signed the same file, it will overwrite the changes made by others.
Note: These dialogs are only displayed on files you checked out in a offline state without files that have been checked out before entering the offline state. Practice warnings, as indicated by the first dialog, may lose data.
When you work offline, if you check out a file, and another team member also checks out, modify and check into the same file, you must be very cautious, otherwise your signing will overwrite the modification of the team member. The safest choice is to avoid offline file check out. Always check out the file you want to process before offline. If you can't do this, or you forgot to check out all the files to be processed prior to offline, manually merge files when you change.
If you check out a file while working offline, and another user has checked out the same file, then the following dialog box is displayed when you connect the solution and the project:
Figure 12: Warnings displayed when trying to check out the signed file
Click OK. In Solution Explorer, this file will display a small warning symbol, indicating that the file still needs attention.
Finally, if you add a file to the project in offline, you can only check the new file to check into Visual SourceSafe.
Tips and skills
URL
All developers are best to use a unified virtual root directory, such as http: // localhost / projectname. Try to avoid using a specific server name because this may make the user difficult to share project files. If you need to use a specific server name, define a new
Reference path
When the reference is added to a non-system assembly, the IDE copies the assembly locally to the project (for web applications, the assembly will be copied to the bin directory). To control if the assembly is copied locally, right-click the assembly, then click Properties. For non-system assemblies, "Copy Local" should be set to "True". This is the default value, it is recommended to use in most cases.
When adding a reference, IDE will update the reference path within the user project file to indicate the actual location of the assembly. Right-click the project and click "Properties". Click "Common Properties" and click "References Paths". In the dialog box (as shown in Figure 13), click "Cancel".
Figure 13: Display reference path
Although the reference path is displayed as an attribute of the project, it is actually unique to items, computers, and users set up this property. This means that if the developer 1 adds the reference to the assembly and check into the project file, the program set will be displayed in Solution Explorer when developers 2 get the latest version of the project file, but it is likely to be Failure because developer 2 may not have the same reference path.
To avoid this problem, all teams' developers should use a unified reference path within the team. Thus, as long as the following conditions are met, other developers have no need to do anything about the solution or project file after adding a reference: The reference path has been set, and the setup of each project task is required to set up a quote set. On the hard disk, and the location is correct
This method requires defining a standard generated output location and enables all references to reference the assemblies within that location. If this condition is too strict, multiple paths separated by commas can be included in the reference path.
Add a web reference
This is also one of the improvements of Visual Studio .NET Beta 2 relative to Visual Studio .NET Beta 1.
There is a Web References folder in the folder where your project is located. When you add a web reference, create a new folder under the Web References folder. The new folder names the server that hosts the web service and contains WSDL, DISCO, and the generated Web service client agent. This folder name is also used as the namespace of the web service client agent.
These folders and files will be added to the Visual SourceSafe project when adding a web reference. When updating the web reference, you will also check, update, and check into these files. (Right-click the Web reference, and then click Update Web Referemce.)
When adding a web reference, the web service URL is hard to encode within the Web service client agent. However, you can change the behavior of the web service client agent to read the web service URL from the .config file. Right-click the Web reference, click "Properties" and change "URL Behavior" from "Static" to "Dynamic".
Figure 14: Web reference attribute
The following code will be added to the .config file:
Value = "http://localhost/webservicetest/service1.asmx" /> The constructor of the web service client agent is also modified to read the web service URL from the .config file. One problem that needs to be aware is that two web references pointing to the same server cannot be added, but pointing to different web services. This is because IDE will try to create another web reference with the existing folder name. See the above for explaining how Web references in the file system. However, this is just a small problem. Simply rename the folder as the name of the actual service instead of retaining its name (and namespace name) to reserve the name of the server hosting the web service. Right click on the Web reference, click "Properties" and change "Folder Name". Problems in Visual Studio .NET Beta 2 Project file checkout The project file will be automatically checked out when the project needs to be changed. This will happen when adding a file to a project or change item settings. However, project documents will not be checked in after modification. In some cases, unnecessary project file check out behavior occurs during the generation process and editing form. These are known errors and should be solved in the final version. The end result is that this may lead to team developers to compete for project documents. If the team members have conflicts in the project file check out, they may need to switch to the shared checkout. Note that the special! Identifier symbols in Solution Explorer indicates that you have checked out the project file in an exclusive way. Project in multi-solution Although Visual SourceSafe integration supports the project for multiple solutions, there is still an error. When using Visual Studio .NET Beta 2, it is best to be careful and make sure that each project belongs to a solution. Offline work There are many questions that need to be paid off when working offline. The most important issue is to cancel the warning dialog box to successfully check out the files at the time of working offline. This issue and other issues have been described above. The project is not in Visual SourceSafe This may be a small problem, but if your project is not in Visual SourceSafe, and the solution is in Visual SourceSafe, Solution Explorer will display the project and its files as a checkout, even if they are not in Visual SourceSafe. The identifier that can be considered indicating "local changes" or not added to Visual SourceSafe. The signing command adds the project file to the Visual SourceSafe. Delete reference This may also be a small problem, but if you delete a reference to a non-system assembly, IDE will not update the reference path within the user project file. Even if you no longer collect the assembly, the actual location of the assembly remains within the reference path. Generate multi-project solutions By default, each project should generate to your own output directory. Typically, the project will generate to bin / debug or bin / release subdirectory. Do not support multiple items in a solution into the same directory. For any reference in the same solution (ie, the project generated by other items referenced in the same solution), "Copy Local" should be retained as the default value TRUE. This applies to both the assembly reference and is also applicable to references between projects. to sum up The team working characteristics in Visual Studio .NET Beta 2 are a major improvement relative to Visual Studio .NET Beta 1. Now all the core programs work, and most of them have fun. Although there is still a need to solve some small errors before publishing, Visual SourceSafe integration and IDE changes still brings improved team development experience. Project files and source code files can now be easily shared between developers and make it easier to move applications from the development environment to test and product environments.
