Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
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 1.0 and 1.1 will reach End of Life on June 27, 2019
.NET Core 1.0 was released on June 27,
2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reachend of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.
Link: https://devblogs.microsoft.com/dotnet/net-core-1-0-and-1-1-will-reach-end-of-life-on-june-27-2019/
gRPC for dotnet
We plan to implement a fully-managed version of
gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NETplaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the
mananged client experience in 3.0.
Link: https://github.com/grpc/grpc-dotnet/
Adding a GraphQL Endpoint to Your ASP.NET Core API
Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.
Link: https://rolandguijt.com/adding-a-graphql-endpoint-to-your-api/
Introduction to Benchmarking C# Code with Benchmark .NET
Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark
.NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.
Link: https://www.stevejgordon.co.uk/introduction-to-benchmarking-csharp-code-with-benchmark-dot-net
Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard
Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!
Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.
In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.