Roundup #55: .NET Core 3, F# 4.7, AWS joins .NET Foundation, .NET Foundation Maturity Model, Finding Service Boundaries

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.

Announcing .NET Core 3.0

We’re excited to announce the release of .NET Core 3.0. It includes many improvements, including adding Windows Forms and WPF, adding new JSON APIs, support for ARM64 and improving performance across the board. C# 8 is also part of this release, which includes nullable, async streams, and more patterns. F# 4.7 is included, and focused on relaxing syntax and targeting .NET Standard 2.0. You can start updating existing projects to target .NET Core 3.0 today. The release is compatible with previous versions, making updating easy.

Link: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

Announcing F# 4.7

We’re excited to announce general availability of F# 4.7 in conjunction with the .NET Core 3.0 release! In this post, I’ll show you how to get started, explain everything in F# 4.7 and give you a sneak peek at what we’re doing for the next version of F#.

Link: https://devblogs.microsoft.com/dotnet/announcing-f-4-7/

AWS Joins the .NET Foundation

We’re excited to announce today that AWS is joining the .NET Foundation as a corporate sponsor. AWS has a long-standing commitment to .NET, with a decade of experience running Microsoft Windows and .NET on AWSJoining the .NET Foundation is a natural step for us to further invest and participate in this community.

Link: https://aws.amazon.com/blogs/opensource/aws-joins-the-net-foundation/

.NET Foundation Project Maturity Model

This proposal describes new approaches that we can use to improve the quality and quantity of .NET open source projects, and the .NET ecosystem generally. The .NET ecosystem is strong, but could be stronger still, and there are general challenges in open source projects that we should address in our ecosystem.

Link: https://github.com/dotnet-foundation/project-maturity-model

Context is King: Finding Service Boundaries Talk

Shameless plug of my own talk 🙂

Are you having trouble defining service boundaries? We know there are benefits in splitting up a complex system, such as more focused models and modular deployments.

Defining the correct service boundaries is incredibly important but can be pretty tricky. When defined correctly, the model feels natural and cohesive. Defined wrong can make a system overly complex and end in disaster.

Join Derek as he explores the use of key terminology in real business systems. How dissecting simple words and asking the right questions led to insights that helped define the service boundaries in real business systems developed over the last decade.

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

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #54: Service Provider Validation, Default Interface Members, BFF with ProxyKit, GC Perf

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.

ASP.NET Core 3: Service provider validation

In this post I describe the new “validate on build” feature that has been added to ASP.NET Core 3.0. This can be used to detect when your DI service provider is misconfigured. Specifically, the feature detects where you have a dependency on a service that you haven’t registered in the DI container.

Link: https://andrewlock.net/new-in-asp-net-core-3-service-provider-validation/

Default Interface Members, What Are They Good For?

The problem this solves is that if add a new member to an interface, every type that implements that interface will need to provide an implementation for that member. This may not be such a big deal if the interface is in your own code but as with any breaking change, in a library released to the public or other teams it can create a lot of headaches.

Link: https://daveaglick.com/posts/default-interface-members-what-are-they-good-for

Simplifying the BFF with ProxyKit – ASP.NET Core: From 0 to overkill

In this episode, we’ll revise our current backend for frontend implementation, introducing ProxyKit to simplify request routing to backing APIs, foregoing the need to implement everything manually.

Link: https://blog.codingmilitia.com/2019/09/11/aspnet-029-from-zero-to-overkill-simplifying-the-bff-with-proxykit

GC Perf Infrastructure – Part 0

In this blog entry and some future ones I will be showing off functionalities that our new GC perf infrastructure provides. Andy and I have been working on it (he did all the work; I merely played the consultant role). We will be open sourcing it soon and I wanted to give you some examples of using it and you can add these to your repertoire of perf analysis techniques when it’s available.

Link: https://devblogs.microsoft.com/dotnet/gc-perf-infrastructure-part-0/

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.