Alter response header in Web API to return machine name

Full source code available here.

I recently hit a problem where I was getting incorrect responses from a server behind a load balancer. Looking at the logs didn’t help because there was no error.

It was likely due to a misconfigured environmental variable but I couldn’t even identify which server was having the problem because of the load balancer.

Luckily the application was a .NET Core Web Api and I could use a little bit of middleware to add the server name to the response header.

It’s a trivial change in the Configure(..) method of Startup.cs

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.Use((context, next) =>
    {
        context.Response.Headers.Add("MachineName", $"{Environment.MachineName}");
        return next();
    });
    app.UseMvc();
}

That’s all I had to do.

Here’s how the response looks now.

.

Full source code available here.

Loading Config from Multiple Sources with .NET Core 2.x Web Api or MVC

Full source code available here.

.NET Core 2 and .NET Core 2.1 offer many ways to load configuration and they are well documented by Microsoft. But there is one scenario that I didn’t see explained.

If you want to supplement the configuration in appsettings.json with more from a remote service, database or some other source, you first need to know where that source is, then make a request to it and add it to your configuration. You are probably going to put the location of the remote configuration appsettings.json, then you call the remote config source.
Sounds easy? It is, but not obvious.

First, a little background.

In an out of the box Web API or MVC application you get a Program.cs that looks like this –

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();
}

On line 9, we have WebHost.CreateDefaultBuilder(args), if you peek the definition of this with Resharper you will some something like –

The highlighted code is how your appsettings.json is loaded into the configuration and added to services collection, this call happens just as you leave Program.cs

But you want to read from the appsettings.json and use a value from it to make another call to get more configuration and then add the whole lot of the services collection. You might also want to setup some logging configuration in Program.cs, so you need access to all configuration settings before calling

CreateWebHostBuilder(args).Build().Run();

Here’s how you do it.

Step 1
Inside the main method in Program.cs, build the configuration yourself –

IConfigurationBuilder builder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json");
Configuration = builder.Build();

Get the location of the other configuration service, in my example it is another json file.
Add it to the builder and call build.

string otherConfigService = Configuration["otherConfigService"]; // this could be a database or something like consul

builder.AddJsonFile(otherConfigService);
Configuration = builder.Build();

Now you have access to the configuration values from the second source.

Configuration["SomeOtherConfigItem1"]}
Configuration["SomeOtherConfigItem2"]}

So far so good, but as mentioned above, the CreateDefaultBuilder adds the configuration to the ServiceCollection, making it available by DI. But that only happens for appsettings.json (and appsettings.{env.EnvironmentName}.json, not the config you loaded from the other source.

If you tried to access the a config setting of your from inside Startup.cs or a controller, it would not be there.

Step 2
Let’s make our configuration available via the ServicesCollection.

In the first block of code above there was a call – CreateWebHostBuilder(args).Build().Run();

I added line 4 below, this will add the configuration to the services collection.

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseConfiguration(Configuration); // add this line to add your configuration to the service collection

Now, the config values loaded from appsettings.json and your secondary config source will be available throughout your application.

Full source code available here.

Using the In-Memory Cache with .NET Core Web API

Full source code available here.

If you need to store anything temporarily within an application, you should consider using the In-Memory Cache from Microsoft. In .NET Core it is much easier to use than its predecessor from Framework 4.x. You can store almost anything in it, in a type safe manner.

When adding an item to the cache you set the an expiration, this can be an absolute time, a sliding window or the combination of both. Choosing which one to use depends on your scenario.

When an item is removed from the cache a delegate can be called, you can use this for logging or some other purpose.
Items can also be evicted when the cache is running low on memory.

In this example I’m going to show a simple usage example for the cache inside a .NET Core Web API application.
Just a single line in startup.cs adds the cache to the dependency injection container.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMemoryCache();
    services.AddMvc();
}

Now I can access the cache from inside all my controllers by just adding an IMemoryCache parameter to the constructor.

private readonly IMemoryCache _cache;
public CountriesController(IMemoryCache memoryCache)
{
    _cache = memoryCache;
}

I have a very simple GET method that takes a country code as its parameter and looks up full name of the country.

[HttpGet("{countryCode}")]
public async Task<IActionResult> Get(string countryCode)
{
    string country = await LookupCountryByCode(countryCode);

    if (string.IsNullOrEmpty(country))
    {
        return NoContent();
    }
    return Ok(country);
}

And here is where I use the cache.

private async Task<string> LookupCountryByCode(string countryCode)
{
    if(!_cache.TryGetValue("ListOfCountries", out Dictionary<string, string> countries))
    {
        Console.WriteLine("Cache miss....loading from database into cache");
        countries =
            JsonConvert.DeserializeObject<Dictionary<string, string>>(
                await System.IO.File.ReadAllTextAsync("countrylist.json"));

        _cache.Set("ListOfCountries", countries, TimeSpan.FromSeconds(10));
    }
    else
    {
        Console.WriteLine("Cache hit");
    }

    return countries[countryCode];
}

On line 3, I check if the list of countries is in the cache; I won’t be the first time through this method or if the cache entry has expired.
Inside the if clause I load the list of countries from a json file, but you could load from a database or any other source. Then I add the list to the cache and set when the entry will expire, in this example it will expire 10 seconds after it was added.

If you want to use both an absolute expiration and sliding window you need to pass the MemoryCacheEntryOptions when adding an item to the cache.

MemoryCacheEntryOptions options = new MemoryCacheEntryOptions
{
    AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(25), // cache will expire in 25 seconds
    SlidingExpiration = TimeSpan.FromSeconds(5) // caceh will expire if inactive for 5 seconds
};

_cache.Set("ListOfCountries", countries, options);

Full source code available here.

Using Dependency Injection with Startup.cs in ASP.NET Core

Full source code available here.

Did you know that .NET Core 2 can pass in an instance of any type you want to the Startup.cs constructor? Well you can! Here’s how.

Out of the box the Startup.cs comes like this –

public class Startup
{
	public Startup(IConfiguration configuration)
	{
		Configuration = configuration;
	}
//snip..

The IConfiguration is passed in by dependency injection. In Program.cs you can add other types to the DI container, and then add that type to the constructor parameters of Startup.cs.

Here’s how it works. The Microsoft.AspNetCore.Hosting.WebHostBuilder has a ConfigureServices(...) method –

public IWebHostBuilder ConfigureServices(Action<IServiceCollection> configureServices)
{
    if (configureServices == null)
    {
        throw new ArgumentNullException(nameof(configureServices));
    }

    return ConfigureServices((_, services) => configureServices(services));
}

This lets you add services to the dependency injection container from the Program.cs.

WebHost.CreateDefaultBuilder(args) returns an IWebHostBuilder and that lets you use the ConfigureServices(...) method. Easy!

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .ConfigureServices(serviceCollection =>
            serviceCollection.AddScoped<ISomeService, SomeService>())
        .UseStartup<Startup>()
        .Build();

And in Startup.cs

public class Startup
{
    private ISomeService _someService;
    public Startup(IConfiguration configuration, ISomeService someService)
    {
        _someService = someService;
        Configuration = configuration;
    }
// snip..	

The instance of ISomeService is of course available for DI everywhere in the application.

public class ValuesController : Controller
{
    private readonly ISomeService _someService;
    public ValuesController(ISomeService someService)
    {
        _someService = someService;
    }
}

Full source code available here.

Getting .NET Core 2.1 Preview 2 Working with Visual Studio 2017

About a year ago I wanted to start using .NET Framework 4.7, it should have been an easy process, but wasn’t. After some trial and error if figured it out and wrote a blog post explaining how to get it working.

Now with the release of .NET Core 2.1 Preview 2, I have hit the familiar problems – no obvious instructions from Microsoft, no one place to download all everything that needed and a Visual Studio install that does not include what you the latest SDK or runtime, and errors like – The specified framework 'Microsoft.AspNetCore.App', version '2.1.0-preview2-final' was not found. or, 'dotnet.exe' has exited with code -2147450730 (0x80008096).

After a few hours messing around and installing the wrong versions of the right software I figured it out.

Step 1

Install the latest version of Visual Studio Preview https://www.visualstudio.com/vs/preview/, at the time of writing this was version 15.7.0 Preview 4.0

I’m interested in developing Web API applications, so I check that box.

BUT, version 15.7.0 Preview 4.0 comes with .NET Core Version 2.1.0 Preview 1. So you don’t get the fancy new features like HttpClientFactory. Read on…

Step 2

Go to
https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.1.0-preview2-download.md and download the SDK and the Runtime for your architecture.

You can verify the checksum of the downloads if you want to by comparing your SHA sum to these ones – https://dotnetcli.blob.core.windows.net/dotnet/checksums/2.1.300-preview2-008530-sdk-sha.txt

Install both the SDK and the runtime.

Step 3

To verify that that you are running .NET Core Preview 2, open visual studio and create a new .NET Core Web API application.

Once it has been created, open the .csproj file, you should see this block –

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.0-preview2-final" />
</ItemGroup>

If you don’t see Version="2.1.0-preview2-final", something has gone wrong.

You can verify what packages are installed by going to your start menu and opening Apps and Features/Add or remove programs.

If you have installed the right SDK and runtime you should see the following –

Setting the Kestrel Port From Appsettings.json

Full source code available CoreWithKestrelFromConfighere.

In my previous post I explained how to host Kestrel web server running on (the default) port 5000 as a Windows service. But what if you want to run the server on a different port?

There are a few ways to do this, but the easiest is to add an entry to the appsettings.json file specifying the urls the server should listen to.

In this example, I’m setting it to http://localhost:62000.

The appsettings.json file looks like this –

{
"urls": "http://localhost:62000/"
}

I also removed applicationUrl setting from the from the launchSettings.json file, now Visual Studio and the command line will set the application to the same port.

To add the settings in appsettings.json to the configuration, call .AddJsonFile("appsettings.json") when creating the ConfigurationBuilder.

public class Program
{
    public static IConfiguration Configuration { get; set; }
    public static void Main(string[] args)
    {
        var builder = new ConfigurationBuilder()
            .AddJsonFile("appsettings.json");
        Configuration = builder.Build();

        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .UseConfiguration(Configuration)
            .Build();
}

You don’t have name the file appsettings.json, you can put it any file you like, but this is convenient.

To run the application from the command line you can do one of two things –

1. Go to the directory where the csproj file is located and type:
dotnet run

2. Go to the bin\debug\netcoreapp2.0 directory and type:
dotnet CoreWithKestrelFromConfig.dll

You can set Kestrel to listen on multiple urls, the format is this –

{
   "urls": "http://localhost:62000/;http://localhost:62002/"
}

Full source code available CoreWithKestrelFromConfighere.

Hosting a .NET Core 2 Kestrel Server in a Windows Service

Full source code available here.

If you have been using the Kestrel web server with Framework 4.x, you might already be hosting Kestrel inside a Windows service. But what if you want to use Kestrel with .Net Core 2? It’s not straightforward to host that with a Windows service, but not too difficult either.

Before installing the service verify that Kestrel is running on the port you expect.

Navigate to

bin\debug\netcoreapp2.0

and type

dotnet WebApiCoreWithKestrel.dll (or whatever the name of your assembly is).

This command should start a console and at the top will be the port Kestrel is running on. If you haven’t specified anything, it will start on port 5000. I’ll show you how to change that in a later post.

Here are the steps for deploying this application as a service.

Step 1
First you need to download nssm, the Non-Sucking Service Manager and place it somewhere in your path or drop the nssm.exe into the bin\debug\netcoreapp2.0 directory of your project (you should use the release dll when deploying for real).

Step 2
Then you build you application.

Step 3
Create a good old batch file to run your dll and add one line –

dotnet WebApiCoreWithKestrel.dll

Swap in whatever the name of your application is.

Step 4
From a command prompt type –
nssm install MyKestrelService

In the nssm window, click on the button to the right of path and pick the startup.bat file you created in step 3.

Click through to the Shutdown tab.

Note the Generate Control-C on shutdown. In Program.cs I’ve added a method that logs when the shutdown signal is received, you of course can perform any task you wish.

private static void Console_CancelKeyPress(object sender, ConsoleCancelEventArgs e)
{
    Log.Information("Shutting down");
}

Click Install Service

Step 5
In service manager you should now see a service called MyKestrelService, right click it and start the service.

That’s it your Kestrel server is up and running, you can hit by going to http://localhost:5000/api/values.

Full source code available here.

Reusing HttpClient with Dependency Injection

Full source code available here.

If you are using HttpClient to make requests for you, you might have come across some articles discussing how to reuse HttpClient. They strongly advocate for using a single HttpClient for as many requests as possible, i.e. not creating a new HttpClient for every request.
Not having to create/dispose of the HttpClient for every request should improve the performance of you application. One estimate states that every time you instantiate a HttpClient takes 35ms.

In this article I will show you how to use dependency injection to reuse the HttpClient in .Net Core, but the same principle applies in Framework 4.x applications.

The one advantage of creating a new HttpClient for every request is that you don’t need to worry about the DNS record of an endpoint changing during the lifetime of the application, this is common if you are swapping staging and production instances during a deployment. But this is easyly(ish) handled by the ServicePointManger.

Adding HttpClient to the DI Container
In Startup.cs add the below lines.

public void ConfigureServices(IServiceCollection services)
{
    Uri endPointA = new Uri("http://localhost:58919/"); // this is the endpoint HttpClient will hit
    HttpClient httpClient = new HttpClient()
    {
        BaseAddress = endPointA,
    };

    ServicePointManager.FindServicePoint(endPointA).ConnectionLeaseTimeout = 60000; // sixty seconds

    services.AddSingleton<HttpClient>(httpClient); // note the singleton
    services.AddMvc();
}

This approach is ideal if you have a limited number of endpoints and you know them at application startup. If you don’t know then endpoints at startup you can add the call to ServicePointManager where you HttpClient requests occur.

Using the HttpClient
Now I have the HttpClient registered with the Dependency Injection container, let’s take a look at the controller that uses it to make a request. See the inline comments.

public class ValuesController : Controller
{
    private readonly HttpClient _httpClient; // declare a HttpClient

    public ValuesController(HttpClient httpClient) // this is the singelton instance of HttpClient
    {
        _httpClient = httpClient; // assign it to the local HttpClient
    }

    // GET api/values
    [HttpGet]
    public async Task<IActionResult> Get()
    {
        string requestEndpoint = "api/products";

        HttpResponseMessage httpResponse = await _httpClient.GetAsync(requestEndpoint); // make request
        List<Product> products = await httpResponse.Content.ReasAsJsonAsync<List<Product>>();
        return Ok(products);
    }
}

Full source code available here.

Entity Framework Core 2 Unit Testing in .NET Core 2

Full source code available here.

Unit testing Entity Framework used to be quite a chore, but over the past few years it has become significantly easier.

In this post I’m going to show you how to use the InMemory database with named instances.

The ProductsController is fairly standard, it takes a DbContext in the constructor which is instantiated by dependency injection (see the Startup.cs in the source code if you don’t know how to do this).

public ProductsController(ProductsContext context)
{
    _productsContext = context;
}

The action methods use the context to query the database and return responses to the callers. From the response status code the caller knows if there is also content (products) in the response.

[HttpGet]
public async Task<IActionResult> Get()
{
    var products = await _productsContext.Products.ToListAsync();

    if (!products.Any())
    {
        return NotFound();
    }
    return Ok(products);
}

Testing
In the unit test project, (see here if you need help creating this), I’ve added a ProductsControllerTests class.

In my Get test I created an instance of a DbContextOptions by using the DbContextOptionsBuilder. On the builder I specify that I want an InMemoryDatabase and give it a unique name for this test – this is important, if the name is not unique across all tests or if it is left blank you will end up with a database shared by more than one test.

In the Arrange portion of the test I also instantiate the ProductsContext; then instantiate a few products, add them to the context; don’t forget to save the changes; finally create an instance of the of ProductsController.

Here is the full Arrange portion of the test.

// Arrange
var options = new DbContextOptionsBuilder<ProductsContext>()
.UseInMemoryDatabase(databaseName: "Get test")
.Options;

ProductsContext productsContext = new ProductsContext(options);
Product product01 = new Product { Name = "first", ProductId = 1, Sku = "abc" };
Product product02 = new Product { Name = "second", ProductId = 2, Sku = "def" };

productsContext.Products.Add(product01);
productsContext.Products.Add(product02);
await productsContext.SaveChangesAsync();
ProductsController controller = new ProductsController(productsContext);

Next I Act, just calling the controller’s Get method. The controller already has the context and the get method will query it just like a real database.

// Act
var actionResult = await controller.Get();

Then I Assert. 

// Assert
var okObjectResult = actionResult as OkObjectResult;

List<Product> products = okObjectResult.Value as List<Product>;

Assert.Equal(2, products.Count());

Note the as OkObjectResult type, I know it's that type because that is what I return from the ProductsController.

I assign the value of the okObjectResult to a List.Assert that there are two entries in the list.

Testing NotFound - 404
In the ProductsController I also have a Get that takes a productId as an int and returns a product.
You should also test the scenario that no entries in the database match the search. In this case I am returning a NotFound, you may choose to return something else like an OK with nothing in it. In the case of a list, some people like to return an empty list; there is much debate on this topic and I have no interest in adding my two cents.

To test the NotFound response, the Act and Assert change a little. I call the GET method with an id that I know will return nothing.

// Act
var actionResult = await controller.Get(999);

// Assert
var notFoundResult = actionResult as NotFoundResult;

Assert.Equal(404, notFoundResult.StatusCode);

Full source code available here.

Unit Testing .NET Core 2 Web Api

Full source code available here.

Unit testing Web API controllers in .NET Core 2 is very easy.

I have very simple GET and POST methods.

[Route("api/[controller]")]
public class ValuesController : Controller
{
    [HttpGet]
    public async Task<IActionResult> Get()
    {
        // imagine some db logic
        List<string> values = new List<string>() { "value1", "value2" };
        return Ok(values);
    }

    [HttpPost]
    public async Task<IActionResult> Post([FromBody]string value)
    {
        // imagine some db logic
        return Created("", value);
    }
}

Add an xUnit Test Project to your solution.

In the test project add a ValuesControllerTests class.

Add a method to test the ValuesController.Get like this –

[Fact]
public async Task TestGet()
{
    // Arrange
    var controller = new ValuesController();

    // Act
    IActionResult actionResult = await controller.Get();

    // Assert
    Assert.NotNull(actionResult);

    OkObjectResult result = actionResult as OkObjectResult;

    Assert.NotNull(result);

    List<string> messages = result.Value as List<string>;

    Assert.Equal(2, messages.Count);
    Assert.Equal("value1", messages[0]);
    Assert.Equal("value2", messages[1]);
}

Note here how I expect the result to be an OkObjectResult

OkObjectResult result = actionResult as OkObjectResult;

And here where I cast the result.Value as List, the type I sent from the controller. No deserializing from json, strings or byte arrays needed!

List<string> messages = result.Value as List<string>;

Now it is simple to perform the appropriate asserts.

Here is another example, this time testing the ValuesController.Post().

[Fact]
public async Task TestPost()
{
    // Arrange
    var controller = new ValuesController();

    // Act
    IActionResult actionResult = await controller.Post("Some value");

    // Assert
    Assert.NotNull(actionResult);
    CreatedResult result = actionResult as CreatedResult;

    Assert.NotNull(result);
    Assert.Equal(201, result.StatusCode);
} 

You can also test a result for NotFoundResult, OkResult, UnauthorizedResult, etc.

Full source code available here.