Roundup #42: Nancy, BuildXL, String Params, Rider, Infra Code

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.

Nancy 2.0.0

Pretty sure everyone has been using Nancy 2.0.0-clinteastwood in production for the past 2 years but regardless, official 2.0 release.

Link: https://www.nuget.org/packages/Nancy/

BuildXL

Build Accelerator, BuildXL for short, is a build engine originally developed for large internal teams at Microsoft, and owned by the Tools for Software Engineers team, part of the Microsoft One Engineering System internal engineering group. Internally at Microsoft, BuildXL runs 30,000+ builds per day on monorepo codebases up to a half-terabyte in size with a half-million process executions per build, using distribution to thousands of datacenter machines and petabytes of source code, package, and build output caching. Thousands of developers use BuildXL on their desktops for faster builds even on mega-sized codebases.

Link: https://github.com/Microsoft/BuildXL

Efficient Params and String Formatting

This combination of features will increase the efficiency of formatting string values and passing of params style arguments.

Link:https://github.com/dotnet/csharplang/blob/master/proposals/format.md

Rider 2019.1

Link https://www.jetbrains.com/rider/whatsnew/#v2019-1

5 Lessons Learned From Writing Over 300,000 Lines of Infrastructure Code

This talk is a concise masterclass on how to write infrastructure code. I’ll share key lessons from the “Infrastructure Cookbook” we developed at Gruntwork while creating and maintaining a library of over 300,000 lines of infrastructure code that’s used in production by hundreds of companies. Come and hear our war stories, laugh about all the mistakes we’ve made along the way, and learn what Terraform, Packer, Docker, and Go look like in the wild. Topics include how to design infrastructure APIs, automated tests for infrastructure code, patterns for reuse and composition, patterns for zero-downtime deployments, refactoring, namespacing, versioning, CI / CD for infrastructure code, and more.

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

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #41: Apache Spark, Strongly Typed EntityIDs, Azure Workers, Automapper, NetCore3 Progress

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 for Apache® Spark™ Preview

Today at Spark + AI summit we are excited to announce .NET for Apache Spark. Spark is a popular open source distributed processing engine for analytics over large data sets. Spark can be used for processing batches of data, real-time streams, machine learning, and ad-hoc query.

Link: https://devblogs.microsoft.com/dotnet/introducing-net-for-apache-spark/

Using strongly-typed entity IDs to avoid primitive obsession

Have you ever requested an entity from a service (web API / database / generic service) and got a 404 / not found response when you’re sure it exists? I’ve seen it quite a few times, and it sometimes comes down to requesting the entity using the wrong ID. In this post I show one way to avoid these sorts of errors by acknowledging the problem as primitive obsession, and using the C# type system to catch the errors for us.

Link: https://andrewlock.net/using-strongly-typed-entity-ids-to-avoid-primitive-obsession-part-1/

.NET Core Workers in Azure Container Instances

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 you’ll learn how to use a Worker with Azure Container Registry and Azure Container Instances to get your Worker running as a microservice in the cloud.

Link: https://devblogs.microsoft.com/aspnet/dotnet-core-workers-in-azure-container-instances/

AutoMapper Usage Guidelines

A list of Do and Do Not for best practices if you’re using Automapper. I just saw that a new version was released and it made me think of this post.

Link: https://jimmybogard.com/automapper-usage-guidelines/

.NET Core 3.0 – progress on bugs, weekly update from 4/24

Link: https://twitter.com/ziki_cz/status/1121126233792585728

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Using AWS Parameter Store for ASP.NET Core Data Protection Keys

Using AWS Parameter Store for ASP.NET Core Data Protection Keys

If you’re using ASP.NET Core in AWS under any type of load balanced scenario, either through Elastic Beanstalk or an ALB with and ECS, etc, you will need to share the data protection keys. This is because each instance of your application needs to be using the exact same keys.

This isn’t an issue if you are using a single instance as the keys will be stored in memory.

If you haven’t yet used the AWS SDK, I highly recommend first checking out my quick start on configuring AWS SDK in ASP.NET Core.

AWS Systems Manager Parameter Store

One option is to use Parameter store to store the data protection keys. Thankfully AWS has released a nice little package to make this really simple.

First, add the Amazon.AspNetCore.DataProtection.SSM package to your csproj.

Now you can use the PersistKeysToAWSSystemsManager method passing the prefix as the parameter.

That’s it! That simple. Now when you run your application, you will see that a new parameter has been created with the prefix you specified followed by key-{GUID}.

ASP.NET Core Data Protection

If you want to persist data protection keys to somewhere like S3, check out this other post.

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.