CODEWITHSUNDEEP
.netasp.net
Achilles
Achilles

Reputation: 11309

Are applications with many DLLs a bad thing?

We have an enterpise web application that did consist of 4 compiled components (DLLs). Over a year ago, we began implementing more granular components in an attempt to isolate functionality, reduce coupling and reduce the risk of recompiling and deploying massive chunks of code. While no one argues that this approach has given us MUCH improved flexibility and speed to market when adding new functionality and patching bugs, the applications now consists of nearly 40 dlls. We have a naming convention that works well for identifying our components.

My question is: Is there any down-side(Performance, maintenance, etc...) to having an application with many dlls?

Edit: We are exploring the option of refactoring code into larger components which I think might be a regression of sorts...

Upvotes: 25

Views: 5281

Answers (5)

Stephen Cleary
Stephen Cleary

Reputation: 456687

Don't forget about ILMerge. It works quite well if you want the multiple DLLs for development (different projects) but one EXE for deployment (faster to load, easier to deploy).

The downside of ILMerge is that it'll fail in some dynamic loading scenarios, e.g., creating an instance of a type by (string) name. So, ILMerge may or may not be feasable, depending on your IoC provider.

Upvotes: 4

LBushkin
LBushkin

Reputation: 131726

Separating independent functional domains into individual DLLs is generally a good thing. It helps introduce the potential for reuse and help mitigate the introduction of inappropriate coupling between the internal implementations of classes.

However, there are downsides to introducing multiple assemblies as part of a system:

  1. It takes longer to load, verify, and JIT multiple assemblies. This is rarely a problem, however - and should generally not be your primary concern in deciding how to partition the functionality of an application.
  2. It can be unwise to update an application by deploying changes within a single assembly. Often dividing an app into separate DLLs creates the impression that its possible to fix or enhance it by replacing just some of it's assemblies. While it's certainly possible it can introduce subtle bugs if there are changes in side-effects or undocumented behaviors of the classes and methods in those assemblies.
  3. It can be harder to understand a system that is divided into too many assemblies. Tools like ReSharper and CodeRush have some limitations when analyzing code divided across multiple assemblies.
  4. It can encourage developers to make more types public than they should. Since only public types can be consumed and inherited by other assemblies, a multi-assembly project can result in more public types than may be desirable.

Upvotes: 12

Henk Holterman
Henk Holterman

Reputation: 273284

My question is: Is there any down-side(Performance, maintenance, etc...) to having an application with many dlls?

A downside with many DLLs ? No
A downside with too many DLLs ? Sure.

So how many is too much?

An assembly is an means of organization, like namespaces and classes. Namespaces define logical boundaries, assemblies physical boundaries.

You should try to keep assemblies coherent, and view them as system modules.

And yes, there would be a (small) performance problem if you had hundreds of them. But with 40, I don't see a problem.

Upvotes: 16

Tim Robinson
Tim Robinson

Reputation: 54744

The sorts of issues that get worse with more DLLs are:

  • Build times: the compiler runs once for each DLL, and DLLs must be copied to and from the output directory
  • Load times: each DLL file must be loaded separately by Windows, although DLLs are demand loaded, so you will typically incur cost for only the parts you use
  • Rebasing: the more DLLs you have, the greater the chance that two will collide in virtual memory. This doesn't pose a problem, because Windows can rebase one of them, but the rebasing process takes time, and Windows must load any affected DLL pages from disk in advance. Rebasing doesn't typically affect managed DLLs much.
  • Visual Studio overhead: one DLL = one project = more work for the IDE

The advice I follow is to use DLLs to organise your deployment, and namespaces to organise your code. If you find that you always release a given set of DLLs together, you might as well merge them.

Upvotes: 6

Darin Dimitrov
Darin Dimitrov

Reputation: 1038930

Maintenance - no, performance - yes. The more assemblies that need to be loaded the slower your application will start. For each assembly that needs to be loaded into the AppDomain the loader needs to perform a series of verifications.

Upvotes: 7

Related Questions