You know, I am stuggling with this very issue. I have also found that VS.NET
really starts to break down as a conifuration management tool for complex
n-tier applications.

I just posted a similar topic at codeproject.com.
(http://www.codeproject.com/script/comments/forums.asp?forumid=3831&select=6
75694)

Perhaps an answer to both of our questions will come from this group or
codeproject!

cheers,
don

HI,

My team of 6 developers has been working on a multi-
solution, multi-project ASP.NET enterprise app for the
last year.  This is a business-critical system with high
impact on the bottom line. Around 3000 users. It will
replace a mainframe app which costs us several million
dollars per year in maintenance fees.  It consists of 8
solutions, each solution contains 4 projects, and there
will be almost 300 web pages and 150 Cognos reports when
we are done.  The solutions are aligned along business
processes, i.e. money management, customer management,
etc.  One solution contains modules and datasets commonly
used by multiple other solutions, and another solution
contains just the 'back-office' screens which are used to
edit master files and company setups.

We've found the following to be helpful:
1) Use Visual Source Safe as the central code
repository.  Visual Studio integrates VSS fairly well
(but not perfectly).  A caveat - do not use VSS Explorer
to check in/check out files once Visual Studio has added
them to VSS or checked them out.  Otherwise you WILL get
out-of-sync if you are careless, and someone's code will
be overwritten.
2) Use the Partitioned Single Solution model (remember we
are talking about large systems here).  We tried the
Multi-Solution model but it was very troublesome due to
file references getting frequently broken.  For us this
model gives the best mix of separation of developers and
centralization of code.  You can use the Single Solution
model if you don't mind the long load and Rebuild times
in Visual Studio.
3) Every developer has his own web server to develop on.  
When development is complete, the code is checked into
VSS.  Code does not get checked in unless it compiles.
4) Twice daily a separate Build Server uses a batch file
to GET LATEST from VSS (using a Single Solution which
contains all 32 projects) and Rebuild the whole
application.  If the build fails the batch file sends an  
email to me and the responsible developer is flogged.  If
the build succeeds the resulting asp.net web pages and
DLLs are XCOPY'd to the development department web farm
(2 servers).
5) Our QA people test the code on the development web
farm.  The individual developers do not have access to
these web servers.
6) During our periodic user acceptance testing the
candidate build is copied to a testing web farm (2
servers).  There the business owners can test the code
without being affected by ongoing developer work.

Key learnings:
1) Do not use file references.  Run away as fast as you
can.  
2) Every developer has their local solutions and projects
in the same place on every computer.  This simplifies VSS
work and removes the need to change paths.
3) Don't mess with the Reference Path property page in
Visual Studio.  Let Visual Studio figure it out; if every
developer has the same project structure in the same
place on every computer then VS and VSS will work well
together.
4) Strike a balance between the number of solutions, and
the number of projects in each solution, and the need for
multiple developers to work on the same projects.  We
aligned the solutions along business process lines but
some other arrangement may work better for you.  The
point is to prevent developer 1 from waiting on developer
2 to check in a project file.

Hope this helps.  Good Luck with your app.

Jeff K.

<snip>

Hi Michael,

We have a decent size project going here...  about 300k lines of code, 6
client applications and lots of seperate assemblies and web services -- also
database projects.  We went assembly crazy at the beginning (we have over
100 asseblies) but, we are slowly consolidating to reduce reference
complexity.  Also, there are about 25 - 30 developers.  And I'm guessing
about 2000 source files.  We have major production releases 4 times a year.

We use a home grown build tool and it has been meeting our needs fairly
well.  We use Source Safe for all work -- it has been working, but I can't
wait for the next version.  We are running daily builds on a dedicated build
machine -- currently we are building every hour.

Essentially, the build tool follows the build process outlined in the MS
document you referenced.  It was non-trivial to write due to the rather
convoluted Visual Studio project and solutions files.  Our build tool does a
get from source safe, parses all the project files and generates a makefile
that calls the compilers (csc, vbc) directly.  The makefile is generated so
all interdependencies are resolved and built in the correct order. We do
delta builds hourly during the business day, only building what has changed
and any assemblies that depend on those, etc.  We do full builds twice a
day.

For simple (one assembly) local development we use a common share point for
references - this share point is deployed to on an as needed basis using the
output of the build tool.  For complex development (several interconnected
assemblies) the developer runs local delta builds on his or her workstation.
The developer repoints the Reference Path to the locally built assemblies.
We have had very little problem with the Reference Path settings -- having
them in a non-source controlled file has helped more than hurt us.

I agree with matching Source Safe and the local file structure.  One thing
that has also been handy for us is to match the path to the assembly root
namespace.

Things that have been a sore point for us:
1. Breaking the build -> it is easy for a developer to check in code that
does not compile.  With hourly builds we find these problems sooner rather
than later.
2. Concurrent development on multiple releases -- we have not found an easy
way to do this with source safe.

Things I might change:
1. Build Tool -- it is very complex.  It might have been better to
investigate something along the lines of nant.
2. Database projects -- they seem to be the step-child of the Visual Studio
family.  It might have been better to look at 3rd party solutions here.
3. The sheer number of our assemblies.  This increased the complexity
significantly.  One class per assembly is not good design.  We are looking
at consolidating core assemblies on the client side and server side.

I would strongly suggest reading Martin Fowler's article title Continous
Integration: http://www.martinfowler.com/articles/continuousIntegration.html

I'm not sure how much help this posting is.  Please let me know if you have
any questions or if you want me to go into detail on anything specific.

Also, you might want to look at the Whidbey release of Visual Studio.  Its
release still a bit off in the future, but it might steer some of your
decisions.

Good luck,
Don