1. DEV232 Source Control and Team Development Using Visual Studio.NET and Visual SourceSafe Alfredo Méndez Program Manager Microsoft Corporation

2. Overview Agenda Team Development Tips SourceSafe Best Practices Changes in Visual Studio.NET 2003 Summary and Discussion Recommendations Not one-size-fits all

3. Only one developer can debug a server host Web application (or Web service) at a time Takes too long for each developer to compile and build entire team’s codebase References work on one developer’s machine, but not another Difficult to match binary assemblies to source code files used to build them TIP: Use Assembly Versions…and SourceSafe labels Difficulty Working In Teams With Visual Studio.NET and SourceSafe [assembly: AssemblyVersion("1.0.1001.1")]

4. Unit UnitTest Test Team Development Process High-level Lifecycle Business Need or New Idea GatherRequirements TestSystemRelease and Deploy Implement and Develop Implement Implement Implement Implement Repeatable & ReliableFast Multiple Check-outs, Multiple Solution Files Analyze and Architect

5. Team Development Tips Being Repeatable, Reliable, and Fast Set up a Team Environment Dedicate Team Hardware Resources Choose a Web Development Model Structure and Name Your Sources Solutions and Projects Manage Dependencies Multiple Solutions Create A Build Process – BuildIt.NET

6. Test Team Issue Tracking Test Process Test Results Build Process Build Output Get Latest BuildIt.NET Set Up A Team Environment Development Team Team Reference Development Process Admin Team MSI Package Check In, Get GetSourceSafeServer Deployment Process Release Process Web Services Server References Build Server Database Server

7. Dedicate Server Hardware Recommendations CPUMemoryHard disk BuildPIII-class 660 MHz 96-192 MB*600 MB sys 3 GB install SourceSafe Pentium-class 333MHz 32-256 MB (32MB min) 4-10 GB (2x db size) TIP: Minimize network latency for speed DatabaseSQL Server 2000 Enterprise Edition with appropriate requirements Web Service Windows 2000, XP, or Server 2003 Internet Information Services (IIS) 5 or 6 NTFS file system is recommended *Varies by OS (Window NT 4, Windows 2000, XP, 2003 Server)

8. Choose A Web Model VSS Developer 1 Web Application Developer 2 Web Application Visual Studio.NET Isolated / Local Host Common Web Server Web Application VSS Developer 1 Visual Studio.NET Developer 2 Visual Studio.NET Common Web Server VSS Developer 1 Visual Studio.NET Web Application Developer 2 Visual Studio.NET Semi-Isolated / Server Host Non-Isolated / Front Page Recommended Recommended

9. Web Development Models IsolatedSemi-IsolatedNon-Isolated Typical accesshttp://localhosthttp://server SourceSafe accessFile Share FrontPage UNC access neededYes No Can work isolatedYes No Offline supportYes Limited Dedicated serverNoYes Web referencesAutomaticUse user.configAutomatic Server debuggingAutomatic1 Session per machine RecommendationsPreferredServer Resources Compatible Recommended Recommended

10. Projects (.csproj,.vbproj, etc.) Build and configuration settings for assembly Web projects – created with an HTTP location http://localhost/MyWebProject Non-Web, local projects – file system location c :\Projects\MySystem\MySolution\MyWinProject Structure And Name Projects And Solutions Solution files (.sln) Groups related projects together Contains project dependency information used by the build process for build order Dependencies Solution Project A Project B Project C

11. Manage Dependencies Files and Project References Use project references where possible Work great with source control References to paths are user-specific Each user will need to set their path up before they build the first time To refer to a non-built or third-party dll, consider putting it on a shared folder and set the CopyLocal property = TRUE

12. Manage Dependencies Web References Web references to external services work fine Web references to Webs within the solution require management http://localhosthttp://localhost users Need to ensure all their local projects are in the same place http://serverhttp://server users Need to make their references ‘dynamic’ Each team member must have a user.config file that resolves the reference for them

13. Proj1 Create Multiple Solutions c:\Projects Single Solution Solution1 Solution1.sln Proj1.csproj Master Solution Multi-Solution Web1 Web1.vbproj Proj1 c:\Projects Solution1 Solution1.sln Proj1.csproj Proj1 c:\Projects Solution1 Solution1.sln Proj1.csproj Solution2 Solution2.sln Recommended Recommended Web1 Web1.vbproj Solution2 Solution2.sln Web1 Web1.vbproj Patterns & Practices

14. ..\Visual Studio Projects C:\Projects Local Structure MySolution ClientProject1 Bin WebAppProject2 Bin C:\inetpub\wwwroot $/Projects SourceSafe Structure MySolution.root MySolution ClientProject1 WebAppProject2.sln Solution default \My Documents\Visual Studio Projects Web projects default usually \inetpub\wwwroot Alter this default structure for a team environment Visual Studio.NET 2003 will restructure VSS folders – adding “.root” Create A Common Folder Structure Use the same local structure for all developers

15. Create Naming Conventions Carefully consider projects, assemblies, folders, and namespaces Output assemblies match project name Utilities.Data.csproj  Utilities.Data.dll Assembly root namespace = project and assembly name Use same names for SourceSafe folders and local folders Change and delete with caution from Visual Studio.NET

16. Create A Build Process Using BuildIt.NET Critical element for all team development Configure a build server as soon as possible Build scripts are key for repeatability Build scripts use the SourceSafe automation model or command line Download the code to the build machine Check-in an updated version info file Create a label to match sources with outputs Build scripts compile by executing Microsoft Visual Studio.NET (devenv.exe) from the command line Source code available, so it’s fully customizable

17. Steps In The Build Script Generate build number Label Sources & Retrieve & Retrieve Create Backup & Archive & Archive Errors? Devenv.exe & copy to \Latest Debug & Release Yes Send e-mail with error log Rename \Latest to \Broken Fix broken build UpdateBuildNumber.xml Send e-mail Delete Backup Copy \Latest to numbered folder No c:\BuildLab Sources Latest Archive 1 2 Debug Release Debug Release Success!

18. BuildIt.NET Alfredo Méndez Program Manager Visual Studio Core Team demo demo

19. SourceSafe Best Practices And Tips For Team Development

20. Files And Source Control Visual Studio.NET extensions Source-Controlled Solution.sln Project.vbproj,.csproj App Configweb.config, app.config Source Files.cpp,.cs,.vb,.aspx,.asax,.resx,.css,.h,.vsdisco,.idl Hint Files.vssscc,.vspscc, ~sak*.sln ~sak*.vbproj, ~sak*.vsproj Not Source-Controlled User Options.suo User Options.vbproj.user,.csproj.user Web info.vbproj.webinfo,. csproj.webinfo Build outputs.idl .h, many others… Hint Filesmssccprj.scc, vssver.scc There are many files…

21. …Don’t Worry About Those Files! Use Visual Studio.NET and it’s automatic! Always use Visual Studio.NET for source control Only the appropriate files are added to source control Paired files are matched automatically Example: Form1.vb and Form1.resx Visual Studio.NET project and solution files are updated with appropriate SCC-specific details A count of projects in the solution that are under source-control (this count includes the solution itself) SourceSafe server for each project Location on the server for each project Name of each project’s source-control provider Each project's location relative to the solution file TIP: Create a blank solution first, then add projects

22. Installing Visual SourceSafe SourceSafe not installed by default with Visual Studio.NET Install on server before installing client software Avoid NetSetup – it makes non-shareable connections Use SourceSafe 6.0d for all users – do not mix-and-match Secure the default database and the administration tools Don’t create databases under the \Program Files folder Use the 6.0 format when creating databases (faster) Creating SourceSafe Databases Use separate databases for independent efforts More precise control over user access, policy for projects Maintenance and repair will affect a smaller group of users Can easily archive the project’s database when project ends Note: Single databases over 5GB in size perform poorly Use shareable connections like \\machine\vss\srcsafe.ini

23. Securing SourceSafe Databases Use Windows Groups: all developers, plus ‘buildlab’ Windows sharing permissions: remove ‘Everyone’ SourceSafe Admin: remove ‘Destroy’ rights Create SourceSafe accounts for each user and the build script SourceSafe user names should match the domain user names Enable the ‘Use network name for automatic user login’ option Use different passwords for SourceSafe and Windows Create a SourceSafe Administrators Group to secure Vss\Win32 Dealing with Data Corruption Use ‘Analyze’ once each week Have all users log off SourceSafe before ‘Analyze -F’ Consider a fault-tolerant system such as RAID Create tape backups of the SourceSafe database disk volume Minimize use of unreliable network connections like RAS

24. SourceSafe Shadow Folders Creates a directory on a central server Mirrors latest contents of a SourceSafe project folder Check-ins will auto-update the shadow Shadow folders increase check-in time Use with caution Disable to improve performance Ideal for Read-only users Users who check-in will need write permissions to the shadow directory

25. Changes In Visual Studio.NET 2003 What’s New?

26. Visual Studio.NET 2003 And Visual SourceSafe 6.0d Reduced prompting and creation of a “.root” folder in SourceSafe when adding to source control Elimination of temporary files (~sak) that perform a capabilities test Additional guidance on securing your database Other issues identified in KB 820831 [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl] "DoNotCreateSolutionRootFolderInSourceControl"=dword:00000001 "DoNotCreateSolutionRootFolderInSourceControl"=dword:00000001 [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl] "DoNotCreateTemporaryFilesInSourceControl"=dword:00000001 "DoNotCreateTemporaryFilesInSourceControl"=dword:00000001

27. Summary And Discussion Closing thoughts

28. Summary To be fast and maximize repeatability and reliability in teams… Use automated builds in your process Customize BuildIt.NET Dedicate hardware to builds, SourceSafe Use the isolated Web model Spend time defining your project and solution structures Make backups of SourceSafe disk volumes Use several SourceSafe databases

29. Ask The Experts Get Your Questions Answered I will be available at the “Ask The Experts” area the following times: Wed & Thu – 12:00 to 13:00 Friday – 12:00 to 14:00

30. Community Resources http://msdn.microsoft.com/ssafe Community Resources http://www.microsoft.com/communities/default.mspx Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx microsoft.public.visual.sourcesafe microsoft.public.visualsourcesafe microsoft.public.vsnet.vss microsoft.public.sourcesafe microsoft.public.vs.net.ide User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

31. Suggested Reading & Resources Team Development with Visual Studio.NET and Visual SourceSafe http://msdn.microsoft.com/library/en-us/dnbda/html/ tdlg_rm.asp BuildIt.NET http://msdn.microsoft.com/library/en-us/dnbda/html/ tdlg_app.asp Web Projects and Source Control Integration in Visual Studio.NET http://msdn.microsoft.com/library/en-us/dv_vstechart/ html/vetchWebProjectsSourceControlIntegrationInVisualStudi oNET.asp

32. evaluations evaluations

33. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

34. Backup Slides…

35. Team Domain Infrastructure Developer Workstations Dev Test SQL Servers Web Servers Dev Test 100MB Ethernet Stress Hub Stress Test Environmen t 100MB Ethernet DCBuildBackup VSS MSDN VSS Shadow

36. Isolated Development Advantages Local instances of Web application Can debug without interfering with one another Superior support for source-code control* Slightly faster in a local area network (LAN)* Semi-Isolated and Non-Isolated Disadvantages Easy to inadvertently affect another developer Example: Debugging locks common Web server Non-isolated: Only one code-behind DLL FrontPage Extensions don’t support parallel development with multiple shared checkouts

37. Repeatable and Reliable Well-Defined Process (including Build Process) Dedicated Resources for Version Control and Build Well-Defined Source Code Structure Match Source Code with Outputs (Versions,Labels) Fast  Parallel Development Symbiotic Development and Build Environments Web Environment Team Configuration Well-Defined Source Code Structure Multiple checkouts and merging Keys To Getting The Most From Team Development [assembly: AssemblyVersion("1.0.1001.1")]

38. Visual Studio.NET Changing Existing Web Projects Changing Web Model Choice 1. Open Project Properties 2. Open Common Properties folder, click Web Settings 3. Change Web Access Mode Using Front Page 1. Open Visual Studio.NET Tools Options 2. Open Projects folder, click Web Settings 3. Select FrontPage Extensions

39. Structure: Single Solution Model All projects are contained in the one solution If one project needs to reference an assembly generated by another, use project references Use file references only to reference outer-system assemblies that are not built with the rest of your system Inner System Boundary Project A Project B Project C Project D Project E Outer System Boundary Solution 1 External Assemblies Third-Party Components File reference Project reference

40. Structure: Master Solution Model Partitioned Single Solution All projects are contained in a master solution Project references are used between individual projects Separate solution files are introduced for selected project files containing any downstream project it depends on Inner System Boundary Project A Project B Project C Project D Project E Outer System Boundary Master Solution External Assemblies Third-Party Components File reference Project reference Project H Project F Project G Solution

41. Solution 3 Solution 2 Project D Project E Structure: Multi-Solution Model No master solution file File references are used between projects in separate solutions The system build script that runs on the build server builds each solution in turn, based on known dependency relationships Inner System Boundary Outer System Boundary External Assemblies Third-Party Components Solution 1 Project A Project B Project C Project F File reference Project reference Recommended Recommended