Is a solution with hundreds of projects dangerous or just unwieldy?

Question

our main client solution has 111 projects. When I first started on this team I was surprised (and alarmed) that we had so many projects and recommended consolidating the tiers into less but larger assemblies. our structure has models (DTOs) with nhibernate mapping files, and WCF services tier with data controller calls, some framework type projects, and a winform CAB app with multiple modules. we will be using click-once deployment.

because of the build time (up to 15 minutes worst case) some other team members are now concerned as well. I don't have empirical evidence that less projects are a good idea and was wondering is the stack overflow community had any feedback. Is there compelling reasons to alter our solution structure to consolidate projects? will we run into trouble having 100+ assemblies deployed using click-once? Does more assemblies cause slowness when loading and invoking method calls? Any limits we might run into that could corrupt things?

Answer 1

The biggest problem with having many projects in a single solutions (in particular when there are many interdependencies between the projects) is that the compile time will slow down real quick. I have seen compile times go to several minutes to tens of minutes when project numbers grow this large.

Application startup may suffer as well, if 100 assemblies need to be loaded and initialized. This of course assumes that all 100 assemblies are needed by the application.

Such a large number of projects hints at code organization problems as well. I would call this a definite code smell. It looks like an attempt at decoupling that goes beyond the reasonable - a bit of architecture astronaut-ism, at a guess.

I would not worry about the deployment story, as deploying one assembly into a directory is not much different from deploying 100 into one directory... Of course, deploying 100 assemblies via the web will be slower (100 connections instead of 1, probably the have a larger size...).

There are tools that will merge multiple assemblies which can help with this - the best known is from Microsoft - ILMerge.

A bigger issue to worry about, when coming to deployment is in configuration and getting it right, especially if most assemblies need their own configuration.

Answer 2

I don't think there will be any problems once everything is compiled and done.

That being said, just from personal experience I know that lots of projects can kill your efficiency. On my (moderate power) machine, with many projects in a solution it will take a long time just to load visual studio. Also, when it takes almost a quarter of an hour to compile your work-flow and concentration will be broken (even more so if you decide to do something else while you wait).

Answer 3

In a gist: Deployment would be the least of your worries.

The real problems you would be facing apart from longer compile time are : >> probable build ineffciency and reduced developer productivity.

Depending on the kind of automated build setup you have ... a failure in a discrete set of solutions in the same projects coupled with frequent check-ins across a brad base of developers ...are bound to give you (if not already) a series of build failure nightmares.

Here is what you can do to mitigate:

1. Based on level of dependency you can glean out the least dependent projects. For instance, if Project A has the least amount of code churn...it merits to be separated out with a automated assembly reference...depending on the build solution you are using.

2. Also, a trivial tip, Devs could just load the projects they are working opn..for faster and efficient startup.

3. If you have a multi-environment deployment setup like : DEV, UAT, STAGE, MIRROR and PROD..transitioning the configuration correctly every time would also be a royal pain. So, you can move all non-trivial configuration to the DB level...and keep cleaner config files...using them for only absolutely necessary entities.

Answer 4

It is possible that the benefits sought by the the person who chose to create 110 projects can be achieved with 110 namespaces in one .dll.

The large number of dll's makes it more obvious when dependencies start to creep (1 dll references 22 others), but that is also true with namespaces (if you don't have a using statement, then it there is build in discouragement to reference lots of other namespaces.

Also when you merge assemblies, you lose "internal", and may want to make some methods less visible than they were, which is a good thing anyhow.