14

All is in the title :)

Currently, we have a VS2005 solution with 20+ projets. Like

MySolution
MySolution.Modules.Foo
MySolution.Modules.Bar
[insert many here]
MySolution.Modules.Baz

Can there be a harm to "merge" MySolution.Modules.* in one project ? All namespaces will be preserved, so no problem here.

But is there anything I didn't think about ?

Note : Currently, there can't be circular references : if MySolution.Modules.Foo references MySolution.Modules.Bar, MySolution.Modules.Bar can't reference MySolution.Modules.Foo. So we'll have to be careful not to create some.

mathieu
  • 30,974
  • 4
  • 64
  • 90

5 Answers5

15

I have been in a couple of companies where having far too many projects has been a pain in various ways. I haven't yet been anywhere which had too few projects, although that's certainly possible.

Think about a project as a unit of reuse, amongst other things. Is any product going to need Foo but not Bar, or vice versa? If not, merge them together.

I like to keep different layers (presentation, business logic, data access) apart, and it's nice to have a common, product-agnostic utility library, but that's about it in many cases.

Oh, and keep tests in a different project to your production code, of course :)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
11

Advantages of one assembly:

  • potentially perf
  • potentially easier deployment

Advantages of many assemblies:

  • Everything else. Assuming these are good cohesive modules, it helps with separation of concerns, keeps dependencies in check by forcing you to think about levelling/layering of your architecture, etc.
Brian
  • 117,631
  • 17
  • 236
  • 300
  • Doesn't having many small assemblies slow down visual studio performance? And doesn't each individual assembly have overhead in it when creating the metadata and debugging symbols? – Meyer Denney Jan 19 '17 at 19:28
5

We use ILMerge to bind up all our little assemblies into a larger block. Especially assemblies that are in different projects but are ultimately part of the same name space.

For example, we have a lot data entities for records and views spread over a number of assemblies, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll etc. but in the end we use ILMerge to put bind them together into a single MJ.DE.DLL. - makes updating/synchronizing the app easier as there are fewer piecesto fiddle with on the production server and we know that all the related classes come from the same compile.

MikeJ
  • 14,430
  • 21
  • 71
  • 87
3

Compile time. If you have your project broken into pieces, only the piece that was modified needs be compiled. If it's all part of one big project, you'll have to recompile everything any time you change something. Depending on how big your project is, this can be a big deal.

Kevin Babcock
  • 10,187
  • 19
  • 69
  • 89
  • 1
    I've never seen this be a big deal for C# projects. To the contrary, the MSBuild overhead seems heavier than the C# compiler at times. (This is completely anecdotal evidence btw.) – Sam Harwell Jul 28 '09 at 05:40
3

For one thing, Visual Studio starts taking longer and longer to load your solution if you have tons of projects, as opposed to few projects with tons of code in them.

This is not necessarily a good enough reason to just have one project, over all the others mentioned here, but something to keep in mind.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • I've heard this before, but never experienced it. Can you define 'tons'? I have a solution with > 50 projects and it loads like lightning. – Kent Boogaart Feb 20 '09 at 09:25
  • 2
    There might be other factors involved. We're using TFS and it might spend time refreshing source control status, but our solution contains 45 projects and can consume a good 30 seconds to load at its worst. Granted, not much, but tests shows this is linked to number of projects. – Lasse V. Karlsen Feb 20 '09 at 10:15
  • 1
    @Kent, I've been there and felt the pain – johnc Jul 28 '09 at 05:20