Hi,
I recommend using project references over assembly references. Personally,
I like having all of the projects in one solution as long as it doesn't
hamper development (too much clicking and searching can get annoying).
It may seem a bit strange having all of my required utility libraries added
to every solution that uses them as projects, but I do that also. I like to
be able to update the utility libraries when I find bugs or to add new
features while I'm using them.
Another benefit of project references is that it helps to be able to quickly
debug all of the projects from within the same solution by using breakpoints
and being able to step into other projects. Although this is possible
without project references, you'd have to reference the assembly with the
debug symbols, which brings me to my last point...
Project references also allow you to build a debug or release configuration
by just changing the solution configuration. With assembly references you'd
have to do some rewiring first for release builds.
An alternative for team development is to use smaller solutions that contain
only the projects that a particular team requires, with assembly references
to the other projects, and then create one major solution that builds the
final release with project references to all. The build solution would tie
in all of the teams components and could be used for a nightly debug build
and the ultimate release build.
The only problem that I've seen with project references (if you want to call
it a problem) is that source control complains about the binding root being
different from the solution for each of the utility projects.
Another advantage, regarding dependency and build order, can be found on
MSDN:
Project References
§ Project-to-Project References and File References
http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx