• en | es

Multiple projects in Visual Studio solutions considered harmful

Multiple projects in Visual Studio solutions considered harmful

I agree with Chad Myers when he defines a common project anti-pattern “Many projects in a Visual Studio Solution”.

Fast feedback loop

Too many projects increase both the load and build time of your solution. Also a solution will take longer to start executing in debug due the overhead of loading/resolving multiple assemblies with associated PDB’s and symbols. This has an impact on the fast feedback loop we should strive to achieve. When I write code I want feedback as fast as possible. This includes compiling, and executing tests. Solutions with multiple projects affect the fast feedback loop.

Logical boundary != Physical boundary

An assembly is a unit of deployment in .Net. A Visual Studio project has a 1 on 1 relation with an assembly. We should have boundaries in our solutions, but we should not confuse logical boundaries with physical boundaries. A project in Visual Studio creates a physical boundary; this is often needed, but also open to abuse. Physical boundaries are all about deployment and versioning. If you are not deploying and versioning a part of your code independently, there is no reason to create a physical boundary. Multiple layers != multiple assemblies.

Dependency management

I don't want to reference System.Web across all code, so I create a separate assembly where I "isolate" the code that depends on that assembly. When I hear this argument, most of the time it equates to distrust among team members. Or, I don't trust other developers, so to avoid them referencing System.Web on business classes, I segregate them in another project that does not reference System.Web. Can you hear yourself? There may be a compelling reason to isolate a dependency in a separate assembly, but the reason should not be: to avoid other developers making a mess.

How do I do it?

My solutions start with two projects one for production code and one for tests. The question to ask before creating a project is: Do I need to deploy and version this part of the code independently? Only if the answer is yes do I create a new project.

Conclusion

This subject has been discussed in the community for a long time but I still don’t see any change. I’m continuously faced with solutions with dozens even hundreds of projects. In fact I would say this is the norm, unfortunately. I still see shocked faces, when I propose rearranging a solution using folders and namespaces instead of projects. So I’m adding my voice to other voices.

Some authors propose a number between 15-20 maximum projects in a Visual Studio Solution to be a good compromise. I disagree; my proposal is one for production code and a separate project for tests. Adding any other project to a solution should be considered very carefully.

Thanks to Tom Male and Eric Li Koo for reading drafts of this.

References

http://ayende.com/blog/3158/the-two-project-solution http://geekswithblogs.net/FrostRed/archive/2008/10/03/125628.aspx http://codebetter.com/jeremymiller/2008/09/30/separate-assemblies-loose-coupling/ http://www.hanselman.com/blog/AssemblyFiefdomsWhatsTheRightNumberOfAssembliesLibraries.aspx https://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio-solution-file/

About the author

Pedro is a software craftsman with over twenty years experience. Passionate about the web, distributed systems and mobile technology. Advocate of agile practices and the software craftsmanship movement. Has been key in bringing Software Craftsmanship practices into several organizations.

Member of developer groups such as: London Software Craftsmanship Community, NSCoders and Agile Barcelona. Frequent speaker on subjects such as: Software Craftsmanship, web and mobile solutions.