Visual Studio Solution Structure for multiple deployable projects

Question

Scenario:

Currently we have a single solution supporting a single deployable entity, a WinForm/WPF client, this solution has a layer architecture with projects representing various layers (Data, Business, UI). We will be introducing other deployable entities such as a LiteClient, a Server and an RIA.

We are considering a restructure where we will have multiple solutions, one per deployable entity (Client Solution, Server Solution, RIA Solution etc), these solutions will share various projects, e.g the Data layer project. This is essentially the Partitioned Single Solution recommended by Microsoft's P&P group (http://msdn.microsoft.com/en-us/library/ms998208.aspx)

Question:

Apart from the admin overhead of this approach, is there any serious real world gothas waiting for us, if we adopt it.

Answer 1

If you change something within the shared projects, you have to check if that didn't break the dependent projects. If you keep those projects in seperate solutions you have to remember to recompile them each time you modify the shared projects.

That's a drawback that I can see.

Answer 2

This is a reasonable and normal approach. At the end of the day, the Visual Studio solution is simply a collection of projects with deployment information.

In order to reduce possible dependency issues, make sure you use a build server (TFS or otherwise) that takes care of compiling and deployments.

Answer 3

See:

http://keithelder.net/blog/archive/2007/02/01/Structuring-Solutions-in-Visual-Studio-and-Team-Foundation.aspx