I have a solution that I work on with another person and the solution has around 50-60 projects, which in my opinion is too many, as it slows down build time during development and generally means more work must be done by the IDE than is necessary during development.
The only reason this solution is not broken into smaller solutions is that any kind of refactoring or other changes to code can potentially cause breakages in other solutions and these are not picked up until after the code is pushed to the repository and then discovered by the other developer when he tries to do his work.
As I don’t have a lot of experience with continuous integration, I’m wondering if (aside from the other fantastic benefits that come with build automation) it is the standard way that other developers are avoiding the need for solutions with a lot of projects? Can somebody recommend a good primer on continuous integration and build automation for .Net/Windows developers?
Yes, a solution with 50-60 projects most likely is too much. Presumably all of those projects don’t relate to the particular product that the solution builds, and that many of them could be considered framework pieces?
I would recommend moving any framework (product agnostic) projects into their own framework solution, and then just add references to the compiled assemblies in the product solutions, rather than the framework projects themselves.
If you use TeamCity 7 (recently released) for your continuous integration, then one of the features it provides is NuGet packaging. This means you could package your company framework into a NuGet package to make deployment to each product solution very straightforward.
Some great resources on continuous integration/delivery are: