Roundup #37: .NET Core 1.x End of Life, gRPC, GraphQL, Benchmarking, Life Beyond Distributed Transactions

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

.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.


gRPC for dotnet

We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:

– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)

We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the mananged client experience in 3.0.


Adding a GraphQL Endpoint to Your ASP.NET Core API

Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.


Introduction to Benchmarking C# Code with Benchmark .NET

Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark .NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.


Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard

Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!

Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.

In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical ASP.NET Core SignalR: Azure SignalR Service

ASP.NET Core SignalR Scaling

In this section, I’m going to cover how to deal with scaling SignalR by using the Azure SignalR Service. This is a managed service that is an alternative to using the Redis backplane that I’ve described in the previous section.

You may want to use this option as it eliminates having to manage your own Redis instance as well as dealing with a load balancers configuration of sticky sessions (client affinity). Everything is all pre-configured for you, and is a fully managed service.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

If you haven’t already, check out the prior sections of this course.

  1. Course Overview
  2. ASP.NET Core SignalR Overview
  3. Basics
  4. Server Hubs
  5. HubContext
  6. Authorization
  7. Scaling with Redis

SignalR Scaling

I’ve covered the basics of scaling in the previous section and how having a web farm poses problems when using SignalR.

If you haven’t already or are need an overview of a webfarm scenario with SignalR, check out that section which covers how to scale using Redis as a backplane.

Azure SignalR Service

First thing to do is add a new resource in Azure by and search for the SignalR Service.

As you are creating the new service, when selecting the pricing tier, note that the free tier does not support changing the unit count. Meaning you are limited to 20 connections and 20k messages/day. The standard tier gives you 1k connections per unit and 1M messages/day/unit and allows you to scale up to 100 units (depending on the region).

Once created, go to the Settings > Keys page where you will need to copy the Connection String


First, you’ll need to reference the Microsoft.Azure.SignalR package in your csproj.

From here you simply need to change the ConfigureServices() to use AddAzureSignalR() and modify the Configure() to call UseAzureSignalR()

User Secrets

Now we need to place our Azure SignalR Service connection string in user secrets. To add to our secrets via the dotnet CLI:

dotnet user-secrets set Azure:SignalR:ConnectionString "Connection String Goes Here"   

If you’re unfamiliar with user secrets, check out my blog post on handling sensitive configuration data.

That’s it. You’ll now be using the Azure SignalR Service and be able to scale to 1000’s of connections.

Get The Course!

You’ve got several options:

  1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
  2. Access the full course now by enrolling for free on Teachable.
  3. Follow along with the blog post series here on
    1. Course Overview
    2. ASP.NET Core SignalR Overview
    3. Basics
    4. Server Hubs
    5. HubContext
    6. Authorization
    7. Scaling with Redis
    8. Scaling with Azure SignalR Service

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.

Roundup #36: Server GC in a Small Containers, Simple-Exec, Why your ASP.NET Core Application Won’t Scale

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

Running with Server GC in a Small Container Scenario Part 1 – Hard Limit for the GC Heap

I’ve checked in 2 configs related to specifying a hard limit for the GC heap memory usage so I wanted to describe them and how they are intended to be used. Feedback would be greatly appreciated.

In order to talk about the new configs it’s important to understand what consists of the memory usage in a process. When it comes to memory the terminology can be very confusing so it’s worth pointing out that by “memory” I meant private commit size. A process can have the following memory usage from the runtime’s POV:

-GC heap usage – this includes both the actual GC heap and the native memory used by the GC itself to do its bookkeeping;
-native memory used by other things in the runtime such as the jitted code heap;
-native memory used by something that’s not the runtime, eg, you are allocating native memory in your pinvoke calls;

We cannot control 3) and it could be significant. 2) is in general small compared to 1).



SimpleExec is a .NET library that runs external commands. It wraps System.Diagnostics.Process to make things easier.

SimpleExec intentionally does not invoke the system shell.

The command is echoed to standard error (stderr) for visibility.

Platform support: .NET Standard 1.3 and upwards.


Why your ASP.NET Core application won’t scale – Damien Edwards, David Fowler

Hey my app doesn’t scale! ____ Framework sucks! Well, you can write a slow app in any language. David Fowler and Damian Edwards will show you why your app isn’t scaling and gives you the DOs and the DON’Ts of making big apps do big things in ASP.NET Core.

We’ll talk about async, parallelism, and appropriate use of multiple threads. Are you misusing some APIs and inadvertently crashing your apps?

David Fowler and Damian Edwards, will show you the errors of your ways and make sense out of these techniques and when they’re useful – or when they should be avoided.

This will be a demo-heavy and highly technical session.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.