C#

Flexible integration tests with dacpac support

Integration tests are an important aspect of software development, high code coverage does improve code quality. But the tests need to be flexible and fast so they do not hinder the developers in their daily work. On the build server speed doesn’t matter that much, but a good test suite must be fast enough so that the developers choose to use it instead of running the system manually to test their features. Thats how you get good code coverage. Sadly publishing a dacpac is anything but fast. But there are clever tactics you can apply to make it work good as your daily testing platform.
(more…)

Advertisements

Build server – client contracts with dotnet CLI

Now days type safety is common within the web-world with TypeScript and on the horizon WebAssembly with .NET Core (Blazor etc). I have for a long time advocated for the importance of this, especially when we are talking the contract between server and client. For example this T4 template that spits out C# CQS types as javascript.

T4 doesn’t play well with Dot Net Core, but we now have the dotnet CLI toolset we can use instead.
(more…)

Client – server event aggregation with SignalR ASP.NET Core

Event aggregation is really a pattern i like, there is something elegant about firing events and subscribers can listen to them without knowing who fired them. This creates decoupled domains both in backends and frontends. Back in 2013, at my customer of that time we saw an increasing demand for pub / sub and immediate update. We fired events on the backend event bus and in the frontend we had SignalR Hubs that picked up the events and forwarded them to the clients. This caused duplicated and similar code both on the client and on the web server. I decided to create an abstraction layer between SignalR and the event aggregator. The result is a library called SignalR.EventAggregatorProxy

It has now been ported to support ASP.NET Core, this article will focus on the changes, for the orginal article go here.

(more…)

SQL CE and namespaces

We use SQL CE in our unit test project to test our EF6 queries. This works pretty well and Code first setup makes sure each test gets a fresh CE database to work with.

We ran into a problem where two EF types had the same table name but inside different schemas. CE does not support schemas and this resulted in naming conflicts when setting up database. My solution was to create a little convention.

public class BakeSchemaIntoTableNameConvention : IStoreModelConvention<EntityType>
{
    public void Apply(EntityType item, DbModel model)
    {
        var entitySet = model.StoreModel.Container.EntitySets.Single(es => es.ElementType == item);
        entitySet.Table = $"{entitySet.Schema}_{entitySet.Table}";
    }
}

It bakes the schema into the table name like dbo_MyTable. You add the convention like.

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Conventions.Add<BakeSchemaIntoTableNameConvention>();

    modelBuilder.Configurations.AddFromAssembly(typeof (MyContext).Assembly);
}

You do not want to add this for production code so what I did was create a public event on the context. And call it from the OnModelCreating method.

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    ModelCreating?.Invoke(this, modelBuilder);

    modelBuilder.Configurations.AddFromAssembly(typeof (MyContext).Assembly);
}

Call it from your Unittest project like.

ctx.ModelCreating += (s, e) => e.Conventions.Add<BakeSchemaIntoTableNameConvention>();

Microsoft.Rest.ServiceClient opt out retry

If you use Swagger generated REST proxies then you have probably come across the pretty new Microsoft.Rest namespace and namely the abstract class ServiceClient. I noticed a strange behavior when using clients that subclass this base class. The default behavior for this class is to retry when a 500 status code is returned.
I can not understand the reason for this being Opt out, its obvious a feature like this should be Opt in. So keep in mind when using this class you must always call SetRetryPolicy to disable the retry strategy.

var service = new MyService(uri, credentials);
service.SetRetryPolicy(new RetryPolicy(new HttpStatusCodeErrorDetectionStrategy(), 0));

Task.WhenAny with take predicate

Not a very common scenario but still it happens, you want to execute a request to several Services, and only one has the correct data. The built in Task.WhenAny only supports to await the first Task complete. That wont do if you want to wait for the first Task to complete that satisfy a specific condition.

Nito.AsyncEx is a helper library for Task programming, it comes with an extension method called OrderByCompletion. It takes a collection of Task<T> and return a new collection that will be ordered on completion status. Using this method its a simple task to create a WhenAny based on a predicate.

public async static Task<TResult> First<TResult>(this IEnumerable<Task<TResult>> source, Predicate<TResult> predicate)
{
    var ordered = source
        .OrderByCompletion();

    foreach (var task in ordered)
    {
        var result = await task;
        if (predicate(result)) return result;
    }

    throw new Exception("Sequence contains no matching element");
}

Used like

var result = await services
   .Select(s => s.GetFooAsync())
   .First(f => f.IsSuccess);
}

Parallel executed Tasks with isolated scopes

My current customers infrastructure is heavily dependent on external suppliers of data. Because of the nature of the data the system often have to-do the requests in real time while the end-customer is waiting for the response. Parallel tasks comes in handy when you want to aggregate data from several end points, both because it puts less strain on the Thread Pool and that your response time will be faster because you do not need to wait for each to complete (Parallel vs Sequential).

The problem starts with frameworks that does not play nice with sharing their resources over multiple Tasks/Threads, an example of this is the Entity Framework DbContext. One way is to marshall the lifetime of the context yourself and spawn one for each parallel task. But this is not a solid design, if you use a IOC you want any object in the current graph to receive the same instance of the DbContext without bothering with lifetime code. I created a little class called TaskRunner for this purpose (more…)

Abstract DI container Scopes

I¬†saw an increasing demand for mini workflows / domain sub-parts in one of my projects. Most containers have some kind of support for sub scopes or nested containers, but I do not want to expose the Container API. If you have few places were you need nested containers you can implement this directly for your container of choice. An example of this is a container specific implementation of Web API’s IDependencyResolver. But in our case we had several different needs for scoped contexts near the domain. My solution was to abstract the context in a interface IScopedContext. (more…)

Entity framework 6 and fluent mapping

If you google for EF and fluent mapping this is the first hit you get which is not strange since its the official MSDN page about fluent mapping in EF6.

They only discuss overriding the OnModelCreating method and configure the mapping inline in that method. And this is the most common way of dealing with fluent mapping out there in the community. But there is a much better and seperated way of doing it which MSDN fail to show.

System.Data.Entity.ModelConfiguration.EntityTypeConfiguration

This little class is your salvation when working with Fluent mapping in large enterprise systems. Implement it like. (more…)