Roundup #16: NET Standard 2.1, Endpoint Routing, Bullseye, API Spec Workflow

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.

.NET Standard 2.1

This document describes the plan for .NET Standard 2.1, which includes the definition of its API surface.

We did a diff between .NET Core 2.1 and .NET Standard 2.0 to see which APIs that were added in .NET Core would be great candidates for inclusion in the standard.

Interesting to read some of the pros/cons for versioning and the decision to go with 2.1



Endpoint Routing

We’re making a big investment in routing starting in 2.2 to make it interoperate more seamlessly with middleware. For 2.2 this will start with us making a few changes to the routing model, and adding some minor features. In 3.0 the plan is to introduce a model where routing and middleware operate together naturally. This post will focus on the 2.2 improvements, we’ll discuss 3.0 a bit further in the future.

Pretty nice to see this as I’ve been wanting this for some time now, hence blog post on generating links to routes outside of MVC.




Bullseye is a .NET package for describing and running targets and their dependencies.

Bullseye can be used to write targets that do anything. It is not coupled to building .NET projects.

Really cool project that I just discovered by Adam Ralph.  Bullseye feels like a great and simple way to define some targets for doing tasks.  Feels very much like Cake without all the extra plugins.  Anyone using it already? Going to explore it more.



Our API Specification Workflow

A year ago we started trying to figure out the best way to not just document HTTP APIs, but to leverage API specifications to avoid duplicating efforts on loads of similar-but-different tasks; maintaining Postman Collections, creating mocks, contract testing, payload validation, etc. To us, it felt like API developers were wasting a lot of time writing up the same logic over and over again. Listing endpoints, defining what fields should have what data, figuring out validation logic, writing up examples, doing this all over and over again in loads of different formats, then — the few folks that have enough time and interest —would write loads of tests to make sure all these different formats were saying the same thing.



Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Generating links with UrlHelper outside of ASP.NET Core

UrlHelper outside of ASP.NET CoreI’ve been trying to solve the issue of generating links with UrlHelper outside of ASP.NET Core.  The problem I was facing was wanting to use UrlHelper while not directly in the context of ASP.NET Core.

There are two specific scenarios were:

  • Generate a link for an ASP.NET Core MVC route that I was going to be using in an email.  This is a separate process that is not running ASP.NET Core but does have references to the assemblies that contain the controllers.
  • Generate a link for an ASP.NET Core MVC route from a Nancy Module running in a Katana self host.  This also has a reference to the assemblies containing the controllers.


I tried various different solutions but couldn’t come up with a solution.  After a ton of searching, I finally found a StackOverflow post that provided a solution.  Although not pretty, it does work.

Here’s a sample console application.  First, there are a few extension methods for setting up the web host builder, application builder and generating the UrlHelper with a default HttpContext.

Next is to create a Startup class we will use in our web host builder.

Lastly, putting it all into place is to build a web host and then use the extension method to get a UrlHelper.  You’ll notice you need to provide the base path to the extension method.  This is because the extension method uses this base address as the request within the HttpContext it’s creating.


I’ve created a console application with the source available on GitHub.

If you know of a method of generating a link to an ASP.NET Core MVC route without being in the context of ASP.NET Core, please let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.


eShopOnContainers a Microservice based .NET Core Sample Application

eShopOnContainersFinding good sample applications if pretty difficult, if not impossible.  Most are small Todo style applications that are generally very CRUD based.  Thankfully Microsoft has created the eShopOnContainers a Microservice based .NET Core Sample Application.

.NET Core reference application, powered by Microsoft, based on a simplified microservices architecture and Docker containers.

This reference application is cross-platform at the server and client side, thanks to .NET Core services capable of running on Linux or Windows containers depending on your Docker host, and to Xamarin for mobile apps running on Android, iOS or Windows/UWP plus any browser for the client web apps.

The architecture proposes a microservice oriented architecture implementation with multiple autonomous microservices (each one owning its own data/db) and implementing different approaches within each microservice (simple CRUD vs. DDD/CQRS patterns) using Http as the communication protocol between the client apps and the microservices and supports asynchronous communication for data updates propagation across multiple services based on Integration Events and an Event Bus (a light message broker, to choose between RabbitMQ or Azure Service Bus, underneath) plus other features defined at the roadmap.


Here’s a development environment overview of the of the eShopOnContainers app.  I just want to point out a few pieces that I thought were well done in this sample.



Service Autonomy

Each service (Identity, Catalog, Ordering, Basket, Marketing, Locations) is autonomous.  It owns its own data(store) and does not have any dependencies on any other services.  In order to communicate with other services, it uses an event-driven model via publish/subscriber on an event bus of RabbitMQ or Azure Service Bus.

Each service does contain its own HTTP API that provides functionality such as retrieving data as well as performing specific actions.  For example, the Ordering service contains an API project that has HTTP resources for retrieving orders as well as canceling an order.

View Composition

Since each service provides its own HTTP API for retrieving specific data owned within that service, you ultimately need to compose your view from multiple services.

Backend-For-Frontends (BFF) patterns are used to provide a single API backend for a specific client type.  For example, the MVC and SPA apps use the Web-Shipping and Web-Marketing BFF while the Xamarin mobile app uses the Mobile-Shopping and Mobile-Marketing BFF.  Ultimately these BFF make HTTP calls to the needed services to compose the data required for the client.


I highly recommend checking out the application and digging in a bit.  There are many different services and each has its own individual architecture within it.  Such as the Ordering service using CQRS via the MediatR library in it’s HTTP API.  It also uses some technical DDD patterns as well.

If you’re interested in the Backends-For-Frontends, I recommend checking the post by Sam Newman and Chris Richardson.

Although a tad outdated, Particular have also a fork of eShopOnContainers but modified to run on top of NServiceBus.

If you know of any other solid sample applications beyond To Do lists, please let me know in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.