Open Source .net libraries that make your life easier

Even though people sometimes claim that open source .net is not in a healthy state and that the community too often relies on what Microsoft is providing, there do exist some awesome open source libraries out there. Over the course of the last couple of years, we've started several - often small scale - new projects at work and I've come to rely on some libraries that solve some specific problems, and they solve them well. This post is not about packages that are in NuGet's top 100 list, but about lesser known libraries that deserve some extra attention.

Are there some things they have in common? Yes!

  1. Most of them have excellent documentation, time and time again this turns out to be extremely important for any OSS project, especially go get starters on board.
  2. These libraries are not frameworks in the sense that they don't force you into any application structure or require you to inherit from class X or Y. They are just nice libraries that you can plug into your projects and they do what they promise.

So let's get into it...


Hangfire is a library that allows you to quickly and beautifully add background processing to your application. It's extremely simple to setup and scheduling background work is as straightforward as it can be.

BackgroundJob.Enqueue(() => Console.WriteLine("Simple!")); 

There are several things I love about Hangfire:



Shortly after the Razor View Engine came out for, Andrew Davey had the excellent idea to start using it to do Email templating: Postal was born. The idea is simple, your Views folder gets an extra subdirectory called Emails where you put in all your Razor Email templates and everything Razor has to offer comes for free: Layouts, strongly-typed models, Url-helpers, partials, etc. Sending an e-mail is as simple as

dynamic email = new Email("Example"); // Uses Views\Emails\Example.cshtml
email.To = "";
email.FunnyLink = DB.GetRandomLolcatLink();

You basically create a Email object and treat it as a dynamic, you chuck some properties onto it, which you can then inside your Email template.

To: @ViewBag.To
Subject: Important Message

You wanted important web links right?
Check out this: @ViewBag.FunnyLink


Of course you can use strongly-typed Models if you want to.

It respects Web.config's smtp settings and hence works perfectly with services like Mandrill or Postmark, has some nice features like image inlining, and it is built to integrate perfectly with any MVC version. Good stuff!


Whether you're in a console app, a web application or a windows service, reading from your app.config's and web.config's application settings is never a fun thing to do, especially if you want to read DateTime or int values.

Formo solves this problem very elegantly by simply exposing the settings as a dynamic object. This makes the code to read the settings much easier on the eye.

dynamic config = new Formo.Configuration();

// This simply reads the string
string apiEndPoint = config.ApiEndPoint;

// This converts the value in to an int, no 
// need to do any conversion in your code
int timeout = config.ApiTimeout<int>();

// This uses a default value of 5 if the
// configuration files contains no values
int retries = config.ApiRetries<int>(5);

If you don't like dynamic, you can even go a step further and bind the application settings to a simple POCO class.

public class Settings
    public string ApiEndpoint { get; set; }

    public int ApiTimeout { get; set; }

dynamic configuration = new FormoConfiguration();
Settings settings = configuration.Bind<Settings>();

Even though Formo's scope is very limited and even though it seems that reading configuration files will change drastically with aspnet5, I find it a very useful library which for me has reduced the friction of reading config files perfectly.


When dealing with data from legacy systems, then CSV files are still commonly used as the way to export data. In the past I have used several different ways of dealing with these files: copy/paste from codeproject (yeah, I know), hand written CSV reader for specific format, etc.

Until I bumped into CsvHelper, that is. The feature that I love the most, is how you can define a CsvClassMap to populate a certain POCO class. You can then use a CsvReader to convert each row into an instance of that POCO class. That way, you don't have to think about all the nitty gritty details that can occur when you need to read CSV files. These class maps provide a lot of configuration options and I have yet to encounter a situation that CsvHelper cannot handle.


Writing a Windows Service is a lot harder than it should be. The logic itself is the easy part, but writing and configuring the part that creates the service on the system is just a mess. If you follow the Visual Studio Way of doing things, this mess involves

You get the gist, it is overly complex and involves too much automatically generated code and magic strings. Compare this to the beauty of a Topshelf service.

public static void Main()
    HostFactory.Run(c =>
        c.Service<BookSyncService>(s =>
           s.WhenStarted(tc => tc.Start());
           s.WhenStopped(tc => tc.Stop());


        c.SetDisplayName("Book Sync Service");
        c.SetDescription("Sync books");

The result is a simple .exe file that you can use to install, uninstall, start and stop your Windows Service. To install it you simply go to the command-line and execute

.\yourservice.exe install

and the service will be configured in the Windows Service registry. Other operations are very similar and you can find more information in the full reference.


At first sight none of these libraries do something spectacular. They do however make your work lighter by simply taking care of some very mundane problems like background processing, reading CSV files or creating a Windows Service. And this is where there value comes from: they allow you to focus on the real challenges of your application. And as cheesy as it may be, that's a beautiful goal.

comments powered by Disqus