Roundup #8

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

ASP.NET Core 2.2 Roadmap

We are currently planning to have 3 previews before RTM:

  • August – Preview 1
  • September – Preview 2
  • October – Preview 3
  • Before End-of-year – RTM

As with our previous roadmap posts this is what we intend right now, but it’s subject to change as we continue development.



Windows Command-Line: The Evolution of the Windows Command-Line

Welcome to the second post in this “Windows Command-Line” series. In this post we’ll discuss some of the background & history behind the Windows Command-Line. Specifically, we’ll explore its humble origins in MS-DOS, to its modern-day incarnation supporting tools like PowerShell and Windows Subsystem for Linux.



Analyzing .NET Core project dependencies: Finding transitive dependencies

In the previous blog post, I looked at how we can use the .NET Core CLI to generate a dependency graph which allows you to determine the package references for a .NET Core or .NET Standard project. This is the same technique I used when developing dotnet-outdated.

Once dotnet-outdated started gaining a bit of traction, one of the issues opened on the GitHub repository was a request to support detecting outdated transitive dependencies.



The Web That Never Was – Dylan Beattie

The story of the web is a story about freedom. It’s a story about information, about breaking down barriers, about creating new ways for people to communicate, to collaborate, and to share their ideas. It’s also a story that has as much do with marketing, money and meetings as it does with research and innovation. It’s a story of mediocre ideas that succeeded where brilliant ideas failed, a story of compromises, rushed deadlines and last-minute decisions. And it could so easily have been very, very different.

What if IBM had hired Digital Research instead of Microsoft to develop the operating system for their first PC, way back in 1980? What if Marc Andreessen and Jim Clark had gone to work for Nintendo in 1993 and never founded Netscape? What if one of the team at CERN had said “Tim, won’t it sound a bit silly if everyone spends the next fifty years saying double-you-double-you-double-you all the time”?

In this talk, Dylan Beattie will explore alternative history of the world wide web – a web with no Microsoft, no Windows; no Firefox, no Google and no JavaScript. A software industry from another timeline, a world of platforms, protocols and programming languages that are unmistakably alien – and yet strangely familiar.



Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

How to Create Health Checks in ASP.NET Core

Health Checks in ASP.NET CoreIf you’re using a load balancer in front of your ASP.NET Core application you will need to provide it a route where it can verify that your application is still running.  Here’s an overview of how you can implement implement Health Checks in ASP.NET Core.

Health Checks in ASP.NET Core

If you’re using ASP.NET Core MVC, you might first think to just create a controller and action and provide that route as the health check for your load balancer.

However there are alternative ways to accomplish this with middleware.

Basic Middleware

At the very basic level, we can create a middleware high in the pipeline that is checking the request path and if /hc, return a 200 status code along with content “UP”.  Here’s our Startup’s Configure method.

Checking Services

At a minimum we are confirming that ASP.NET Core is running, but often times we are using databases and other external services that our web application needs to access.  If our application cannot connect to these external services, do we want them to remain in the load balancer pool?  If not, then we can add some various checks and return a 200 if everything is successful.


Be honest, having that database code in there is pretty awful.  Let’s move this out into it’s own class and add an extension method onto IApplicationBuilder.

Now from our Configure() method we can just call the extension method.

ASP.NET Core 2.2

As of this writing, ASP.NET Core 2.2 has a plan for built in health checks.  This post will be updated accordingly when it is released.


Hopefully this gets you the idea of passing configuration data (path) to the middleware.  You can take this much further depending on your needs.

Are you using another solution for handling health checks?  Let me know in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

HTTP API Problem Details in ASP.NET Core

Problem Details in ASP.NET CoreIf you’ve been writing HTTP API’s, you likely have needed to return exceptions and errors back to the consuming clients.  Before you go and grow your own solution to this common problem, there is RFC 7807 Problem Details for HTTP APIs which set out solve this problem.

“problem detail” as a way to carry machine-readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

Problem Details in ASP.NET Core

Now that you’re on board with Problem Details, how do we use or implement this in ASP.NET Core.  Thankfully, Kristian Hellang has done all the heavy lifting and released Hellang.Middleware.ProblemDetails on NuGet.


Once you get the NuGet package, it’s simply a matter of adding it to your Startup’s Configure(IApplicationBuilder app):

By default with no configuration, this will return a Problem Details body and application/problem+json content type for status codes returned from MVC. This means 404’s as well as status codes you return from your controller actions explicitly.

Here’s an example of the response for a 404 when a route is not found.

For making explicit returns such as UnauthorizedResult:

This returns, as you might expect:

Bad Request

Most often you might be return a BadRequestObjectResult when the users sends malformed request.  In this case the solution is pretty sweet.  Simply provide BadRequest() with an object that is or derives from Microsoft.AspNetCore.Mvc.ProblemDetails


Another option is throw an exception.  Specifically you can throw a ProblemDetailsException that takes a ProblemDetails as a parameter.

Mapping Exceptions to ProblemDetails

Although I’m not in love with throwing a ProblemDetailsException, one of the reasons is you may not be directly inside an MVC Controller action.  If you follow my blog enough, you know I like to decouple using something like the MediatR library.  In this case you likely won’t be throwing a ProblemDetailsException.

But no worries, this situation is covered by being able to map exceptions to ProblemDetailsExceptions in the configuration.


If a 500 occurs due to an unhandled exception, this is covered.  However you likely want to see the exception details when in development.  Again, no problem!


This post really revolves around the sample on the GitHub repo.  Check it out to try it out yourself.

Are you using another solution for ProblemDetails in your HTTP API’s?  Let me know in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.