Skip to content

Roundup #68: Binding Redirects, Combining Types as Effects to Describe an Application, Endpoint from multiple middleware, Clean Architecture

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.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Binding Redirects

You’re probably here because of an error like this:

Could not load file or assembly ‘System.<…>, Version=4.x.x.x, Culture=neutral, PublicKeyToken=<…>’ or one of its dependencies. The system cannot find the file specified.

And you likely saw a build warning like this:

warning MSB3277: Found conflicts between different versions of “System.<…>” that could not be resolved.

Whelp, you’re not alone. We’re thinking about starting a survivors group.

If someone starts a survivors group, I’m joining. I’ve spent a serious amount of time and head-scratching over binding redirects. Specifically around System.Net.Http. The answer in my case was using <AutoGenerateBindingRedirects>


Combining Types as Effects to Describe an Application

I can only imagine the face I made the first time someone referred to the type of an application. Coming from a Delphi, .NET, and web background at the time, I assumed the type of an application was Web vs Desktop vs Command Line. What I came to understand was that types can be used to model effects which can then determine what your application does.

Reid pointed out this post he wrote after I posted the following tweet (and my typo of “ton”… oops). I highly recommend reading this as Reid points out something I’ve never really thought of before.


Creating an endpoint from multiple middleware in ASP.NET Core 3.x

In a recent post I discussed the changes to routing that come in ASP.NET Core 3.0, and how you can convert a “terminal” middleware to the new “endpoint” design. One question I’ve received is whether that removes the need for “branching” the pipeline, and if not, how can you achieve the same thing with endpoints?

This short post assumes that you’ve already read my post on converting a terminal middleware to endpoint routing, so if you haven’t already, take a look at that one first! I give a quick recap below, but I won’t go into details.


The Clean Architecture – Ian Cooper

What is the clean architecture and how you would build one in .NET? Recently Bob Martin has categorized a set of architectures, including hexagonal architecture, onion architecture and screaming architecture as ‘the clean architecture’ – a layered architecture of concentric circles with a strong emphasis on separation of concerns. This architecture has become popular because of its amenability to modification as an evolutionary architecture and its support for practices such as TDD. In this presentation we will discuss the clean architecture and its benefits. More than that, in the bulk of the presentation, we will show you how to implement a clean architecture in .NET. From first steps to working code, we will show you the moves required to embrace this approach, and introduce you to some of the OSS libraries that can help you get there. All examples will be in .NET Core


Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Leave a Reply

Your email address will not be published. Required fields are marked *