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.

Link: https://devblogs.microsoft.com/dotnet/introducing-net-5/

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

Link: https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-3.0

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.

Link: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

ASP.NET Core on App Service Dashboard

Link: https://aspnetcoreon.azurewebsites.net/

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.

Link: https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/

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.

Amazon.Extensions.Configuration.SystemsManager

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.

Configure

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.

Configuring AWS SDK in ASP.NET Core

Configuring AWS SDK in ASP.NET Core

If you’re using any AWS Services, you’re likely going to be using the AWS SDK via NuGet packages. You don’t need to configure anything to start using the SDK, but there are a few things that can make your life a lot easier. Follow along for a how-to on configuring AWS SDK in ASP.NET Core.

AWS CLI Named Profiles

The AWS Command Line Interface (CLI) is the first thing you’re going to want to have. Beyond controlling AWS services it allows you to configure credential profiles.

Once you have the CLI installed, to configure the default profile simply run and follow the prompt to enter your access key, secret and region.

> aws configure

For the rest of this example, I’m going to be using the default profile that I’ve configured that contains my access key and secret.

AppSettings

The AWS SDK will look for an AWS key in your appsettings.json file. It will use this section for configuration. In this section, you can define which Profile to use as well as many other options including as Region.

Environment Variables

You can also use Environment Variables to define these same settings. Be sure to use colon as hierarchy.

Startup.cs

The AWSSDK.Extensions.NETCore.Setup NuGet package that adds extension methods to IConfiguration and IServiceCollection that makes it simple to retrieve AWS configuration and types.

Now if you inject the IAmazonS3 from a Controller or even if you resolve it from context.RequestServices.GetService<IAmazonS3>() you will get out an instance that is auto-configured with the access key and secret from your Default profile as well as the Region defined in your appsetting or Environment Variable.

AWS SDK in ASP.NET Core

That’s the quick start way of being able to use the AWS SDK without having to specify any of your credentials in your source as well as being able to use dependency injection to have the AWS SDK types resolve pre-configured.

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.