What to include in a Utility Library

Question

With more and more projects under my belt I find that I am often repeating many common tasks from project to project, client to client. So I have started to assemble a "utility" library, a collection of these common elements that are often repeated from project to project.

So far I have utilities to resize images, export data grids to excel, send e-mails, and replace tokenized messages.

If you were building/using a .NET utility class library, what types of processes would you see as helpful? What namespaces/groups would you envision?

Update

I am talking about an actual class library, separated into namespaces to group common elements.

Answer 1

Personally, I would put some of this functionality into separate libraries, as "utility" is a rather subjective term, what one person finds helpful is not so helpful to another.

If within the library it was broken up into descriptive namespaces, then I would say that's better (e.g. resize images would be in some sort of .Drawing namespace, or in a .Drawing.dll).

Answer 2

1. I wouldn't write a library called 'Common' or 'Utilities' or 'Misc' or... You get the idea. Instead, I'd have a directory called 'Lib', and have each area of functionality in a separate library under that. For example, I might have Lib/Trace, Lib/UI, Lib/Net, Lib/Web for a C++ project. For C#, I'd have Lib/Acme.Trace, Lib/Acme.Windows.Forms, Lib/Acme.Net, etc. (assuming your top-level namespace/company is called 'Acme').
2. YAGNI. Don't go writing code that you might need.
3. Don't throw things into a shared library until you've used them in two or more projects.

Answer 3

Though I am just a fledgling developer myself I have found RegEx functions and SQL filters to be quite useful. I also have Merge Replication functionality for MSSQL that has been quite handy for me so far.

Answer 4

I have plenty of things in my class library which I share between projects:

• IoC container and dependency injection framework
• A full controller/observer framework, allows me to separate UI code from backlogic code
• A reasonable database-independent set of classes for executing SQL, takes care of some of the syntax differences, mainly function names
• Lots of other helper classes and utility methods for dealing with data
• Some standardized internal storage classes, like Tuple<..> etc.
• Some custom collections, like Set<T>, Heap<T>, as well as plenty of utility methods for dealing with various types of collections

The class library is added to when I need more stuff.

Answer 5

I'd suggest that instead of a "utility" library just make domain specific (graphics, authentication, validation, etc) libraries and only include them where they are needed. The key of course is decided how specific to be. More specificity is generally better.

Irregardless if it has no domain then you probably don't understand it fully meaning that you should re-evaluate what you are doing and trying to accomplish first.

Also, remember that what is useful in one or two projects may end up only being useful in one or two projects. Adding more classes than necessary only causes maintenance issues down the road.