I am very new to Visual Studio and C# and am wondering how best to create a repository of sorts for utility methods.

For instance, we need a method that returns the current fiscal year and other company specific values.

Would it be best to create utility class file that is imported into every project? Or, create a new project with the these methods and add it to the current solution?

In python, for instance, I created an egg that has all the utility methods that I then install into the site-packages.


Create a new project and import it into needed solutions. This way you can let it have its own solution and add an additional project for unit tests.

  • When you say "import it" are you promoting referencing the DLL or the project? Having multiple copies of the project is going to cause issues. – StuperUser Nov 2 '11 at 23:02
  • 3
    @StuperUser: Even if you reference the project itself, there's still only one copy of it. Obviously you have to rebuild all the dependent projects/assemblies if you've made a significant change, but that is true no matter how it's referenced. – Aaronaught Nov 2 '11 at 23:57
  • @StuperUser: I prefer referencing the DLL over importing the project, but Aaronaught is correct about having to rebuild it either way. – Michael Wheeler Nov 3 '11 at 14:34

I fabour creating "Framework" dll's in a seperate project/solution and referencing when needed, keep it backwards compatible with its own unit tests etc. If the requirements are domain specific then create another project within the current solution.


I'd create a project that has all of the utilities, and you reference that in other projects.

I'd put company-specific things in a separate project again.

You can include the same projects in many solutions; you just have to be careful about making changes that could break usages in other solutions.


My suggestion is to not worry about it until you have to.

Create your utility methods and place them into an appropriate class in the project that requires them. I might create a FiscalYear class, and separate classes for each area within the "company-specific values". Do not create a single class just to hold "company-specific values", since the only thing those values will have in common is that they are "company-specific".

When you get a second project that also needs access to the same classes, then is the time to create a third project to hold those classes that are in common between them.

  • Might be too late at that point. I find that doing it properly from the start is better than later on, especially when one forgets to do it later or the task itself is of low priority. – Bernard Nov 2 '11 at 19:01
  • Personally, I find the opposite. It's best not to plan these things too far ahead, or you'll find you've planned for things you didn't actually need. – John Saunders Nov 2 '11 at 19:29
  • True, that might be the case,. It obviously depends on the situation. However, I try to plan ahead anyway for these kinds of "unexpected surprises". – Bernard Nov 2 '11 at 19:45
  • 1
    Good luck. Over 35 years of experience tell me that planning very far in advance is a waste of time. I just 1/2 hour ago got a request to delete a stack of "planned" TFS work items which turned out to be total fiction. I only hope those who created them learned the lesson. – John Saunders Nov 2 '11 at 19:48
  • I hear you. Experience is a good teacher. – Bernard Nov 2 '11 at 19:59

We have a large suite of web applications in our team and faced the same issue. We came up with a very high-level generic "Application Utilities" library. This contains project agnostic utlity functions/classes. So (as you suggested) date utlities, things that replicated some of the old VB functions I missed (String.Left, String.Right etc) and that kind of thing.

For each specific project we have a BusinessLayer assembly which contains various project-specific logic. It is not uncommon to find a "Utlities" namespace within this project. This would contain various functions specific to the context of the application.


If the data will change, it should be stored in a data store (database, XML, CSV, etc.) and not in code. For example, fiscal year keeps changing and if you store it in code or DLL, you will have to change the version every year to hard code the new value.

You can use this suggestion together with @marc's and @Bond's notes above to get a complete answer of your question.


Don't forget its a Anti-Pattern. Therefore better to rethink about your solution http://lostechies.com/chrismissal/2009/06/01/anti-patterns-and-worst-practices-utils-class/

  • Where should a method to e.g. compare a range of one byte array with a range of another be placed? How about a function to take a pair of double values x and y, and compute the square root of (x²+y²), if a framework does not already include such methods within its utility classes? – supercat Mar 11 '14 at 21:21
