file references vs. project references for enterprise apps

[Adam J. Schaff]

Hello all.

I am part of a team about to start work on a large enterprise application.
There will be a main application and a bunch of smaller applications that
are all related and use the same database. All applications will be using
the same class libraries (of which we will probably have many for things
like data access, exception management, business objects, and many more).
Some of these class libraries will reference one another.

I am looking for advice on how to structure these projects. I keep hearing
project references recommended over file references, yet that would seem to
require one monolithic solution containing all projects. Aside from how slow
that would be, it seems inappropriate to have all developers able to see the
class libraries that are another team member's responsibility. So I thought
about using file references and having one project per solution. But if I go
that route, then it is unclear to me how I would let projects know about new
versions of other class libraries. The notion of manually removing and
re-adding file references regularly seems an unnecessary burden. Maybe I
should put a copy of all assemblies in a common network folder during a
nightly build and have all projects reference their dependencies from there?

Note that I'd like to avoid the GAC. I want these applications to be almost
xcopy distributable, and I have no qualms whatsoever about having 5 separate
copies of the same class library for 5 different applications. Disk space is
cheap! :)

Any advice on how you have structured your own large projects would be most
welcomed. Feel free to share any experiences, good or bad, with either file
or project references.

Thx,
AJ