As my "real job" .NET developer group
gets into full swing on a major project, we've found out some very interesting
and useful things about development in a team environment under the
new .NET platform. We've also found out that you have to do some serious
studying and reading to get things right, and that also, there is
an educational process that needs to happen because developers
have a tendency to focus on the little things that annoy them as "negatives"
and not want to change because they don't yet see the "big picture"
Here I'm going to share some of the things we've
learned so far as I suspect that there is a growing number of developer
teams that will be working together on a common code base for .NET,
much of which may involve migrating (or shall I say more accurately,
"rewriting"?) legacy VB 6.0 COM components and projects to
the .NET platform.
First of all, the good news is that VS.NET is
much more tightly integrated into Visual Sourcesafe, and when used properly,
it can make a very big difference in the overall source code
maintenance process and the build process. This translates into immediate
and ongoing savings of time and an increase in developer productivity
when working in a team - based environment, and that's really good
The downside is that this doesn't necessarily
come automatically or intuitively. What I can tell you, however, is
that if you take the time to read the Microsoft whitepapers and have
your team meet several times before your project starts to discuss architecture,
coding standards, the build process and source code control, it will
pay big dividends, and they'll be noticeable right away!
To begin, you should start by having every member
of your group carefully read the team
development whitepaper for .NET and your group should have a meeting
to go over the details, making any adjustments you need. To summarize
the most important points from my perspective:
1) There are three main models for developing Web applications:
In Isolated, develop (edit, debug and
run) in complete isolation on your own development workstation using
your local Web server (http://localhost).
In Semi-Isolated, you use a common Web
server (http://remoteserver) for application development and debugging.
You check files in and out via a VSS database located on a network file
share. Your working copy of the project is located on the common Web
server in a specified project folder, which is also a Microsoft Internet
Information Server (IIS) virtual root. Each developer has a unique project
folder on the common Web server.
In Non-Isolated, use a common Web server
(http://remoteserver) for application development and debugging. However,
you do not have your own working copy of files and all developers use
a single folder and virtual root on the server; for example, http://remoteserver/projectname.
We use Isolated mode at our organization; usually
decisions not to use this recommended mode revolve around hardware and
similar issues. You can use multiple checkout, and your team will have
the most flexibility.
The most important concept to understand
about VSS and .NET is that the SOLUTION (.sln) file is king.
If you set up your project tree in Sourcesafe with the SOLUTION at the
top, and each separate PROJECT in the Solution TREE representing another
component or "piece" of the solution (the total project),
then you will have a hard time going wrong. The idea here is to be able
to check out the entire solution, do a batch build in ONE SINGLE SHOT
(from the IDE), and deploy and test it. Important: A project can
be part of one or more solutions but solutions can't be included
within other solutions. Different developers can have one or more PROJECTS
that are part of the SOLUTION checked out at any one time. But when
you do a "Get Latest" on the SOLUTION and do a build, everything
should be synched- up.
The way we have our SourceSafe "Tree" set
up however, enables more flexibility. We have the "Master Solution"
at the top of the project tree. Within each "component's"
tree node we have a separate "sub-solution" file for that
component or assembly, which solution can have a test harness project
for the solution, XML documentation generated by the IDE, and other
such files. This enables one of our team to check out only the Solution
for the project they are working on within the overall "Master
Solution" and have everything they need to work on that "unit".
if you choose this route, the whitepaper suggests you mark these subsolutions
with "ProjectNameSoln" type nomenclature.
This is a concept that some developers are not
going to be used to (that's why their project build cycles are such
an incredible mess), but if you want success, you're going to have to
Another important concept is to "sync up"
the directory structures between VSS and your hard drive. We use a namespace
structure in Sourcesafe that mirrors our actual .NET namespace hierarchy
(I did say you should have a well-defined namespace scheme, didn't I?).
It goes something like this:
Company.Division.Tier (web, data,util, etc.).componentname
What you do is start with your C: or D: drive, and
make the working folder name hierarchy look IDENTICAL to the one for
your project in Sourcesafe. This will allow you to check out individual
projects in the SOLUTION, work on them (even with multiple checkouts)
and have everything fall into place. Don't worry about the fact that
some of the projects are WEB projects - VSS will handle it with virtual
directories, and I'll give an example shortly.
Build dependencies are vitally important to the whole
process. There are two basic types of references - project references
and file references. You set both types by using the Add References
dialog box in Visual Studio .NET. Because project references also establish
build order dependencies, you should use them whenever possible.
Always use the VS.NET IDE to handle all your
source control operations! All project creation and manipulation within
VSS should be performed by using the integrated VSS support menus within
Visual Studio .NET - don't use VSS Explorer for this! The tight integration
that's been built into the product will ensure that that files are managed
correctly in a team environment.
Now here is how to Create a new Web Application within
1. Open Visual Studio .NET, and on the File menu,
point to New, and then click Blank Solution.
2. Enter MyWebAppSolution as the solution name, and then set its location
3. Click OK. Visual Studio .NET creates the MyWebAppSolution folder
beneath the specified root folder location.
4.Use Windows Explorer to create a new subfolder called MyWebApp beneath
5. Use either Windows Explorer or Internet Services Manager to establish
the MyWebApp folder as an IIS virtual root.
Note: Visual Studio .NET requires that the virtual
root name match the project folder name.
6. Return to Visual Studio .NET, and on the
File menu, point to Add Project, and then click New Project.
7. Add an ASP.Net Web Application project.
8. In the Location field, enter http://localhost/MyWebApp, and then
click OK. The project and Web source files will be created in the specified
You should be aware that when you check out a Web form
(aspx) file or a code-behind file (aspx.cs or aspx.vb), Visual Studio
.NET automatically checks out both files. This is by design because
user interface changes generally involve an aspect of coding within
the code-behind file.
You should spend considerable time with naming
conventions. Use common names for projects and assemblies. Your output
assembly name should always match the project name from which it is
generated. For example, you should be able to assume that an assembly
called MyCompany.Utilities.Data.dll is generated by a project called
If you change the name of an output assembly, consider changing the
project name to match, and vice-versa.
Also, be sure to use Copy Local = True for Project and File References.
There is much more involved in this process, and all
I can tell you is that serious study and planning is well worth the
effort. You should be spending time with build scripts, dependency checking,
deployment projects and much more. The Team development whitepaper referenced
above covers a great deal of this. It should be made required reading
for every single member of your development team.