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.