Transcript Document

DEV232
Source Control and Team Development
Using Visual Studio .NET and Visual
SourceSafe
Alfredo Méndez
Program Manager
Microsoft Corporation
Overview
Agenda
Team Development Tips
SourceSafe Best Practices
Changes in Visual Studio .NET 2003
Summary and Discussion
Recommendations
Not one-size-fits all
Difficulty Working In Teams
With Visual Studio .NET and SourceSafe
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
[assembly: AssemblyVersion("1.0.1001.1")]
Team Development Process
High-level Lifecycle
Business Need
or New Idea
Gather
Requirements
Analyze and
Architect
Multiple Check-outs, Multiple Solution Files
Repeatable &
Reliable
Fast
Implement
Unit and Develop
Test
Implement
and Develop
Implement
and Develop
Implement
Unit and Develop
Test
Test
System
Release
and Deploy
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
Set Up A Team Environment
Get Latest
SourceSafe
Server
Development
Process
Check In,
Get
Development
Team
Database
Server
BuildIt .NET
Build
Process
Build Server
Test Process
MSI Package
Build Output
References
Web Services Reference
Server
Admin Team
Release
Process
MSI Package
Test Team
Test
Results
Issue Tracking
Deployment
Process
Dedicate Server Hardware
Recommendations
Build
SourceSafe
Database
Web
Service
CPU
Memory
Hard disk
PIII-class
660 MHz
Pentium-class
333MHz
96-192 MB*
32-256 MB
600 MB sys
3 GB install
4-10 GB
(32MB min)
(2x db size)
TIP: Minimize network latency for speed
SQL Server 2000 Enterprise Edition with
appropriate requirements
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)
Choose A Web Model
Isolated / Local Host
Semi-Isolated / Server Host
Common Web Server
Developer 1
Developer 2
Web Application
Web Application
Visual Studio .NET
Visual Studio .NET
Web Application
Web Application
Developer 1
Developer 2
Visual Studio .NET
Visual Studio .NET
VSS
VSS
 Recommended
Non-Isolated / Front Page
Common Web Server
Web Application
VSS
Developer 1
Developer 2
Visual Studio .NET
Visual Studio .NET
Web Development Models
Isolated
Semi-Isolated
Non-Isolated
http://localhost
http://server
http://server
SourceSafe access
File Share
File Share
FrontPage
UNC access needed
Yes
Yes
No
Can work isolated
Yes
Yes
No
Offline support
Yes
Yes
Limited
Dedicated server
No
Yes
Yes
Web references
Automatic
Use user.config
Automatic
Server debugging
Automatic
1 Session per
machine
1 Session
per machine
Recommendations
Preferred
Server
Resources
Compatible
 Recommended
Typical access
Structure And Name
Solution
Projects And Solutions
Dependencies
Project A
Projects (.csproj, .vbproj, etc.)
Project B
Build and configuration
Project C
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
Solution files (.sln)
Groups related projects together
Contains project dependency information used
by the build process for build order
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
Manage Dependencies
Web References
Web references to external services work fine
Web references to Webs within the solution
require management
http://localhost users
Need to ensure all their local projects are in the
same place
http://server users
Need to make their references ‘dynamic’
Each team member must have a user.config file that resolves
the reference for them
Create Multiple Solutions
Single Solution
c:\Projects
Solution1
Master Solution
c:\Projects
Solution1
Multi-Solution
c:\Projects
Solution1
Solution1.sln
Solution1.sln
Solution1.sln
Proj1
Proj1
Proj1
Proj1.csproj
Web1
Web1.vbproj
Patterns & Practices
Proj1.csproj
Solution2
Solution2.sln
Proj1.csproj
Solution2
Solution2.sln
Web1
Web1
Web1.vbproj
Web1.vbproj
 Recommended
Create A Common Folder Structure
Use the same local structure for all developers
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”
Local Structure
..\Visual Studio Projects
C:\Projects
SourceSafe Structure
$/Projects
MySolution.root
.sln
MySolution
ClientProject1
MySolution
ClientProject1
Bin
C:\inetpub\wwwroot
WebAppProject2
Bin
WebAppProject2
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
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
Steps In The Build Script
Generate
build number
Fix broken
build
Label Sources
& Retrieve
No
Errors?
Create Backup
& Archive
Copy \Latest to
numbered folder
Yes
Rename \Latest
to \Broken
Send e-mail
with error log
Update
BuildNumber.xml
Delete Backup
Send e-mail
Debug &
Release
Devenv.exe &
copy to \Latest
c:\BuildLab
Sources
Latest
Debug
Release
Archive
1
2
Debug
Success!
Release
demo
BuildIt .NET
Alfredo Méndez
Program Manager
Visual Studio Core Team
SourceSafe Best Practices
And Tips
For Team Development
Files And Source Control
Visual Studio .NET extensions
Source-Controlled
Not Source-Controlled
Solution
Project
.sln
.vbproj,
.csproj
App Config web.config,
app.config
Source Files .cpp, .cs, .vb,
.aspx, .asax,
.resx, .css, .h,
.vsdisco, .idl
User
Options
User
Options
Web info
Hint Files
Hint Files
.vssscc,
.vspscc,
~sak*.sln
~sak*.vbproj,
~sak*.vsproj
Build
outputs
.suo
.vbproj.user,
.csproj.user
.vbproj.webinfo,.
csproj.webinfo
.idl  .h,
many others…
mssccprj.scc,
vssver.scc
There are many files…
…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
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
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
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
Changes In
Visual Studio .NET 2003
What’s New?
Visual Studio .NET 2003
And Visual SourceSafe 6.0d
Reduced prompting and creation of a “.root” folder in
SourceSafe when adding to source control
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl]
"DoNotCreateSolutionRootFolderInSourceControl"=dword:00000001
Elimination of temporary files (~sak) that perform a
capabilities test
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl]
"DoNotCreateTemporaryFilesInSourceControl"=dword:00000001
Additional guidance on securing your database
Other issues identified in KB 820831
Summary And Discussion
Closing thoughts
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
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
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
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
evaluations
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Backup Slides…
Team Domain Infrastructure
Stress Test
Environmen
t
Stress Hub
100MB Ethernet
DC
Build
Backup
VSS
MSDN
VSS Shadow
100MB Ethernet
SQL Servers
Developer
Workstations
Dev
Test
Web Servers
Dev
Test
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
Keys To Getting The Most
From Team Development
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)
[assembly: AssemblyVersion("1.0.1001.1")]
Fast  Parallel Development
Symbiotic Development and Build Environments
Web Environment Team Configuration
Well-Defined Source Code Structure
Multiple checkouts and merging
Visual Studio .NET
Changing Existing Web Projects
Using Front Page
Changing Web Model Choice
1. Open Visual Studio .NET Tools 1. Open Project Properties
Options
2. Open Common Properties folder,
2. Open Projects folder, click Web
click Web Settings
Settings
3. Change Web Access Mode
3. Select FrontPage Extensions
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
File reference
Outer System
Boundary
Solution 1
Project reference
Project
A
Project
B
Project
C
Project
E
Project
D
Inner System
Boundary
External
Assemblies
Third-Party
Components
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
File reference
Outer System
Boundary
Project
A
Project reference
Project
C
Project
B
Solution
Project
D
Project
H
Project
E
Project Project
F
G
Inner System
Boundary
Master
Solution
External
Assemblies
Third-Party
Components
Structure: Multi-Solution Model
 Recommended
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
File reference
Solution 2
Solution 1
Project reference
Project
A
Project
B
Outer System
Boundary
Project
D
Project
E
Project
C
Solution 3
Project
F
Inner System
Boundary
External
Assemblies
Third-Party
Components