Overview

1. Team Development Using Visual Studio 6.0Martyn LovellDevelopment LeadVisual Studio EnterpriseMicrosoft Corporation6-309

3. Overview • Team Development Tools • Source Control • Setting up • Unifying tools • Parallel Development • VSS integration best practices • Component Management • Setting up • Best practices • Summary • Q&A

4. Focus Areas • Covered • Visual Studio 6.0 • Visual C++, Visual Basic, Visual J++, Visual InterDev • Source Control Systems • Visual SourceSafe, Others • Visual Component Manager • Not Deeply Covered • Visual FoxPro • Microsoft Access • Other uses of the Microsoft Repository

5. Team Development Tools • Source control • Manage Source code • Manage Documentation • Share Reusable source • Component management • Manage Built binaries • Manage External binaries (MFCxx.DLL) • Share Binary components (OCX) • Each allows other’s content • But is optimized as described above.

6. Source Control • All of Visual Studio is integrated with Source Control • Each piece of the product does it slightly differently • Working with each individually is well-documented • When your work crosses tools things become more complex • This is the focus of this part of the talk

7. Types of Integration • Client Side • Has user interface • e.g. Diff/Merge • Uses Microsoft Source Code Control Interface (MSSCCI) • Server/Automation • No user-interface • Runs unattended

8. Client Integration • MSSCCI-based • De Facto standard • Supported by all major vendors • PVCS, ClearCase, Team Connection, … • Used by other editors and tools • MS Products • Visual Basic, Visual C++, Visual J++, Visual FoxPro, Access

9. Server Integration • Server-side integration uses a VSS-specific interface • SourceSafe supports it • PVCS has some support too • Used to keep a server backed by source control • Not widely used on the client • MS Products • FrontPage, Office Web Server, Visual InterDev

10. Setting up: Team • One person should administer • They will be responsible for • User management • Sharing • Branching • Pinning • Analyze • Creating Databases

11. Setting up:Visual SourceSafe • Use VSS explorer to open databases • Use browse to find your database on the network • Create shareable connections • Shareable connections look like • \\martyn\vss\srcsafe.ini • Non-shareable connections look like • C:\foo\srcsafe.ini • Avoid using NetSetup • It makes a non-shareable connection

12. Setting up: FrontPage • Set up FrontPage server to point at VSS • Can point at VSS database on any machine • Tough process • Get the KB articles • See Q157883, which points at other KB articles • Works seamlessly when set up

13. Creating A New Project • Create it on your local machine • Ensure it builds there • Keep everything under a unified root • All projects and files should be under some well known point • Otherwise, VSS will force you to copy them • Put metafiles above their references • Workspaces above projects (VC) • Project groups above projects (VB) • Solutions above projects (VJ/VID) • Vital for VB and VC; highly desirable for others

14. Importing Libraries • Don’t try to share local copies of library files • Your development efforts will interfere with each other • Source space is a small fraction of build space • Use ‘Share and branch’ to make references to common libraries • Caveats later

15. Adding To Source Control • Server layout should match disk layout • Don’t add output or temporary files • OPT/SUO • NCB • PDB • APS • Do add binary files • BMP/ICO • Consider adding input binaries (OCX, DLL)

16. Working With Source Control • Use integration where ever possible • Resort to VSS Explorer only when necessary • Use Refresh status command after using VSS Explorer • Check out all files before working on them

17. Unifying Tools • Three ways to unify tools • Command Line • Build Tree • Single SCC Environment • Each has strengths and weaknesses • No perfect solution yet

18. Command Line • Ensure unified root across all languages • Avoid adding directories too often • Write command line scripts to get latest versions • Pro • Simple • Extensible • Con • Completely manual

19. Build Tree • Ensure unified root across all languages • Avoid adding directories too often • Use VSS GUI to get new versions • Recursive • Build Tree • Pro • Simple • Con • Completely manual

20. Single SCC Environment • Choose a host environment • Probably best to choose your most important one • Create fake projects to wrap all projects from other environments • Fake projects must be kept in sync with real projects • All SCC operations done from the host environment • Other environments see themselves as controlled

21. Host: MDE (VJ/VID/VSA) • Microsoft Development Environment • Best SCC UI and integration • Use utility projects to model external projects • Can set up build too • No debugging except of VJ • Only way to integrate with VID as well • Good support for Share and Branch • Does not have VC’s issues in this area. • Best general-case solution from a source control perspective

22. Host: VC++ • Good SCC UI and integration • Use makefile projects to model external projects • Can set up build too • Debug VB, VC • No way to integrate with VID • Manual support for Share and Branch • Good for primary-VC users

23. Host: VB • Basic SCC UI and Integration • Use a VB Project to model external project • Not ideal • Can’t easily set up build • Debug only VB • No way to integrate with VID • Good support for Share and Branch • Good for mostly VB users who do a little VC

24. Demo • Assorted hosts

25. Parallel Development • VSS uses Share command to work in parallel • Branch command splits the share • Always branch metafiles • DSW, DSP, VBG, VBP, SLN, VJP • Some manual fix up required in VC • See knowledgebase Q173065 • VJ has command to aid fix up • Change Connection

26. Parallel Development (2) • Simplest solution • Share and branch everything • Administrator should complete branch before people start work • Be sure to reopen everything before you let others loose • Branching webs is hard • Avoid it • Use Copy Web

27. Parallel Development (3) • Merge branches when no one is working • Tree can become un-buildable • Do a get latest version • Build, Test • Fix any problems • Avoid re-share unless required

28. VSS Best Practices • Run Analyze weekly • Take regular backups • It’s a database! • Use the 6.0 format database • Performance • Get Visual Studio 6 SP4 • Includes several useful VSS fixes • Deploy to clients, not just server • Avoid unreliable networks • Use RAS only for read operations

29. Integration Best Practices • Have a shareable connection • Have a unified root • Share sparingly • Always use integration • Check out early

30. Component Management • Use Visual Component Manager to • Share built components • Reuse across organization boundaries • Provide centralised repository • Assign custom properties • Archive binary dependencies • VBRUN, MFC, etc • Not good for • Source code sharing

31. Setting Up • Experiment with MS Access • Create a taxonomy • Investment here will pay off • Initial taxonomy may help • Decide on keywords • People will not bother unless the keywords are apposite • Then setup SQL server • Key for performance • Have users deploy • Many may not have installed

32. Demo • Publish and Reuse

33. Best Practices • Archive all used binaries, OS-es, etc • Archive all inter-team releases • Create a simple website using FrontPage • Allows users to describe their component in more detail • VCM will run within IE too • Keep the publish burden low • Users are loathe to add metadata

34. Summary • SCC integration is powerful and flexible • Managing across many products is easier than it seems • Simple best practices can avoid most problems

35. Q & A • Http://msdn.microsoft.com • MartynL@microsoft.com