Fog Creek Software
Discussion Board

Team Development with MS Visual Studio

Those who are in the MS land, how do you do configuration management when working with Visual C++? For example, you have 100 developers working on 50 modules of the system. Each of them may have to tweak the .dsp file to add/remove files, alter settings, etc. How does it get managed in a source control environment?

Coming from the UNIX land with make files, VS seems to be suited to a very small development team. I plead my ignorance and respectfully ask for help! :)

Thursday, April 3, 2003

In my experience, if you have 50 modules, you'll probably have 50 .dsp files (or .vcproj in Studio.NET).  That should pretty much eliminate most collisions.

Even if not, the .dsp file is text so it's possible to allow multiple checkouts and do merges.  The catch is that stuff like include paths and libraries are all one line, so merges don't work for that.

Basically, it shouldn't be any tougher than Makefiles.

Thursday, April 3, 2003

Based on the way you phrased your question, you've probably already seen this, but in case you haven't, check out this guide from Microsoft's Patterns & Practices site:

Team Development with Visual Studio .NET and Visual SourceSafe

Friday, April 4, 2003

In my corner of MS Land we all keep pretty much the same environment.  Same include dirs, same lib dirs, etc...  So any .dsp will work on anyone's machine.  As for modifying it, we treat it just like any other file - it gets added to source safe and you have to check it out.

Not really any different than using a make file. 

Friday, April 4, 2003

In my team, it is a REQUIREMENT that your environment is the same as everyone elses.  I don't care how many developers there are, when you check out of Source Safe it should compile with no changes to the DSP.

Matt Watson
Friday, April 4, 2003

>For example, you have 100
>developers working on 50 modules of the system

You can make separate .dsw's that only include the .dsp's that you actually need.  It loads and compiles faster that way, and if another user changes a .dsp that I don't use, I don't have to care about it. (And if he checks in some code that doesn't compile, i'm not slowed down.)

Use Visual Source Safe for integration.

100 coders?  At that point, you probably want to start thinking about rational tools ... ugh.  I'd avoid it if you could.


Matt H.
Friday, April 4, 2003

Add me to the list of people who suggest just checking the .dsp/.dsw into the source code control system of your choice (SourceSafe, CVS, Perforce, ClearCase, whatever).

However I'd also say (and I realize I'm responding to a bit of a hypothetical situation, right?) 100 developers is too many to be on a team where each cares about the other's source code.  Some clear distinctions should be made with regards to modules, and each team should have a binary deliverable (generally in the form of a DLL or static lib, for Windows development) for the other teams.

George McBay
Friday, April 4, 2003

In my experience, just 5 developers depending on the state of each other's source code is too much.

Can you make a build in one step? If you can, then partition the whole project into manageable chunks. Each of these should build a variety of EXEs, DLLs, possibly static libraries too, and at regular intervals. Developers can then depend on these rather than the source code.

In the past, I've been on a four man team depending on another four man team who in turn were depending on a three man team and a six man team. In each case, the software for each team was built separately at regular daily intervals, an SDK of files produced, with release notes annotated from the checkin comments in SourceSafe.

Worked for me.

The catch here is that when you come to release a product, you need to know that you're using the front end app build 123 with the middleware library build 456 and the backend drivers build 789, and that's the _only_ releasable combination. Unless the drivers and the middleware have been regression tested with all the other modules that may depend on them.

Better than being unemployed...
Tuesday, April 8, 2003

I've never seen this documented, but it is possible to include env vars in dsp files in the form $(ENV_VAR).  These get expanded when used and are very helpful in setting up "portable" dsp's.  There are also a number of builtin macros, e.g., $(WkspName)

Thursday, April 10, 2003

We've found that all you really need to do is make sure that all the paths in your DSP file are relative, rather than absolute. It's a little annoying, but as long as you go in and make sure of this, your projects are a lot more "portable" from machine to machine.

Chris Tavares
Thursday, April 10, 2003

I asked everybody on my team to use only relative paths in all our DSPs. This allows developers to build the solution on C:, D:, H: or whatever drive they want in whatever folder they like. It is not difficult to achieve once you get the use of '..\'. We have a medium size project, some 50 modules and we noticed a huge increase in productivity after the changes were made (some years ago).

People were afraid to get the latest code knowing they will spend a day to make the build work.


Saturday, April 12, 2003

*  Recent Topics

*  Fog Creek Home