Advantages and Disadvantages of Packaging Code as Single DLL

Question

I am trying to figure our what is the appropriate granularity for code libraries. Specifically, I want to work out if all my general code libraries should be rolled into a single DLL, or if they are better separated into separate DLLs, one for each discrete area of functionality.

Background

I have a a set of code libraries that are shared across applications. They include code to manage database access, read configuration from our centralized configuration repository, perform standard transformations on data from external sources, and a whole lot of other things besides. Some of these libraries have dependencies on others (e.g. database access depends on configuration repository code). Others are fairly independent. Some applications need all the code, but most just use a sub-set (where the sub-set differs between applications).

If it matters, I'm a C# developer, working on enterprise scale applications.

Approach

To help me figure out what I should do, I started to make a list of the advantages and disadvantages of each approach. Unfortunately, this has yet to reveal a clear winner:

Advantages of One Big Library

• Only need to add a single reference to client applications.
• Only need to update one DLL when bugs need to be fixed or functionality extended.
• There are less files to deploy, so hosting servers end up looking 'neater'. ie. they typically end up with an executable and a "sharedlibrary.dll" file in them.

Advantages of Multiple Small Libraries

• Applications don't need to drag around dependencies on functionality that they don't need.
• Dependencies are explicit, so it is easy to see what depends on what.
• The DLL names indicate the kind of code they contain.

My Question

What other factors should I consider? Have I missed any significant advantages / disadvantages of either approach?

Answer 1

Here are a few reasons to separate a piece of code into a separate DLL. I am sure there are more.

1. The code doesn't change very often, or changes more frequently, and thus would benefit from the ability to be deployed on different time tables
2. The code is managed by a different team, e.g. your team in India, and they have their own build server
3. The assembly needs different code level access permissions
4. The code has a different EULA, intellectual property, or distribution scheme
5. The code contains sensitive items, e.g. cryptographic keys, and needs to be deployed in a different location on the server with less access permissions
6. The code contains remotable items and can be deployed on a different server to improve performance or access resources
7. Your solution has the ability to bootstrap and update DLLs when a patch is released
8. Your code utilizes the internal keyword to help with control of scope
9. You are using satellite assemblies to support globalization
10. Your build times are very long and you'd rather be able to build the solution in smaller bites
11. You wish to target different versions of the .NET framework