Co-Hosting Orleans and ASP.NET Core

Orleans and ASP.NET Core

With the release of Orleans 3.0 comes the ability to co-host with ASP.NET Core (or any other framework that uses the generic host builder).

What this means is you can run Orleans and ASP.NET Core in the same process.

The advantage to this is both services will share the same service provider, logging, etc that is configured with the host builder.

Orleans and ASP.NET Core

The extension method UseOrleans() is available now on the IHostBuilder. Just like you would configure the ASP.NET Core via ConfigureWebHostDefaults, you can configure the Orleans silo.


One of the nice benefits here is that because both services share service registrations, an ASP.NET Core MVC controller can have the IClusterClient injected into it.

Also since logging is configured it is shared between both ASP.NET Core and Orleans. When I run my demo application, you can see both services in my console logs.

Health Checks

Another benefit of co-hosting Orleans and ASP.NET Core is you can provide a frontend via ASP.NET Core to expose status of your Orleans silo. I’ve written about the ASP.NET Core Health Checks over on the Telerik Blog.

If you’re running in something Docker, AWS ECS or Kubernetes, this would provide you information to determine the health/liveness of your services

Orleans 3.0

If you want more info on the 3.0 release, check out the Announcement for all the details.

Also, check out other related posts:

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Detecting Sync over Async Code in ASP.NET Core

Sync over Async

It’s pretty easy to write some bad async code, especially when you first start using async/await. Async/await is pretty viral in .NET, which means it generally goes all the way through the stack. This can be challenging if you are trying to add async/await to an existing app and you usually end up adding sync over async code.

If you don’t use async/await correctly, and end up writing sync-over-async code, you’ll ultimately end up causing ThreadPool starvation.

Sync over Async

The term refers to making an async call but not awaiting it. Often time this is caused by calling .Wait() or .Result on the returned Task.


Ben Adams wrote a Blocking Detector for ASP.NET Core.

Start by adding the NuGet package Ben.BlockingDetector to your csproj.

At the very beginning (or the higher the better) of your Configure() method in your Startup, add the UseBlockingDetection() extension method to the IApplicationBuilder.

That’s it. Really. Now when we run our application and hit the /sync-over-async route from the example above, a warning is logged in the console (or however you have logging configured).

I’ve added the red arrow to point out our sync-over-async method in the call stack.


Another great tool is the Microsoft.VisualStudio.Threading.Analyzers NuGet Package.

Static code analyzer to detect common mistakes or potential issues regarding threading and async coding.

Simply add it the PackageReference to your csproj and by default, you will immediately be getting warnings about sync over async calls. Here’s a screenshot in JetBrains Rider (which also can use Roslyn analyzers) that is notifying us of the issue.

Are you using any other analyzers or packages to detect blocking or problematic async code? Let me know in the comments or on Twitter.

Related Posts: I’ve also written a post on Lazy Async which try’s to solve the issue of deferring doing IO until it’s first needed.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #52: .NET Core and systemd, System.Threading.Channels, screencastR, Configuration Pitfalls

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.

.NET Core and systemd

In preview7 a new package was added to the Microsoft.Extensions set of packages that enables integration with systemd. For the Windows focused, systemd allows similar functionality to Windows Services, there is a post on how to do what we discuss here for Windows Services in this post. This work was contributed by Tom Deseyn from Red Hat. In this post we will create a .NET Core app that runs as a systemd service. The integration makes systemd aware when the application has started/is stopping, and configures logs to be sent in a way that journald (the logging system of systemd) understands log priorities.


An Introduction to System.Threading.Channels

I’ve recently begun making use of a relatively new (well, it’s a little over a year old at the time of writing) feature called “Channels”. The current version number is 4.5.0 (with a 4.6.0 preview also available as pre-release) which makes it sound like it’s been around for a lot longer, but in fact, 4.5.0 was the first stable release of this package!

In this post, I want to provide a short introduction to this feature, which I will hopefully build upon in later posts with some real-world scenarios explaining how and where I have successfully applied it.


screencastR – Simple screen sharing app using SignalR streaming

In this article, we will see how to create simple screen sharing app using signalR streaming. SignalR supports both server to client and client to server streaming. In my previous article , I have done server to client streaming with ChannelReader and ChannelWriter for streaming support. This may look very complex to implement asynchronous streaming just like writing the asynchronous method without async and await keyword. IAsyncEnumerable is the latest addition to .Net Core 3.0 and C# 8 feature for asynchronous streaming. It is now super easy to implement asynchronous streaming with few lines of clean code. In this example, we will use client to server streaming to stream the desktop content to all the connected remote client viewers using signalR stream with the support of IAsyncEnumerable API.


Avoiding ASP.Net Core Configuration Pitfalls With Array Values

ASP.NET Core continues to improve on the legacy of the .NET Framework. Our team is impressed with its performance and excited about future possibilities, but change is seldom a smooth transition. In this post, I’ll explain a pitfall you may run into using the newest configuration model in .NET Core and options to mitigate the issue.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.