Use Visual Studio .NET in a team development environment

xiaoxiao2021-03-06  91

Mark White comes 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. Directory Introduction Settings File Sharing Access Mode Creating an item in Visual SourceSafe From Visual SourceSafe Access Project Modifying File Announcement Change Get The latest version Offline Work Tips And Tips Visual Studio .NET Beta 2 Problem summary Introduction In Microsoft® Visual Studio® .NET The recommended method for performing a web application team in 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. Settings File Sharing Access Mode As described 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. Creating a project in Visual SourceSafe creates a solution to 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: The File Sharing Warning dialog can ignore the warning. 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 final release of Visual SourceSafe 6.0c will open the dialog and set it to the default settings.) To avoid this problem, please " 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: Adding a project to Visual SourceSafe This will also be 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: Try to add the same file to the Visual SourceSafe project The warning dialog box appears Click "Select Different Location" and then continues as described above. 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 the check-out form, but the file is not in Visual SourceSafe. in. 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. When each team member accessing the project from the Visual SourceSafe access project from the Visual Source Safe, you must do the following: On the File menu, click Source Control, 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 / / My Documents / Visual Studio Projects. You can re-configure the following: On the Tools menu, click Options, click "Environment", and then click Projects and Solutions. 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 Solution File This time, if the solution contains one or more file sharing web projects, the "SET Project Location" dialog is displayed. Figure 6: The "SET Project Location" dialog box 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 you open the solution.

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. Modifying the 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 of changes need to be changed, test, and debug the source code to the team members. 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 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 of 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 Status 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: Connecting and disconnecting the solution The connection "Connected" checkbox with the Visual SourceSafe can make the solution and item 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. Checking the file offline can usually check out the files in a way offline. When you check out the file in the offline operation, the following dialog is displayed: Figure 8: Checking the file when disconnecting the file needs to cancel this dialog (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 displayed when the first check-out file is disconnected next time, attempting to check out the files in the offline operation. 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.

Checking in the file offline is not possible 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. Entering the online status This is basically the same as that enters 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 changes To make changes made when you work offline with the solutions and project files contained in the Visual SourceSafe database, you need to check out each file check out when you check out from the Visual SourceSafe and will change the file. A copy of the Visual SourceSafe. After entering the online state, the following two dialogs are displayed on the offline state: Figure 10: Coordinating the file check out in the connection state, first, click "Check Out" (Figure 10) Indicated). Figure 11: Select "Leave this file?" From the Visual SourceSafe check-out file to prevent your modification from overwritten by the version contained in the 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 at offline, another user also checks out the same file, then the following dialog box is displayed when you connect the solution and project online: Figure 12: Attempt to check out the check out The warning displayed when the file is displayed 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. Probably all developers with tricks URL are best to use 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 within the web.config file, and use it to define the application's custom settings. If you are using a web reference, place the web service locally and use http: // localhost / webserviceName as a web reference, or set the web reference URL behavior to dynamic. Dynamic URL behavior will be described later. The reference path is unanimously added to a non-system assembly, and the IDE copies the assembly local 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. In this way, as long as the following conditions are met, other developers have no operations for the solution or project files after adding a reference to the resolution:

The reference path has been set, and the assembly for each item is required to set up a reference that exists on the hard disk, and the location correctly the method requires defining a standard generated output location and enables all references to reference the programs in this location. set. If this condition is too strict, multiple paths separated by commas can be included in the reference path. Adding a web reference 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" to add a web reference, the web service URL is hardcodes 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 .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". The problem project files in Visual Studio .NET Beta 2 are automatically checked out when the project file needs to make changes. 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. Multi-Solutions Projects Although Visual SourceSafe integration support uses items 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. There are many problems that need to be paid off when the work is 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. Deleting references 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. Generating 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. Summarizing the team working characteristics in Visual Studio .NET Beta 2 is 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.

转载请注明原文地址:https://www.9cbs.com/read-106042.html

New Post(0)