Often multiple applications share a large codebase of libraries that change often in development. In these cases, I prefer to create a solution named after the suite, and include separate projects for each application and the shared libraries.
Is this a good approach? How do others structure their code bases for things like a suite of applications?
The actual structure of your solution(s) really depends on the internal workflow. Having a very agile, everyone-refactors-everything approach would point towards one solution with many projects. If your shop has a dedicated library team and various application teams, which do regular internal releases, then separate solutions might help through stronger decoupling, and reduced build times.
It really depends on your organization's particular needs. MSDN has a good page that goes through the various recommended solution layouts, including:
The MSDN page also discusses the pros and cons of each model in more detail so you can decide which one makes sense for you. :)
In general, for an application suite such as you describe, I would consider the partitioned, single solution model. There's a single master solution that builds everything, and a number of separate solutions for each individual application within the suite (assuming the applications are of appreciable size).
If the applications in the suite are small and build quickly (e.g., a suite of command line tools), I might not even generate the separate solution files. That's really a judgement call we can't make for you. :)