Browsing posts in: Uncategorized

Using a SynchronizationContext in unit tests

We’ve started to use the Progress<T> class in our async application. However our tests started to fail because of that (when validating that our callbacks get invoked). This post will show you how to create a simple SynchronizationContext to make sure that everything is invoked before the assert part is being run.

Continue Reading

The quest to generate the perfect repository – Griffin DAL Generator

The data layer is something really important in an application. If it’s incorrectly created it will behave like a virus and infect the entire business layer making it a lot harder to build and maintain the application. Unfortunately the symptoms will not appear until the project have been built for some time. In this article I’ll present my attempt to a cure.

If you have previously read this blog you’ll probably know that I do not use ORMs. Sure, they speed up the initial development considerably. But time saved in the beginning is lost many times when the application grows and have to be maintained. The reason is that once things start to get complex the ORM will fail on you. It will return obscure error messages, fail in the mappings or not translate the LINQ statements in a way that you expected.

The entire ORM movement was created since you, me and most other devs did not want to spend so much time doing repetitive tasks in the data layer (creating all those CRUD statements and build the mappings/conversions between the DB tables and the .NET classes). However, along that way came a lot more laziness. Now we wanted to do as little as possible in the data layer, at least stuff that had to do with the DB.

Along came HQL, LINQ and other ways of abstracting away (and simplifying) the data layer access. Suddenly we have a data layer that can be compared with ASP.NET WebForms. i.e. It tries to abstract away something and act like something it isn’t. And it does it by trying to create a simple API by doing a really complex implementation.

I got two large issues with that. The first thing is that ADO.NET is in itself really simple. Anyone can write a SQL query and fetch the result. The other reason is that when something fails you have to focus on debugging the ORM instead of just correcting a SQL query.

So when something fails you have to start debugging something complex instead of something really simple. Hands on your heart, wouldn’t you prefer correcting a SQL statement instead of a mapping or invalid LINQ query?

The solution

My alternative is a generator application. It doesn’t sound so sexy (and it isn’t). But the generated code is created using my 20 years of experience in the field as starting point.

The generated code contains everything from my data access articles and is either generated using ADO.NET only or my own data mapper library (still just plain SQL). Thus, there is not a complex library which will obfuscate things or take away the control from you. Thus it’s trivial to adapt the code and to correct problems in the future.

The generates can either create Queries (as in Command/Queries) or repositories. The repositories are either generated as asynchronous or synchronous repositories, while the queries are always asynchronous.





It’s considered beta until 2015-04-30 and is free during this period (100% discount). After that the personal license will remain free while companies have to pay.

More info at the homeopage. I’ll try to implement all feature/change requests that comes in this week.

Sample repository using Griffin.Framework

Here is small sample repository using Griffin.Framework

using Griffin.Container;
using Griffin.Data.Mapper;
using OneTrueError.GlobalCore.Invitations;
using OneTrueError.GlobalCore.Invitations.Data;

namespace OneTrueError.GlobalCore.SqlServer
    internal class InvitationRepository : IInvitationRepository
        private readonly GlobalUnitOfWork _unitOfWork;

        public InvitationRepository(GlobalUnitOfWork unitOfWork)
            _unitOfWork = unitOfWork;

        public Invitation FindByEmail(string email)
            return _unitOfWork.FirstOrDefault<Invitation>(new {EmailToInvitedUser = email});

        public void Create(Invitation invitation)

        public void Update(Invitation invitation)

As you might have noticed I’m using one Assembly/DLL per SQL engine that we support. It’s not required for Griffin.Framework, but we are using plain ADO.NET for some DB operations and Griffin.Framework for others. Thus having one DLL per SQL engine allows us to write optimized queries without compromises.

In v2 of OneTrueError we are using two different databases. One for global activities like billing and customer accounts and then one customer specific DB for each customer. The reason is that we’ve had customers which gets several GB of error reports each month. Thus to make sure that the DB is responsive for all other customers (even when we are lacking a few efficient indexes) we’ve taken this approach.

When OneTrueError is started we simply use Assembly.Load together with a configuration setting in <appConfig> to be able to load the correct DLLs.

Azure trouble

During the last week I’ve discovered that the Azure hosting isn’t working very well. I’ve reported the problem to Azure. If you have had trouble accessing the site, please let me know.

I’m currently loosing about 1500 visitors every month due to an error in the PHP configuration at Azure.

You can track my progress in the azure forum


It’s been two weeks and the closest they got is asking for the PHP log. And that’s after me telling them what the problem is.

Again, do note that I’m using the WordPress image that they have configured and the PHP edition that they have selected. Still they make no real effort in finding the problem, despite that I’m a paying customer.

Hence I’m going to move both OneTrueError and my blog from Azure. Why use something where you can’t get help when it doesn’t work?

Using both signed versions of log4net

Older versions of log4net has been signed with a different certificate than the new versions of log4net. That means that they have different public tokens and regular <assemblyBinding> doesn’t work. This post will show you have you can use both versions side-by-side.

Continue Reading

Griffin Framework homepage

Griffin Framework just got a new homepage.

It’s still basic, but will continue to grow. I’ll also commit it in the “homepage” branch at github. Feel free to add improvements to it.

Simple command line parser

I have tried 3-4 different nuget packages for command line parsing. Didn’t figure out how to use them properly. Here is a small command line parser.

Usage example

Here is how I use it.

internal class Program
    private static void Main(string[] args)
        var parser = new SimpleCommandLineParser();

        if (parser.Arguments.ContainsKey("server"))
            var server = new LoadTestServer();
            Console.WriteLine("Server started");
        else if (parser.Arguments.ContainsKey("client"))
            var client = new LoadTestClient(parser.Arguments["client"][0]);
            Console.WriteLine("All enqueued");
            Console.WriteLine(" - Check the app.config for additional configuration options");
            Console.WriteLine("SharpMessaging.BenchmarkApp -server [port]");
            Console.WriteLine("SharpMessaging.BenchmarkApp -client [host:port]");

        Console.WriteLine("Press ENTER to quit");


And the actual code:

public class SimpleCommandLineParser
    public SimpleCommandLineParser()
        Arguments = new Dictionary<string, string[]>();

    public IDictionary<string, string[]> Arguments { get; private set; }

    public void Parse(string[] args)
        var currentName = "";
        var values = new List<string>();
        foreach (var arg in args)
            if (arg.StartsWith("-"))
                if (currentName != "")
                    Arguments[currentName] = values.ToArray();

                currentName = arg.Substring(1);
            else if (currentName == "")
                Arguments[arg] = new string[0];

        if (currentName != "")
            Arguments[currentName] = values.ToArray();

    public bool Contains(string name)
        return Arguments.ContainsKey(name);


The great thing is that .NET have already done an initial parse for you. You can for instance use quotes in it to get everything in the same argument:

someApplication "this is argv[0]"

My parser parses the following:

someApp -server 8344 arg2


Console.WriteLine(parser.Arguments["server"][0]); //8334
Console.WriteLine(parser.Arguments["server"][1]); //arg2

While this:

someApp server verbose

can be checked as:


i.e. strings that are specified before the first dash argument (“-arg”) will be considered to be an argument by itself.