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.

Link: https://devblogs.microsoft.com/dotnet/orleans-3-0/

Snitch

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)

Link: https://github.com/spectresystems/snitch

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.

Link: https://www.youtube.com/watch?v=ZWIUn5BHDBc

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.

Link: https://www.youtube.com/watch?v=7dJBmV_psW0

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

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.

Benefits

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.BlockingDetector

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.

Microsoft.VisualStudio.Threading.Analyzers

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.