I'm helping to manage an external team who are starting to develop new versions of some existing products. Historically, this team has always used a model of a single project in a single solution for about 30 modules in Visual Studio which go together to produce a deployable build.
This is having a detrimental impact on build reliability and quality, because they don't always send us the most up-to-date source code. We're trying to press them to unify all referenced code in to a single solution, but we're getting some resistance – specifically they keep talking about interdependence between modules (read "projects" in Visual Studio) being increased if everything is placed in a single solution file. None of the code in the separate solutions is used elsewhere.
I insist this is nonsense and good development patterns will avoid any such problem.
The team in question also perform bugfix and new feature development on an existing product, the experience of which has been fraught to say the least and suffers from exactly the same problem of splitting over multiple solutions. We've been refused access to their source control (TFS), and the approach we're taking to unify the codebase is to try and at least reduce the number of missing updates and more than occasional regressions (yes, fixed bugs are getting re-introduced in to the product) by saying "send us a ZIP of the entire solution folder so we can unzip, open it in Visual Studio, and press F5 for testing". In terms of general structure and quality, the code is pretty poor and hard to support. This experience is why I'm intent on getting the working processes right as early in the development cycle as possible.
Is there something I'm missing? Is there ever a good reason to keep all that code separated out? For my money it would have to be so compelling a reason that it would be common knowledge, but I'm more than willing to concede that I don't know everything.
Best Answer
You don't need to tell them how to structure their projects. Instead, make it a hard requirement that you can build the system from source by running one single script, without getting any errors. If that scripts runs Visual Studio or Msbuild or some other tools, and if those are called once, 50 or 100 times should not matter.
That way, you get the same "test for completeness" of the code as you would get by putting everything into a single solution. Of course, that script does not tell you if the team has really checked out the latest version from their source control, but having the whole code in one solution would not check that, either.
As a reply to "interdependence between modules being increased if everything is placed in a single solution file" - this is proveable nonsense, since adding projects to a solution does not change any of the dependencies between projects, the dependencies are a result from one project file referencing another, which is completely independent from which solution references which project file. No one stops that team to have both - a single solution which references all projects, and also individual solutions each one referencing only one project.
Nevertheless I would suggest to add a build script. This has benefits even when there is only one solution file. For example, it allows one to run a VS build with a preferred configuration, let you copy the final files for deployment (and nothing more) to a "deploy" folder, and may run some other tools and steps to make the build complete. See also F5 is not a build process!, and The Joel Test.