Is it a better idea to dump 'utility' classes that are shared by multiple projects into a single utilities library, or to create many small assemblies each of which has to be loaded by the projects that use them?
I don't really like the idea of utility libraries, and you get a total mish-mash of functionality, but on the other hand having 20 dlls which each contain a single piece of functionality doesn't seem like a great solution either.
Is there a third way?
EDIT: This is using .net
I tend to put utilities into one (or a few) bigger assemblies, but work with namespaces to get a clear structure among them.
Depends how you will want to have your work distributed to your developers. It also depends if you want to reuse some of the classes later. And – if you have an utility class that is used in one single point in whole application – this is no longer utility class…
I would go with one assembly, with namespaces.
Be vigilant about what goes into the utilities library when including in a lot of projects. Else you will be confronted with something like this.