Roundup #59: IHostingEnvironment vs IHostEnvironment, Async demystified, Pulumi, Memory management and GC in ASP.NET Core

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

IHostingEnvironment vs IHostEnvironment – obsolete types in .NET Core 3.0

In this post I describe the differences between various ASP.NET Core types that have been marked as obsolete in .NET Core 3.0. I describe why things have changed, where the replacement types are, and when you should use them.


Async demystified – Karel Zikmund

Do you struggle to understand async/await in C#? How it works and why? I did. So I asked the best – the author of async, Stephen Toub. This talk is summary of the most interesting insights from him that helped me and my colleagues on CoreFX team to finally truly understand the magic behind async/await.

The talk will cover: History and evolution of asynchronous programming patterns in C# and their problems. Leading to async/await and demonstrating the “why” behind its design choices.

Touch on the “how” it works behind the scenes.

Reasons for customizing and hyper-optimizing async for high-performance areas (like Networking stack).

Touch on related building block – ThreadPool.

Hands on sync-over-async pattern and associated problems. Workarounds in your code if you hit it. Potential solutions in future .NET versions.


Pulumi 💜 .NET Core

Today we are excited to announce the Preview of .NET Core support for all of your modern infrastructure as code needs. This means you can create, deploy, and manage your infrastructure, on any cloud, using your favorite .NET language, including C#, F#, and VB.NET.


Memory management and garbage collection (GC) in ASP.NET Core

Memory management is complex, even in a managed framework like .NET. Analyzing and understanding memory issues can be challenging. This article:

Was motivated by many memory leak and GC not working issues. Most of these issues were caused by not understanding how memory consumption works in .NET Core, or not understanding how it’s measured.

Demonstrates problematic memory use, and suggests alternative approaches.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Orleans Health Checks using ASP.NET Core

Orleans Health Checks

One of the nicest things with the introduction of the Generic Host in Orleans v3.0 is that it allows you to run Orleans side by side with ASP.NET Core. One of the main benefits that I could think of is creating Orleans health checks using ASP.NET Core Health Checks.


Since Orleans 3.0, there is now support for the GenericHost via extensions on IHostBuilder, this allows you to run multiple services within the same process all sharing things such as logging, services, configuration, etc.

In a recent blog post, I covered how you can co-host Orleans and ASP.NET Core. This post is an extension of that. If you have not read that already, go take a look first.

ASP.NET Core Health Checks

The reason for wanting health checks for services like an Orleans Silo are varied. One primary use case is when running a silo that is hosted under some type of container orchestration, such as Kubernetes, AWS ECS, etc.

These orchestrators generally provide a mechanism to determine if your service is healthy or unhealthy. If unhealthy, the will create new instances based on your configuration.

ASP.NET Core has a middleware that simplifies providing such health status. I’ve blogged about creating ASP.NET Core Health Checks over on the Telerik Blog.

Orleans Health Checks

In order to verify that a local silo is healthy, we are going to use a stateless grain. The reason being, stateless grains are always executed locally.

Requests made to Stateless Worker grains are always executed locally, that is on the same silo where the request originated, either made by a grain running on the silo or received by the silo’s client gateway. Hence, calls to Stateless Worker grains from other grains or from client gateways never incur a remote message.

Our grain isn’t really doing anything, and it doesn’t need to. I’ve made it return a bool however, it could just return a Task. Returning a bool might be useful if you plan on doing any other check within the grain, such as maybe verify connections to db, etc.

Next, we’ll create our actual ASP.NET Core Health Check by implementing the IHealthCheck.

All our implementation is going to do is get the IHealthCheckGrain. If anything fails, we’ll return Unhealthy, otherwise its all good so we’ll return Healthy.

As you can see, I also added an extension method off of IHealthChecksBuilder just to simplify registering our new health check.

Finally, to wire up our new health check, we need to add AddHealthChecks and AddOrleansHealthCheck to our ConfigureServices. As well we need to call UseHealthChecks in the Configure method.


Now if you browse or make an HTTP call to the /health endpoint, you get a 200 OK with Healthy if the local silo is running.

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core

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

Introducing Orleans 3.0

We are excited to announce the Orleans 3.0 release. A great number of improvements and fixes went in, as well as several new features, since Orleans 2.0. These changes were driven by the experience of many people running Orleans-based applications in production in a wide range of scenarios and environments, and by the ingenuity and passion of the global Orleans community that always strives to make the codebase better, faster, and more flexible. A BIG Thank You to all who contributed to this release in various ways!

I was happy to see the generic host for co-hosting with something like ASP.NET Core. I’ve blogged Co-Hosting Orleans and ASP.NET Core which this about this feature.



A tool that helps you find transitive package references that can be removed.

> snitch Foo.csproj --tfm net462

Building Foo (net462)...

Building Bar (netstandard2.0)...

Building Baz (netstandard2.0)...

The following packages can be removed:

Autofac (ref by Baz)

Newtonsoft.Json (ref by Bar)

The following packages might be removed:

Castle.Core (ref by Baz) 4.4.0 <- 4.3.1 (Baz)


What’s Your Problem? – Asbjørn Ulsberg

A talk given by Asbjørn Ulsberg from PayEx at the 2019 Platform Summit in Stockholm.

An API isn’t stronger than its weakest link and what’s often ignored in the ongoing maintenance and development of an API is the constant effort required to provide great self-servicable error messages. What this means is that without great, user-friendly error messages, your API is not going to be great.

Just think about your first interaction with an API. How many failing requests have you sent before you have dug yourself through swathes of error messages and documentation to get to that one penultimate successful request making your heart sing and fists shaking in the air?

Great error messages make them not feel like errors, but like friendly guidance towards a working request. They should be detailed enough to let the developer fix whatever problem there is themselves, like a dialogue between a customer and a support technician.

This talk will give you ideas of how to handle errors and exceptions that occur in your application, be it with the incoming request, database failures or errors received from a 3rd party and how to serialize them into user friendly and actionable problem messages.


The next 5 years of ASP.NET Core – Ryan Nowak

Join Ryan Nowak on a tour of ASP.NET Core’s evolution from “Project K” to present day and look forward to a few possible futures. We’ll discuss technical design details of how the ASP.NET Core stack is changing from bottom (hosting and startup), through the server, middleware pipeline, and up to high-level frameworks like MVC and Blazor.

This is a technical deep-dive talk, and will explore possible design directions of .NET 5 and future releases.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.