CODEWITHSUNDEEP
visual-studiostructuresolution
Aidan
Aidan

Reputation: 367

Visual Studio Solution Structure for multiple deployable projects

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/Ee817674(pandp.10).aspx)

Question:

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

Upvotes: 7

Views: 2413

Answers (2)

ChrisLively
ChrisLively

Reputation: 88072

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.

Upvotes: 2

FantaMango77
FantaMango77

Reputation: 2437

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.

Upvotes: 0

Related Questions