Friday, January 13, 2017

ASP.NET Core MVC–Register a global authorization filter

ASP.NET Core MVC still supports the concept of action filters. On the project I’m currently working on I wanted to add a global Authorization filter.

So similar to ASP.NET MVC, I tried to add the AuthorizeAttribute as a global filter:

However this didn’t work. In ASP.NET Core MVC the Attribute class and the filter implementation are separated from each other. Instead I had to use the following code:

Thursday, January 12, 2017

Enums alternative in C#

While reading the following blog post( I noticed this code snippet:

This code is taking advantage of the Expression-bodied function members in C# 6. And although this is just a static class with some readonly properties I found it aesthecially pleasing and it looks like a useful (and more flexible) alternative to enums.

If you look at the syntax you had to use before, it just feels more like a normal class instead of an enum construct…

An alternative approach would be using Getter-only auto-properties but it doesn’t feel the same as well…

Wednesday, January 11, 2017

CQRS: Building a pipeline using MediatR behaviors

I recently started a new project where we are using MediatR to simplify our CQRS infrastructure. This gives us our basic building blocks to create our queries, commands and the related handlers.

One of the things I wanted to add were some decorators to provide some extra functionality(like authorization, logging, transaction management,…) before and after a request. Turns out I’m lucky as with the release of MediatR 3.0 I can fall back to a built-in functionality called behaviors.

Similar to action filters in ASP.NET MVC, it gives me the opportunity to execute some arbitrary logic before and after a request(command/query). Usage is simple:

  • You have to implement the IPipelineBehavior<TRequest, TResponse> interface:
  • Don’t forget to register the pipeline behavior through your IoC container(StructureMap in the example below)!
Note: As I’m registering this as an Open Generic this behavior will apply to all my messages.

Tuesday, January 10, 2017

Formatting strings in F#

As F# is build on top of the CLR and has access to the same Base Class Library you can use String.Format as you know from C#.

A (better) alternative is the printf function in F#. Be aware that the printf function(and its relatives) are not using the composite formatting technique we see in String.Format but use a C-style technique instead.

This means that you don’t use positional placeholders like this:

String.Format("A string: {0}. An int: {1}. A float: {2}. A bool: {3}","hello",42,3.14,true)

Instead you use C-style format strings representing the data types(e.g. %s for string):

printfn "A string: %s. An int: %i. A float: %f. A bool: %b" "hello" 42 3.14 true
What makes this approach really nice is that it adds an extra layer of type safety on top of your string format. If you expect a string parameter but provide an integer, you’ll get a nice compiler error.
But maybe you are wondering; what about string interpolation, a nice feature added to C# 6? Unfortunately this doesn’t exist (yet) in F# although a Language Specification is available(

More information:

Monday, January 9, 2017

F# printfn error

I tried to write out a message to the command line using ‘printfn’. Here is my code:

Unfortunately this code doesn’t compile. Here is the compiler error I got:

The type 'string' is not compatible with the type 'Printf.TextWriterFormat<'a>'

How hard can it be to write a simple string message? Sad smile

The problem becomes obvious when we look at the signature of the printfn function:

printfn : TextWriterFormat<'T> –> 'T

The function didn’t expect a string but a TextWriterFormat<'T>. The compiler has no clue how to convert our string variable to this type.

To fix this you should specify a format specification(%s in this case) and your variable:

Friday, January 6, 2017

Free ebook: Defending the New Perimeter – Modern Security

Right on time! Just before the weekend starts, a new (free) ebook was released giving you a whole weekend to digest it.

“Defending the New Perimeter: Modern Security from Microsoft” is a guide to the Microsoft Cybersecurity Stack for IT Decision Makers written by Pete Zerger and Wes Kroesbergen.

Brad Anderson(Corporate Vice President at Microsoft) wrote the introduction and summaries the book like this:

“In "Defending the New Perimeter", Wes and Pete will explain how the components of Microsoft's defense stack work together seamlessly – backed by the rich intelligence of the Microsoft Intelligent Security Graph – to deliver the best possible protection for your infrastructure, devices, applications, and data. I think you will find it to be a great resource to acquaint yourself with Microsoft's approach to modern security for the hybrid enterprise. ”

A must read for CIOs, CISOs and IT professionals who care about security.

Download the ebook here(registration required).


Thursday, January 5, 2017

Running MsTest unit tests for your .NET Core code

To be able to run unit tests for your .NET Core code, Microsoft created a new version of the MSTest Framework with support for .NET Core. This version is still in preview yet but provides both testing support from the commandline(through dotnet test) and through Visual Studio.

To get up and running I followed the steps as described here: . However when I tried to run the tests, the Test Explorer in Visual Studio remained empty and no tests were discovered.

What went wrong?

I made a stupid mistake as I only added the MSTest.TestFramework NuGet package. This package contains the Test Attributes and Assertions. To be able to run the tests you also need a Test Adapter and test runner which are part of the dotnet-test-mstest NuGet package. After adding this package, my tests were finally discovered. Problem solved!

From the project.json:

"dependencies": {
   "dotnet-test-mstest": "1.1.2-preview",
   "Marten": "1.2.4",
"MSTest.TestFramework": "1.0.8-rc"