Asp.NET Core – populating IOptions<T> from external data source

2017-02-26 TPodolakASP.NET Core1 Comment

1. Introduction

In ASP.NET Core web.config is no longer a proper place for storing application settings. New framework introduces the concept of a json based configuration and the default file which stores the settings now is appsettings.json. Here is a quick tutorial how to use new features.

2. Reading configuration

Let’s assume that our appsettings.json file looks as follows.

{
    "Logging": {
        "IncludeScopes": false,
        "LogLevel": {
            "Default": "Debug",
            "System": "Information",
            "Microsoft": "Information"
        }
    },
    "AvailabilitySearchOptions": {
        "FlexDaysIn": 2,
        "FlexDaysOut": 3
    }
}

{

"Logging": {

"IncludeScopes": false,

"LogLevel": {

"Default": "Debug",

"System": "Information",

"Microsoft": "Information"

}

"AvailabilitySearchOptions": {

"FlexDaysIn": 2,

"FlexDaysOut": 3

}

Thanks to ConfigurationBuilder we can parse this config and later on materialize sections or entire file into strongly typed configuration classes. Let’s say we want to parse AvailabilitySearchOptions node to following class

public class AvailabilitySearchOptions
{
    public int FlexDaysIn { get; set; }

    public int FlexDaysOut { get; set; }

    public TimeSpan MinimumConnectionTime { get; set; }

    public TimeSpan MinimumDepartureTime { get; set; }
}

public class AvailabilitySearchOptions

{

public int FlexDaysIn { get; set; }

public int FlexDaysOut { get; set; }

public TimeSpan MinimumConnectionTime { get; set; }

public TimeSpan MinimumDepartureTime { get; set; }

}

We can achieve that with following steps. First of all, we need to read entire configuration

public IConfigurationRoot Configuration { get; }

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
                        .SetBasePath(env.ContentRootPath)
                        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
                        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

public IConfigurationRoot Configuration { get; }

public Startup(IHostingEnvironment env)

{

var builder = new ConfigurationBuilder()

.SetBasePath(env.ContentRootPath)

.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)

.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)

.AddEnvironmentVariables();

Configuration = builder.Build();

}

And in the next step we have to register IOptions<AvailabilitySearchOptions> in the container using services.Configure<TOptions>(IConfiguration section) method

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));  
}

// This method gets called by the runtime. Use this method to add services to the container.

public void ConfigureServices(IServiceCollection services)

{

// Add framework services.

services.AddMvc();

services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));

}

Note Configuration.GetSection(“AvailabilitySearchOptions”) passed as argument to services.Configure method.
From now on we can access AvailabilitySearchOptions settings via IOptions<AvailabilitySearchOptions> interface, which you can easily inject into your classes.

[Route("api/[controller]")]
public class OptionsController : Controller
{
    private readonly IOptions<AvailabilitySearchOptions> availabilitySearchOptions;

    public OptionsController(IOptions<AvailabilitySearchOptions> availabilitySearchOptions)
    {
        this.availabilitySearchOptions = availabilitySearchOptions;
    }

    public AvailabilitySearchOptions Get()
    {
        return availabilitySearchOptions.Value;
    }
}

[Route("api/[controller]")]

public class OptionsController : Controller

{

private readonly IOptions<AvailabilitySearchOptions> availabilitySearchOptions;

public OptionsController(IOptions<AvailabilitySearchOptions> availabilitySearchOptions)

{

this.availabilitySearchOptions = availabilitySearchOptions;

}

public AvailabilitySearchOptions Get()

{

return availabilitySearchOptions.Value;

}

3. Populating IOptions<T> from external data source

From time to time, reading configuration just from JSON file might not be enough and for instance you would like to add additional configuration read from some external data source. Fortunately you don’t have to resign from the IOptions<T> class as it is possible to read additional data for literally any other source thanks to IConfigureOptions<T> class. All we have to do is to create a setup class which implements IConfigureOptions<T> interface

public class AvailabilitySearchOptionsSetupService : IConfigureOptions<AvailabilitySearchOptions>
{
    private readonly ILogger<AvailabilitySearchOptionsSetupService> logger;
    private readonly IReservationSettingsService reservationSettingsService;
	
    public AvailabilitySearchOptionsSetupService(ILogger<AvailabilitySearchOptionsSetupService> logger ,IReservationSettingsService reservationSettingsService)
    {
        this.logger = logger;
        this.reservationSettingsService = reservationSettingsService;
    }
	
    public void Configure(AvailabilitySearchOptions options)
    {
        this.logger.LogInformation($"Calling first {typeof(IConfigureOptions<AvailabilitySearchOptions>)} service");
        options.MinimumConnectionTime = reservationSettingsService.GetMinimumConnectionTime();
    }
}

public class AvailabilitySearchOptionsSetupService : IConfigureOptions<AvailabilitySearchOptions>

{

private readonly ILogger<AvailabilitySearchOptionsSetupService> logger;

private readonly IReservationSettingsService reservationSettingsService;

public AvailabilitySearchOptionsSetupService(ILogger<AvailabilitySearchOptionsSetupService> logger ,IReservationSettingsService reservationSettingsService)

{

this.logger = logger;

this.reservationSettingsService = reservationSettingsService;

}

public void Configure(AvailabilitySearchOptions options)

{

this.logger.LogInformation($"Calling first {typeof(IConfigureOptions<AvailabilitySearchOptions>)} service");

options.MinimumConnectionTime = reservationSettingsService.GetMinimumConnectionTime();

}

And then registering this class in our container

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));
    services.AddSingleton<IConfigureOptions<AvailabilitySearchOptions>, AvailabilitySearchOptionsSetupService>();
}

// This method gets called by the runtime. Use this method to add services to the container.

public void ConfigureServices(IServiceCollection services)

{

// Add framework services.

services.AddMvc();

services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));

services.AddSingleton<IConfigureOptions<AvailabilitySearchOptions>, AvailabilitySearchOptionsSetupService>();

}

From now on, when value of IOptions<AvailabilitySearchOptions> is accessed for very first time, Configure method from AvailabilitySearchOptionsSetupService will be called and you will be able to set additional values for your settings. Note that values from appsettings.json will already be there.
In addition, it is possible to have multiple implementations of IConfigureOptions<T> so if you want your setup to be split into multiple classes you are good to go.

Source code for this post can be found here

XUnit – sharing test data across assembly

2017-02-192017-02-24 TPodolakxunit

1. Introduction

XUnit provides two ways of sharing data between tests – ICollectionFixture and IClassFixture. The first one allows you to shared context across collections and the second one across test classes. I’ve already had a couple of cases in which these fixtures were not enough. Basically, I wanted to share data between all tests in given assembly – without worrying in which test class or test collection given test is. In these circumstances, I’ve usually used some kind of old fashioned singleton or custom TestFrameworkExecutor. I’ve never liked those solutions, fortunately recently I’ve come across a nice little library – xunit.assemblyfixture.

2. Usage

Xunit.assemblyfixture allows you to share data between tests in given assembly via IAssemblyFixture interface. The usage is basically the same as in other XUnit’s fixtures. All we have to do is to create a class which instance we want to share with other tests

public class TestFixture : IDisposable
{
    public static int InitializationCounter { get; private set; }

    public TestFixture()
    {
        InitializationCounter++;
    }

    public void Dispose()
    {
        // free resources if necessary
    }
}

public class TestFixture : IDisposable

{

public static int InitializationCounter { get; private set; }

public TestFixture()

{

InitializationCounter++;

}

public void Dispose()

{

// free resources if necessary

}

And then create test classes which implement IAssemblyFixture interface. If we want to have access to the fixture from the tests, we can inject instance of TFixture via constructor

public class TestBase : IAssemblyFixture<TestFixture>
{
    protected readonly ITestOutputHelper TestOutputHelper;
    protected readonly TestFixture Fixture;

    protected TestBase(ITestOutputHelper testOutputHelper, TestFixture fixture)
    {
        this.TestOutputHelper = testOutputHelper;
        this.Fixture = fixture;
    }

    protected void DisplayInitializationCount()
    {
        TestOutputHelper.WriteLine($"Initialization count: {TestFixture.InitializationCounter}");
    }
}

public class TestBase : IAssemblyFixture<TestFixture>

{

protected readonly ITestOutputHelper TestOutputHelper;

protected readonly TestFixture Fixture;

protected TestBase(ITestOutputHelper testOutputHelper, TestFixture fixture)

{

this.TestOutputHelper = testOutputHelper;

this.Fixture = fixture;

}

protected void DisplayInitializationCount()

{

TestOutputHelper.WriteLine($"Initialization count: {TestFixture.InitializationCounter}");

}

Xunit.assemblyfixture fixture will ensure that given test class is shared via all the tests and is initialized only once.

If you want to share multiple classes across the assembly, you can, of course, use IAssemblyFixture multiple times.

3. Visual Studio 2017 – XUnit beta tests runners

As for now VS 2017 RC requires beta runners of XUnit in order to run our unit tests. xunit.assemblyfixture seems not to cooperate with them smoothly. However, there is a simple workaround to fix that. All we have to do is to add the following attribute to our test project

[assembly: TestFramework("Xunit.TestFramework", "xunit.assemblyfixture")]

1	[assembly: TestFramework("Xunit.TestFramework", "xunit.assemblyfixture")]

And from now on, XUnit correctly can inject assembly fixtures into our test classes

Source code for this post can be found here

ASP.NET Core – tracking flow of requests with NLog

2017-02-18 TPodolakASP.NET Core, NLog3 Comments

1. Introduction

A while ago I wrote an article about using MappedDiagnosticsLogicalContext for tracking request flow in your application. As we are moving our project to ASP.NET Core, I wanted to keep that functionality in place. Unfortunately, MDLC layout renderer is not available in that framework anymore(when targeting .NET Core). Luckily, there are two other renderers which can be used as a replacement:

aspnet-traceidentifier
aspnet-item

2. Configuring NLog

Before I dig into details of layout renderers mentioned above, we have to configure ASP.NET Core to use NLog as a logger. First of all, we need to grab NLog.Web.AspNetCore NuGet package. Once the package is installed we have to manually add NLog.config to the project (the file won’t be added automatically by NuGet installer). The next step is to configure NLog with our config, then configure NLogWeb and finally register NLog in LoggingFactory. All of these steps should be done in Startup class.

public class Startup
{
    public Startup(IHostingEnvironment env)
    {
        // rest of the code omitted for brevity
        env.ConfigureNLog("NLog.config");
        // rest of the code omitted for brevity
    }
	
    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        // rest of the code omitted for brevity
        loggerFactory.AddNLog();
        app.AddNLogWeb();
        // rest of the code omitted for brevity
    }
}

public class Startup

{

public Startup(IHostingEnvironment env)

{