Team Development with Visual Studio .NET

By Peter A. Bromberg, Ph.D.
Printer Friendly Version

Peter Bromberg


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" at first.

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 news.

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:

  • Isolated (recommended)
  • Semi-Isolated
  • Non-Isolated

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 enforce it

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 etc.

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 a Solution:

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 to C:\yourcompany.division.Tier.Web
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
   the C:\yourcompany.division.Tier.Web\MyWebAppSolution folder.
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 virtual root.

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 MyCompany.Utilities.Data.
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.

Peter Bromberg is an independent consultant specializing in distributed .NET solutions Inc. in Orlando and a co-developer of the developer website. He can be reached at