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.

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.



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.


Efficient Params and String Formatting

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


Rider 2019.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.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Context is King: Finding Service Boundaries

Context is King: Finding Service Boundaries

Having explicit service boundaries is one of the tenets of SOA. Defining correct services boundaries is critical. I believe it’s one of the most important aspects of developing a system is finding service boundaries and it’s also really easy to get wrong.

This blog series is intended as a guide for finding service boundaries within a domain for the system you’re developing.

What’s a Service?

Before I get too far ahead, I better clarify what “service” means to me so we can be on the same page. If I can simplify it to a single sentence it would be:

A service is the authority of a set of business capabilities.

A longer explanation is a service owns all the business logic and data associated with a specific set of business capabilities in our system for our domain.

Here are some of the topics covered in this series.

Data Authority

Services should have full authority over the data they manage. The data that they manage should pertain to the capabilities it provides. No other service should be able to directly access or modify the data. If there is no capabilities provided by the service, it shouldn’t be a service, just a database.


Services should not rely on other code. They should be independent of each other. Prefer asynchronous messaging over RPC.

Services react to messages. The publisher of those messages doesn’t need to know if they were handled. The consumer of the messages does not need to know how they were created.

If RPC is required, create well defined interfaces for your service.


It’s always amazing to me that language can have such a giant impact on understanding a domain which can help to define boundaries.

My classic example is using a warehouse/distribution system that has a Product entity. A Product isn’t a Product isn’t a Product.

Meaning a product in one service can represent an entirely different set of data capabilities in another.

Which then leads me to entities…


I’m not sure where the industry got fixated on entities. Domain Driven Design might be partly to blame for this. It also could be the likes of ORM’s and having mappings to tables that represent entities.

Whatever the reason, I think they do a giant disservice by taking away focus from what really matters which are business capabilities, not entities.

Blog Series

More on all of these topics will be covered in greater length in future posts. Stay tuned. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.