Are there any drawbacks to having 1 solution per project

We are working on a big application, comprising around 100 projects (40 views, 40 controllers/models, 20 Utilities libraries). We have outsourced the bulk of the work and the deliverables come in fairly randomly.

When we get a deliverable (a project), we need to run FxCop, StyleCop, the associated unit-tests, etc, etc. before committing it to source control. To make开发者_JS百科 this easier, we have mandated that every project has a solution file. This allows us to simply run an automated script on the solution file which tests it before checking it in.

My question is "Can you think of any drawbacks to having 1 solution for each project?".

Drawbacks we have already discussed include:

1. Additional maintenance required by developers. This doesn't bother us as we have outsourced development on a fixed-price contract.
2. SourceSafe bindings in solution file. This could have been a huge issue, but luckily we migrated to TFS about a year ago.

We're in a similar boat with about 200 projects, many of them common use, accross our various solutions of varying sizes.

While a disadvantage is load time, one advantage is debugging - i.e. if your code is calling into other assemblies, then it's nice to have everything in the same solution.

Also, we do keep our unit and integration tests along with our core project (DLL or EXE) all in the same solution, so even on a bare bones template we have at least three per solution.

Ultimately I'd say the largest advantage of a common solution boils down to cross-project debugging, IMO. - But I would never just toss them together unless there was at least this, or some other compelling reason.

On a side note - we do not allow a project without a solution for the reasons you noted above (running FxCop, etc.) plus Continuous Integration. One disadvantage of a large solution with several projects is build time - but it does help to know if messing with a component ended up breaking an unrelated solution/project.

We did discover one drawback in the end. All our projects are in Visual Studio 2008. If we want to upgrade one project to Visual Studio 2010, we realised we would almost certainly need to upgrade every other project (as they are all, directly or indirectly, either dependent on, or depended on, each other).