Roundup #43: .NET 5, gRPC, .NET Core 3 Perf, App Service Dashboard, Interface Default Implementation

I was away while Microsoft BUILD happened last week. After catching up, 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.

Introducing .NET 5

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.

There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.

There were a lot of announcements at Build but this is the one that caught most of my attention.


Introduction to gRPC on ASP.NET Core

gRPC is a language agnostic, high-performance Remote Procedure Call (RPC) framework. For more on gRPC fundamentals, see the gRPC documentation page.

I never noticed the docs available for gRPC. Most notably is the Comparing gRPC services with HTTP APIs


Performance Improvements in .NET Core 3.0

Back when we were getting ready to ship .NET Core 2.0, I wrote a blog post exploring some of the many performance improvements that had gone into it. I enjoyed putting it together so much and received such a positive response to the post that I did it again for .NET Core 2.1, a version for which performance was also a significant focus. With //build last week and .NET Core 3.0‘s release now on the horizon, I’m thrilled to have an opportunity to do it again.


ASP.NET Core on App Service Dashboard


Default implementations in interfaces

With last week’s posts Announcing .NET Core 3.0 Preview 5 and Visual Studio 2019 version 16.1 Preview 3, the last major feature of C# 8.0 is now available in preview.

A big impediment to software evolution has been the fact that you couldn’t add new members to a public interface. You would break existing implementers of the interface; after all they would have no implementation for the new member!

Default implementations help with that. An interface member can now be specified with a code body, and if an implementing class or struct does not provide an implementation of that member, no error occurs. Instead, the default implementation is used.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Using AWS Parameter Store for .NET Core Configuration

Parameter Store for .NET Core

One of the aspects I love about .NET Core is the new configuration and options pattern. In a continuation from my last post on using AWS Parameter Store for Data Protection keys, you can imagine it is possible to use Parameter Store for .NET Core Configuration.


There is a package by AWS that facilitates making using Parameter Store incredibly easy. Simply add the Amazon.Extensions.Configuration.SystemsManager package to your project and use the AddSystemsManager extension method on IConfigurationBuilder

The argument you pass to AddSystemsManager will be the prefix to your configuration hierarchy within Parameter Store. In my example, I’m using /Demo as my prefix, as you will also see below.

If you look at the first two entries, I can now create classes that match this hierarchy.


Next step is to add this configuration via the IServiceCollection using the Configure<T> method. Where T is our configuration type DemoConfig

This will add registration for the type IOptions<DemoConfig> so we can inject it in our Controllers or anywhere else the ServiceProvider is used.

This results in our config variable being set to the values from Parameter Store.

Parameter Store for .NET Core

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

Related Links:

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #40: Workers, NET 4.8, Require 4.7.2, AWS SDK, Developer Survey

Been out several weeks from posting a roundup, but it’s back!

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 Workers as Windows Services

In .NET Core 3.0 we are introducing a new type of application template called Worker Service. This template is intended to give you a starting point for writing long running services in .NET Core. In this walkthrough we will create a worker and run it as a Windows Service.

I think this is pretty great and seems really logical. There are so many use cases and the most obvious to me is long running process for something like processing jobs off a queue.


Announcing the .NET Framework 4.8

We are thrilled to announce the release of the .NET Framework 4.8 today. It’s included in the Windows 10 May 2019 Update. .NET Framework 4.8 is also available on Windows 7+ and Windows Server 2008 R2+.

I realize there have been many posts about .NET Framework not being “dead” because it’s built into Windows, but “dead” to me clearly means something different. There is a lot of effort being put into being able to migrate to .NET Core. The future is .NET Core. Is the .NET Framework going anywhere? No, but don’t expect much else beyond 4.8 in my opinion.


Require .NET Framework 4.7.2

This shows how you can author a NuGet package that will provide an error message if the consumer is on .NET Framework 4.6.1 – 4.7.1.

Unfortunately, this is needed because NuGet will allow you to install a package on 4.6.1+ when netstandard2 is really only truly supported on 4.7.2. This is an unfortunate mistake and guidance early on that caused a pile of confusion.


AWS SDK for .NET now targets .NET Standard 2.0

As .NET Core and .NET Standard have matured since their initial release, Microsoft has been encouraging the community to set the baseline for .NET Standard libraries to be 2.0. .NET Standard 2.0 improves how dependencies are resolved. Taking a dependency on library that does not target .NET Standard 2.0 potentially caused confusing build errors or required unnecessary .NET assemblies in project deployment packages.


Stack Overflow Developer Survey Results 2019

Stack Overflow’s annual Developer Survey is the largest and most comprehensive survey of people who code around the world. Each year, we field a survey covering everything from developers’ favorite technologies to their job preferences. This year marks the ninth year we’ve published our annual Developer Survey results, and nearly 90,000 developers took the 20-minute survey earlier this year.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.