Via Eric Gunnerson (also check out the comments on his post):

This useful bit of information crossed my desk today:

When it comes to packaging in separate assemblies, remember that you pay a fairly large performance hit on an assembly load. An assembly should really be considered a unit of security control, independent versioning, or contribution from disparate sources. You might consider placing code in a separate assembly if it is used extremely rarely, but probably not.

Here are some pointers from the "Designing .Net Class Libraries" course:

Factor functionality into assemblies based on:

- Performance - There is overhead in loading each assembly. All other things being equal, the fewer assemblies an application loads, the quicker the load time.

- Versioning - All code in an assembly must version at the same rate.

- Security - All code in an assembly has the same identity and is granted the same level of trust.

Assemblies and Performance

- Prefer single, large assemblies to multiple, smaller assemblies

- Helps reduce working set of application

- Large assemblies are easier for NGEN to optimize (better image layout, etc)

- If you have several assemblies that are always loaded together, combine into a single assembly.