Disadvantages and Advantages of separated projects/DLLs in .NET? How many of them are too much?

Question

The question involves some other related questions, I'll just throw every single on of them feel free to answer one or many of them.

• What are the advantages of separating Projects/DLL?
• What are the disadvantages of separating Projects/DLL?
• If I create a new solution/DLL for every shareable resource, isn't going to be lots of projects?
• After too many projects (like 40+) is this going to have some bad effects of IDE performance (VS.NET 2008)?

I'm asking this question because I've got this big solution with so many different classes and because now I need to separate some interfaces it's all falling apart (circular dependency problem) and now I need to create multiple DLLs, I just want to be sure to do it in the right way this time.

Answer 1

In general, you should have a separation wherever there is a logical separation of dependencies in your code. For example, if you are building a suite of related smaller applications which all rely on a common core, it would make sense to have one library with the core classes and one for each such application. Here's a simple dependency graph that reflects this sort of separation:

         +------------> Core <------------+
         |               ^                |
         |               |                |
   Level Builder         |           Game Server
         ^               |
         |               |
         +-----------Game Client

Finally, .NET doesn't have a great way to have test-only code dependencies except through conditional compilation, so it's also a good idea to have your various tests be in a separate library.

Answer 2

The main disadvantages of lots of dlls are:

• complexity (the sheer number of dlls to manage and deploy)
• performance of "fusion" (which can be reduced using ILMerge)

The advantage is more separation - but actually you can achieve the same (or similar) separation inside a single (or a few) dlls.

---

Re the issue with circular dependencies - you should perhaps look at "dependency injection" and "inversion of control".

Answer 3

I've been battling with the opposite of your problem - too many dlls and dependencies.

I don't know the answers, but here are some questions which might give you some useful pointers.

Structuring projects & dependencies of large winforms applications in C#
What do you do about references when unloading a project in Visual Studio?

Note that you can have different namespaces in the same dll, (and conversely, you can spread a namespace over several dlls).

For my solution-with-lots-of-projects I currently have a set up where I have a custom build configuration (click in the Debug/Release combo and select Configuration Manager) called 'WorkingSetOnly', where I can choose to compile or not each project on Run - this makes running quicker, but conserves intellisense, goto definition etc. I also use Solution Folders to organise projects into two 'buckets' - WorkingSet and Others, though I haven't yet found a way to link the two (config and folders) automatically.

Answer 4

The answer to this question could be very long regarding the scope of the argument, I think first of all it could be better to focus what are the choiches and the reasons that made necessary to separate items in multiple assemblies, and in general this could be in general Design and Layering and/or taking project structure clean.

1. What are the advantages of separating Solutions/DLL?

The advantage of separating solutions and assemblies in general is related to a Design Approach, a code reuse and layers organization, as said, separating solutions helps to share objects/components and to distribute the responsability between layers, promote multi target and pluggable solutions (see for example various storage target assemblies (Database, Files, etc)), testability

2. What are the disadvantages of separating Solutions/DLL?

The major disadvantages, as others said before me, are, first of all complexity (management, maintenance), then performance (but this is another discussion, it's not easy as saying that)

3. If I create a new solution/DLL for every shareable resource isn't going to be lots of solutions?

It depends, first of all I think this could depend on design choiches

4. After too many solutions (like 40+) is this going to have some bad effects of IDE performance (VS.NET 2008)?

I'm not so sure about performance degradation in VS2008 IDE, but sure it could affect performance to manage a single solution of 60+ projects than for instance 4 solutions with 20 projects each.. It must be clear that VS IDE performance could be degraded even after opening for instance 35 files together just from a single or double project solution..

At the end I think the BIG thng to take i mind is that it's better to "build" just what it's really needed than fall in an over-design for instance, so when things became too complex to manage (to many projects) it's better to stop and think "everything's going well?"

Answer 5

Circular dependency problem means:

[Lib1]

[Project1]
  [ClassA]

[Project2]
  [ClassB]

if ClassA and ClassB reference each other, they should be pulled out to Lib1 and have Project1 and Project2 reference Lib1 because it's very difficult to keep Project1 and 2 in sync without doing so.

That doesn't mean go wild and I am sure the IDE performance won't be a huge issue. If you have 40+ projects there is a design problem going on.

Answer 6

Advantages

• Clarity of purpose.
• Ability to replace one dll and have the rest of the application work as before.
• Re-usability (though this is really often overrated*).

Disadvantages

• Difficulty in working with (just shuffling between 7 projects can be a pain).
• Possibility of new types of dependency problems (Project A can reference Project B or vice versa, but not both)
• Lots of DLLs to deploy.

---

In general I suggest using at least one DLL (to separate your business logic from your UI), and more if you'll have different versions of your application that might not need all of that code.

---

*We often make ourselves believe we'll reuse that wonderful Order class. We probably won't. Domain models just tend to be different.