I have a large solution containing many projects. Due t开发者_如何学运维o the size and number of projects the build times are starting to become unmanageable.
I am interested in learning about any techniques people have used to break the solution down and how they've managed DLLs and project references.
Scott Hanselman has blogged on this a number of times.
Bottom line: 30-40 projects seems to be a reasonable upper limit. Anything more starts to get painful.
Ask yourself, "Do I really need all these projects building and in the solution?"
No? Then consider multiple solutions (e.g. client.sln, server.sln, plugins.sln, etc.)
Yes? Then consider consolidating projects into fewer projects. For example, combine Client.Presenters, Client.Views, and Client.Models into a single Client project. See Benefits of larger but fewer assemblies.
Best to follow Microsoft's recommendations:
Structuring Solutions and Projects
You can break your projects into different solutions and point their Build Output Path (Project Properties -> Build -> Output Path) to one common folder. Add the references between various projects from this common folder. This way there is no need to copy DLLs to various bin folders.
However the downside is that you have to remember the Build Sequence yourself.
精彩评论