Its not really - Microsoft says the best way to handle references is to build your project in one huge solution. Yes, I know, they really do mean it too.
The patterns and practices team have put their best practices together with regard to TFS, but it applies to general builds. There are 3 types of solution setup, the "1 big solution", a partitioned approach which is a lot like how most people used to manage builds by building in turn and copying artifacts to a common directory (which si not helped by .NET not having a server-wide 'include' or 'library' path to reference), and a Multiple Solution setup which is a more complex version of the Partitioned one.
In general you should:
Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
Use multiple solutions to create specific views on sub-systems of your application.
Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.
For TFS they recommend branching any external projects inside your project, rather than relying on the workspace mapping that is more akin to subversion's externals. Personally, I think their advice there is not best practice, but I suppose they are trying to minimise any build issues you'll get when using references.
I have had issues with .NET builds that try to shortcut the system by building only what's needed, a nightly build that does everything, and copies every new assembly to a directory was the best way for everyone to keep in sync - especially the testers. Note this really only applies to .NET apps, C++ ones tend to still work because they don't have versioned assemblies or similar aspects that can cause problems with calling components. This approach works well, but you can't always assume that partial builds are ok, vaping the whole thing and rebuild is safest.