Thread Deadlock

Thanks to @t0m-4 for reporting this issue, which due to Microsoft deprecating some of the "sync" APIs for decryption, led to potential thread starvation and locking issues. The update still has to use a "sync-over-async" pattern, but does so in a much safer manner.

Security

We fixed an issue where certain cyclic or self-referential object graphs could trigger uncontrolled recursion during mapping, potentially resulting in stack exhaustion and denial of service.

Applications that process untrusted or attacker-controlled object graphs through affected mapping paths may be impacted.

Users should upgrade to this release.

Security advisory: GHSA-rvv3-g6hj-g44x

Thanks to @skdishansachin for responsibly disclosing this issue.

• AutoMapper Release Notes
• MediatR Release Notes

AutoMapper added some interesting features, allowing for factories and conditions to use dependencies (previously only allowing Func-based callbacks. On the MediatR side, we added support for more interesting generic use cases in complex generic hierarchies as well as a number of bugs squashed.

You can get the latest drops on NuGet. And a little celebration is in order - AutoMapper hit 1 billion downloads 🥳

Enjoy!

From this release forward, we're aligning to major release cadences of .NET since this also means upping our dependency versions as well. Minor versions will still happen throughout the year but upping dependencies often has just as many issues as breaking API changes so we want to align with that cadence to make it easier for folks to understand when things are changing.

This release doesn't have any API changes from the previous minor release, but we did add NuGet package signing:

This shows that the AutoMapper (and MediatR) packages were published by Lucky Penny Software (my company) and not...Unlucky Penny Software? Getting this additional security verification is important for customers to know that this package comes from us and not some other entity. Getting verified for code signing certificates is a fairly involved process doing things like "taking selfies with my passport".

Downloads and release notes below:

• AutoMapper NuGet
• AutoMapper v16.0.0 Release Notes
• MediatR NuGet
• MediatR v14.00 Release Notes

Enjoy!

• AutoMapper 15.1.0 Release Notes
• MediatR 13.1.0 Release Notes

The previous versions restored netstandard2.0 support across the board. In these releases, I'm including first-class support for net462 where I'm building and testing on both *nix and Windows. We noticed that just including netstandard2.0 as a target framework wasn't enough to really guarantee that the libraries would work against full .NET, so we now build and test on both.

There's some new features, enhancements, and bug fixes that you can view in the release notes above.

Enjoy!

Tracking official .NET support

Firstly, the latest releases bring back netstandard2.0 support for both AutoMapper and MediatR which had dropped both years ago. MediatR was actually still on net6.0 prior to this release which was already out of support for months.

It wasn't exactly easy, especially because of how much net8.0 and net9.0 have diverged from netstandard2.0 not just in terms of APIs but C# language features, but having been part of several ASP.NET 4.x to ASP.NET Core migrations, having netstandard2.0 support makes this transition quite a bit easier. In the past we'd have to conditionally reference packages because there was no longer a common package version between say .NET 8 and .NET 4.8. That's something that I wish I had before that now I do.

AutoMapper Roadmap

One of the biggest complaints I hear about AutoMapper is that it's hard to debug - you're trading compile-time errors for runtime exceptions. We spent a LOT of time baking in better exception handling into the expression trees generated (resulting in worse performance, but better diagnostics), but that isn't always enough.

The answer here is source generators, but I'm not interested in merely copying other library's approaches. What I want to target is source generators that:

• Plug in to AutoMapper's rich extensibility model
• Stay true to AutoMapper's design philosophy
• Support IQueryables (my favorite feature)
• Track the features of AutoMapper's in-memory mapping
• Support mapping validation (critical for any mapping tool)

Debuggability is my main focus here, although obviously performance would be a secondary win. Source generators have come a LONG way since I first looked at them when they were first released, so I'm excited to extend AutoMapper's functionality in this area.

This one is pretty big, so that's going to be my focus initially.

MediatR Roadmap

Some folks have asked or even pointed to other libraries that do source generation of basically a copy of MediatR's API. I am looking at that, but there's been quite a few things on MediatR's backlog that I want to look at first. Source generation in mediators I find a bit less interesting in real-world projects, outside of philosophical debates.

MediatR is commonly used in concert with Vertical Slice Architecture, and a number of its features came out of using it in these scenarios (like behaviors). Today, a lot of features are tied in to the feature set of the stock Microsoft DI container. Unfortunately, features are only really added to that container if the ASP.NET Core team needs them. Even my PR to support generic constraints took like 5 years to merge in.

Moving away from relying on those DI features would mean I could do much more interesting things in the "application use case pipeline" that aren't possible with C#/DI alone, like:

• Applying behaviors based on customized policies
• Baking in support for result patterns
• Direct support for application use cases
  • Blazor (sending a request from the client to a handler on the server)
  • Minimal APIs (scaffolding to separate API logic from application logic)
  • Domain events via notifications and EF/other ORMs

The idea of behaviors came from reviewing many production systems using MediatR and folding in that into first-class features. I am going to continue on this track.

What else are you interested in?

The GitHub repositories have transferred to the new GitHub organization (along with their ownership) here:

• LuckyPennySoftware/AutoMapper
• LuckyPennySoftware/MediatR

With these, I've launched new home pages for each library:

• https://automapper.io
• https://mediatr.io

As well as a storefront site to purchase and manage licenses at:

• https://luckypennysoftware.com

It's quite a bit to dig in to, so let's go over the details!

What's the new license?

As discussed before, I wanted to release these libraries under a dual-license model:

• Reciprocal Public License 1.5 (RPL1.5)
• Lucky Penny Software Commercial License

It's a common dual-license model that many other OSS companies have chosen (MongoDB etc.) and had success with.

Under the commercial license, I've created a tier-based licensing model based on team size. There are no individual per-seat licenses, only licensing based on the number of developers.

How much will it cost?

With a tier-based pricing approach, I wanted a pricing model that scales with team size and allows for company growth without a lot of hassle. There are 3 paid tiers:

• Standard - 1-10 developers
• Professional - 11-50 developers
• Enterprise - Unlimited developers

Pricing is a subscription model, with both monthly and annual subscriptions (with a discount for annual subscriptions), as well as an option to bundle both libraries at a discount. You can find the details here (with all options), priced to your currency or in USD:

• AutoMapper pricing
• MediatR pricing

You can also find the details of what subscription benefits you'll get at the links above, including:

• Private Discord channels
• Priority support
• Early access to new releases
• Support for all currently supported versions of .NET Framework 4.x and .NET (netstandard2.0, net8.0, net9.0)
• And more (as I build it)

All subscription payments are managed through Paddle, which supports...many different countries, currencies, and payment providers.

Do you have free licenses for <insert situation here>?

Yes! Besides the RPL license, I'm also including a Community edition under the Commercial license that is free for:

• Companies and individuals under $5,000,000 in gross annual revenue
• Non-profits under $5,000,000 in annual total budget (expenditure)
• Educational/classroom use
• Non-production environments

You're still required to register for a license key, but this is only for auditing purposes.

How do I get the commercial versions?

To make everyone's lives easier, these new major versions of AutoMapper and MediatR on NuGet are released under the new dual license agreement:

• AutoMapper v15.0
• MediatR v13.0

When you install these versions, you'll now be prompted for license acceptance. Once you obtain a license key, you'll be able to set the license key as:

services.AddAutoMapper(cfg => /* or AddMediatR */
    cfg.LicenseKey = "<License key here>";
});

I don't restrict usage of these products with a missing/invalid/expired license key, but you'll see some messages in your logs prompting you to supply a valid key.

What about the existing versions?

I've created archived versions of the final releases of these two libraries:

• AutoMapper/AutoMapper.Archive
• jbogard/MediatR.Archive

Per those existing license agreements, you're free to fork, download, print out and read by the fireplace. Those archives will live on for anyone to use as they like.

If you're an existing user, you don't need to do anything. The existing NuGet packages (prior to the major versions listed above) are bound by the license agreements at the time of their release and will also live on.

Why Lucky Penny?

Because she was my first dog! Although she's no longer with us anymore, I loved her spunk and her spirit and wanted to honor her memory with my company name (and logo). Here she is judging, always judging:

I named her Penny because 1) she was found by the side of a busy highway miles from anywhere (lucky for both of us) and 2) her copper color. So, Lucky Penny Software!

It's been a long journey to get here but I'm excited about what the future holds for these libraries that have amassed more than 1.1 billion downloads. Thanks everyone for your patience and support as I worked to launch!

There is a TON of information out there on possible models for sustainable open source, such as:

• Consulting services
• Open core
• Hosted services
• Dual license
• a dozen others

Of course besides my previous situation, "be fortunate enough to work at a place that values and directly sponsors your work." This is the easiest place to be, but for projects that reach some threshold of users/downloads/complexity, maintainers must rely on sponsorship in some form or fashion. And when that sponsorship goes away for whatever reason, well, here we are.

Of the many options available, the most viable option is to move AutoMapper and MediatR to a dual license model. This looks to be the best choice after carefully examining the options and consulting with many other OSS maintainers who have already made this journey.

Dual Licensing Model

When I first started thinking about how I might go about this, I asked myself, "who bears the most responsibility in ensuring the sustainability of the OSS projects on which they depend?" which is a long winded way of saying "who should pay?" But another way of thinking of this is "who should NOT pay?" Looking at how others do this as well as how I want to approach it, I want to make these libraries free for:

• Developers using it in an OSS setting
• Individuals/students/hobbyists (using AutoMapper for fun not profit)
• Non-profit/charities (maybe not for fun but also not for profit)
• Startups or small companies (below some revenue/funding threshold)
• Non-commercial setting (this I'm not sure is absolutely necessary with the other categories)
• Non-production environments (instead of any trial period etc.)

I don't know if this exact verbiage is what will be the end result, but this is my overall goal.

Then for who I'm targeting for paid for-licenses, it's for-profit businesses using these libraries for commercial activities. Looking at my clients over the years who've used my libraries, it's a mix of these free/commercial categories.

In terms of a model for commercial licensing, I want to ensure that paid licenses add value beyond "I can download the license." This is the more fun part of this exercise for me, where I can try the things I never really could before without a more direct form of sponsorship/funding. I have a lot of ideas here, but nothing ready to share yet. If you have an idea of "if my company paid for a license, what else would I want to have included?" I would love to hear about it!

I am looking at a tiered license model but no per-seat licenses. I don't want to charge individual developers anything—that seems like a pain for everyone involved and I'm trying to keep things simple. "A new developer gets onboarded and now we need a new license" is too much for me to deal with and goes against the spirit of these libraries—the benefit is to the entire team, regardless of the number of developers.

I don't know what those tiers will be exactly, I'm figuring that out next. I do expect some blanket enterprise, site-wide licenses that hopefully makes everything simpler for everyone. I've been on the other side of the table, getting licenses approved internally with clients, and I understand predictability and simplicity go a long way.

Thoughts on Pricing

As for pricing, I don't have details yet, and probably won't until launch in the next couple months. Range-wise, it's hard to compare to other commercial or dual-licensed products out there, since I don't want to do any individual or per-seat license and that seems to be the norm. I am however keenly aware of how much tooling and library products cost as I have to pay for many of these myself.

But if I were to compare to the cost for a team of 10 or 50 or 100 for their IDEs, I would expect my commercial license price to be a fraction of that.

Thanks again to everyone that's reached out with kind words and support, and to the community for their patience while I figure things out.

In order to ensure the long-term sustainability of my OSS projects, I will be commercializing AutoMapper and MediatR.

I did not post this on April 1st for obvious reasons. But first a little background on how I got to this point.

How I Got Here

These two projects originated at my time at Headspring, a consulting company I worked at for over 12 years. About 5 years ago, in January 2020, I decided to strike off on my own and give solo consulting a try. Although it was a scary leap, it's been more rewarding than I could have possibly hoped for, in almost every area.

The area that it didn't work out well, and not at all intentionally, was OSS work:

You can see exactly where my contributions cratered and flat-lined. And that's just commits—issues, PRs, discussions, all my time dried up. This wasn't the intention but was a natural side effect of me focusing on my consulting business.

At Headspring, my time on OSS was directly encouraged and sponsored by them. I could use time between projects to invest back in existing OSS or new OSS, because it benefited the client, the company, and the employees (me and my coworkers).

With me leaving that company, and that company then selling to Accenture later that year, I had no direct major sponsor of my OSS work anymore. My free time was being spent growing and ensuring the success of my consulting company, which being solo, is...kinda important.

Taking time to see how things have been going on all fronts, I had a bit of a shock looking at my OSS work. I realized that model is not sustainable for the long-term success of these projects, which I still endorse and believe in. I need to be able to pay for my time to work on these projects, and get direct feedback from paying clients, like I had earlier at Headspring.

What Will This Look Like?

The short answer is "I don't know exactly". I'm working out those details now and will share them when I figure it out. I have lots of examples of what does and doesn't work well, at least from my perspective, as well as what I consider will work well for these projects.

Short term, nothing will change. I'll still be as (un)responsive on GitHub issues, and I just pushed out a couple releases of any existing work.

My goal is to be able to pay for the time to spend actually improving these projects, building out communities, helping more users, and in general, doing the things that people have asked me MANY times over the years that I should do, but I didn't, because it was not my job. OSS was/is/never will be a hobby for me. I want to change it to at least be part of my job and to fund real work.

I can’t rely on donations, I don't want to make developers pay anything or do anything to punish/annoy them, and I certainly don't think it's Microsoft's job to "pay me the money." Past that, I'm still figuring it out.

When Will This Happen?

I don't know, it's still just me that owns everything. It's still using my free time to sort it out, as my day job is still a consultant. But I plan to be open with this whole process. I'm sure I'll surprise someone but the goal here is to be transparent.

Personally, I'm both filled with excitement and dread—doing these projects for so long has been incredibly rewarding, especially as this is code that came directly out of many, many long-lived production-deployed projects at Headspring. But I don't want these projects to wither and die on the vine, I want them to grow and evolve and thrive. But not just these projects—I want ALL my OSS projects (Respawn etc.) to thrive. This is how it needs to happen.

Final Thanks

Thanks to all that have contributed over the years, and especially to Lucian Bargaoanu who really helped pick up the torch with AutoMapper after I more or less fell off the map. Also thanks to my GitHub sponsors, as many a pint has been purchased with your generous support. And finally thanks to the community, I never hoped anything I built would help anyone beyond my clients, coworkers, and company, but it's always nice to hear that it has.

• Release Notes
• NuGet

This is mainly a regular minor release with a couple extra interesting features:

• Adding convenience method to register open behaviors
• Better cancellation token support (it's passed now everywhere including behaviors)

And some other cleanup items as well. Enjoy!

• Release notes
• NuGet

This release targets .NET 8 (up from .NET 6 from the previous release). It's mainly a bug fix release, with some quality-of-life improvements in configuration validation where we gather up all the possible validation errors before reporting them in an aggregate exception.

Enjoy!

I'll follow up in another post about Aspire impressions, but the NServiceBus part was actually relatively simple. Many Aspire integrations have some kind of 1st-party support where you can do things like:

var rmqPassword = builder.AddParameter("messaging-password");
var dbPassword = builder.AddParameter("db-password");

var broker = builder.AddRabbitMQ(name: "broker", password: rmqPassword, port: 5672)
    .WithDataVolume()
    .WithManagementPlugin()
    .WithEndpoint("management", e => e.Port = 15672)
    .WithHealthCheck();
var mongo = builder.AddMongoDB("mongo");
var sql = builder.AddSqlServer("sql", password: dbPassword)
    .WithHealthCheck()
    .WithDataVolume()
    .AddDatabase("sqldata");

And now my system has RabbitMQ, MongoDB, and SQL Server up and running in containers. There's a lot of stock configuration going on behind AddSqlServer and similar methods but we don't have to use those convenience methods if we don't want to.

The overall Service Platform architecture looks something like:

The "instances" here are running containers that we need to configure in Aspire. On top of that, we might also want to have Service Pulse (another container) and Service Insight (a Windows-only WPF app) running, and these all require extra configuration. Also, the Error and Audit instances use RavenDB as their backing store but Particular also has an image there. The Docker Hub site has links to docs on both the instance and containers.

First up, we need to provide our license to the running containers as raw text in an environment variable, so we'll just read our license (this is just for local development):

var license = File.ReadAllText(                                              
    Path.Combine(                                                            
        Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
        "ParticularSoftware",                                                
        "license.xml"));                                                     

Next, we need our RavenDB instance. There's a special image from Particular, so we'll use the AddContainer method to add our custom image to our Aspire distributed application:

builder                                                                             
    .AddContainer("servicecontroldb", "particular/servicecontrol-ravendb", "latest")
    .WithBindMount("AppHost-servicecontroldb-data", "/opt/RavenDB/Server/RavenData")
    .WithEndpoint(8080, 8080);                                                      

The container docs say that we must mount a persistent volume to that path, so we use the WithBindMount method to mount the volume following the Aspire docs.

Next up are the Particular containers!

Setting up the Service Control Error instance

From the Particular docs, we see that we need to supply configuration for:

• Transport type (RabbitMQ, Azure Service Bus, etc.)
• Connection string to the transport
• Connection string to the Raven DB instance
• Audit instance URLs
• License

Plus port mapping. Pretty quickly I ran into a few challenges:

• The Service Control image can start before RabbitMQ is "ready", resulting in connection failures
• Service Insight, the WPF app, is Windows only so I need to connect to Service Control from a VM

The base configuration is fairly straightforward, we specify the container and image, with environment variables:

builder                                                                                             
    .AddContainer("servicecontrol", "particular/servicecontrol")                                    
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")                         
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                               
    .WithEnvironment("RavenDB_ConnectionString", "http://host.docker.internal:8080")                
    .WithEnvironment("RemoteInstances", "[{\"api_uri\":\"http://host.docker.internal:44444/api\"}]")
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                                         
    .WithArgs("--setup-and-run")                                                                    

But the other two challenges are a bit harder to deal with. There is no built-in way in Aspire to "wait" for other resources to start. This isn't new to Aspire - in the past we had to write custom hooks in Docker Compose to wait for our dependencies' health checks to come back. The extensibility is there to do such a thing, so I found an extension to do just that.

The second problem was...a long slog to figure out. It's possible to have a Parallels VM be able to communicate with Docker containers running in the Mac host. However, I could not get this to work with Aspire. After doing side-by-side comparisons between container manifests running inside/outside of Aspire, I found the culprit:

"PortBindings": {
	"8080/tcp": [
		{
-			"HostIp": "",
+			"HostIp": "127.0.0.1",
			"HostPort": "8000"
		}
	]
},

With the Docker CLI, doing -p 8080:8000 does not set the host IP. Aspire does however, which means I can only access this container via localhost. Not ideal because my Windows VM is definitely not able to access that. Instead of using WithEndpoint or similar, I have to drop down to container runtime args:

.WithContainerRuntimeArgs("-p", "33333:33333")
.WaitFor(rabbitMqResource);                   

Now my Service Control instance is up and running!

Setting up Service Control Audit, Monitoring, and Service Pulse

Following our previous example, we can finish out our configuration for the other container instances:

builder                                                                              
    .AddContainer("servicecontrolaudit", "particular/servicecontrol-audit")          
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")          
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                
    .WithEnvironment("RavenDB_ConnectionString", "http://host.docker.internal:8080") 
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithArgs("--setup-and-run")                                                     
    .WithEndpoint(44444, 44444)                                                      
    .WaitFor(rabbitMqResource);                                                      
                                                                                     
builder                                                                              
    .AddContainer("servicecontrolmonitoring", "particular/servicecontrol-monitoring")
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")          
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithArgs("--setup-and-run")                                                     
    .WithEndpoint(33633, 33633)                                                      
    .WaitFor(rabbitMqResource);                                                      
                                                                                     
builder                                                                              
    .AddContainer("servicepulse", "particular/servicepulse")                         
    .WithEnvironment("SERVICECONTROL_URL", "http://host.docker.internal:33333")      
    .WithEnvironment("MONITORING_URL", "http://host.docker.internal:33633")          
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithEndpoint(9090, 9090)                                                        
    .WaitFor(rabbitMqResource);                                                      

With all this in place in my Service Pulse instance is up and running:

And on the Service Insight side, I had to do the Parallels trick of using my hosts file to create a special "localhost.mac" entry to point to the Mac host:

10.211.55.2 localhost.mac

With this in place, I can configure Service Insight in Windows to connect to the Docker Service Pulse instance running in Docker on the Mac:

All my NServiceBus messages and traces now show up just fine:

Most of the work I had to do was not really Aspire-related, but just configuring Aspire to pass in the appropriate configuration to the containers. You can find the full code to my configuration here:

Code Example

Enjoy!

• Intro
• Cataloging
• Empty Proxy
• Shared Library
• Our First Controller
• Migrating Initial Business Logic
• Our First Views
• Session State
• Hangfire
• Authentication
• Middleware
• Turning Off the Lights

In the last post, we looked at migrating our middleware, which we tackle in an as-needed basis. When a controller needs middleware to be migrated, we migrate that middleware over. If the entire app needs the middleware, it needs to come rather early.

Once we migrate much of our middleware over, it becomes much less work to incrementally migrate individual controllers and their subsequent actions/pages over. I won't go into deep detail into this part - mostly it's fixing namespaces, adjusting features (such as converting child actions into view components), but it can go quite fast. On recent teams I was working with, we migrated easily a dozen controllers a week amongst 3-4 developers. At this point, the bottleneck wasn't the conversion, but testing to make sure the pages still worked correctly

It's essentially testing the entire application, one page at a time, so hopefully you've got some regression tests in some form or fashion. I'm not skipping the incremental controller migration because it's not interesting - it's just because our teams really didn't encounter many challenges there. There will be something that comes up, there always is, but just the controller/action/view part is not too terrible.

But in this post I wanted to focus on getting to the end - what do we do once we've migrated everything but authentication? When there's just one controller left, we're now OK to proceed with migrating the last pieces over and "turning off the lights" on the .NET 4.x application.

Migrating Last Features

The last (or next-to-last) migration typically:

• Migrates the last controller, usually authentication
• Turns off proxying and all remote app features

You don't necessarily need to split this into two separate units of work/deployments, as once you've migrated the last set of requests you can migrate all final features from the .NET Framework application. If the last controller is authentication, we'll also need to remove remote authentication. Our current web adapter configuration before final migration is:

builder.Services.AddSystemWebAdapters()
    .AddJsonSessionSerializer(options =>
    {
        options.RegisterKey<string>("FavoriteInstructor");
    })
    .AddRemoteAppClient(options =>
    {
        // Provide the URL for the remote app that has enabled session querying
        options.RemoteAppUrl = new(builder.Configuration["ProxyTo"]);

        // Provide a strong API key that will be used to authenticate the request on the remote app for querying the session
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true)
    .AddSessionClient();
builder.Services.AddHttpForwarder();

With middleware:

app.UseSystemWebAdapters();

app.MapDefaultControllerRoute();
app.MapForwarder("/{**catch-all}", app.Configuration["ProxyTo"]).Add(
    static builder => ((RouteEndpointBuilder)builder).Order = int.MaxValue);

Along with migrating the authentication piece and all related middleware, we'll remove the above from our application startup, as well as the package references to all the proxy and System.WebAdapters packages. Once that's complete, our .NET application should now handle all requests. There might still be a few extra features to enable in .NET 8, such as Session:

builder.Services.AddSession();

// later

app.UseSession();

With all that complete, our .NET 8 application should now serve all requests and host all features needed to run our entire system.

Turning off the lights

While our .NET 8 application may now be "complete", we're not quite done yet. In my typical last phase we will:

• Deploy the completed .NET 8 application to production
• Monitor for any errors and any activity from the .NET 4.8 application
• Adjust our .NET 8 application as necessary

If we don't see any issues, then the final final cleanup is:

• Remove all .NET 4.8 code from the repository
• Remove any shims to bridge from .NET 8 to .NET 4.8
• Remove all .NET 4.8 application pipelines and deployments
• Remove all .NET 4.8 production resources

And we should end with something like:

So what's next? There's still probably quite a bit to do to ".NET-8-ify" our existing system - all those architectural improvements we skipped in order to fast track migration. But most important - celebrate!

A little different than the previous times I've given this course is an option for either a 2-day or 3-day version. I had received feedback that folks were also interested in larger-scale design concepts such as bounded contexts, messaging, integration patterns, microservices, and modular monoliths. So I've included a 3rd day that covers these topics, where we look at encapsulation and cohesion at larger and larger scopes.

We'll cover:

• Refactoring an existing system to leverage Vertical Slice Architecture
• Applying Domain-Driven Design techniques to model complex business needs
• Communication between slices
• Exploring Validation and Testing (and other cross-cutting concerns) using Vertical Slice Architecture
• Examining various design patterns, code smells, and refactoring techniques
• Implementing the Vertical Slice Architectural pattern in various enterprise application scenarios (minimal APIs, Blazor, Web APIs, etc.)

And on the final day:

• Service boundaries and bounded contexts
• Communication between bounded contexts
• Microservices and modular monoliths
• Studying distributed systems patterns, tools, and libraries such as NServiceBus

The course pulls together my experiences building such systems for nearly 20 years now. And if you can't make the course during the day, I'm also hosting a networking event during the evening where you can meet myself and the other attendees and ask me questions. I hope to see you there!

Register Now

• Intro
• Cataloging
• Empty Proxy
• Shared Library
• Our First Controller
• Migrating Initial Business Logic
• Our First Views
• Session State
• Hangfire
• Authentication
• Middleware
• Turning Off the Lights

In the last post, we looked at tackling probably the most important pieces of middleware - authentication. But many ASP.NET MVC 5 applications will have lots of middleware, but not all of the middleware should be migrated without some analysis on whether or not that middleware is actually needed anymore.

This part is entirely dependent on your application - you might have little to no middleware, or lots. Middleware can also exist in a number of different places:

• Web.config (you WILL forget this)
• Global.asax (probably calling into other classes with the middleware configuration)
• OWIN Startup

When choosing the first controller to migrate, I'm also looking at which controllers have the least amount of middleware, just to minimize the heavy first lift.

Let's look at our various middleware, and see what makes sense to move over, starting with our web.config.

Migrating Web.Config

I think I forget the web.config middleware mainly because I've tried to burn most things ASP.NET from my brain. But we'll find lots of important hosting configuration settings in our web.config, from custom middleware to error handling, application configuration, server configuration and more. Luckily for us, nearly all out-of-the-box configuration has a direct analog in Kestrel. We mostly need to worry about anything custom here. My sample app doesn't have a lot going on:

<system.web>                                                                                        
  <compilation debug="true" targetFramework="4.8.1" />                                              
  <httpRuntime targetFramework="4.8.1" />                                                           
  <customErrors mode="RemoteOnly" redirectMode="ResponseRewrite">                                   
    <error statusCode="404" redirect="/404Error.aspx" />                                            
  </customErrors>                                                                                   
  <!-- Glimpse: This can be commented in to add additional data to the Trace tab when using WebForms
      <trace writeToDiagnosticsTrace="true" enabled="true" pageOutput="false"/> -->                 
  <httpModules>                                                                                     
    <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" />                         
  </httpModules>                                                                                    
  <httpHandlers>                                                                                    
    <add path="glimpse.axd" verb="GET" type="Glimpse.AspNet.HttpHandler, Glimpse.AspNet" />         
  </httpHandlers>                                                                                   
</system.web>                                                                                       

We only have one set of custom modules/handlers and it's the now-dead (and much missed) Glimpse project. In the rest of the configuration, we only see custom errors redirecting to an .ASPX page, which we can easily port over using custom errors in ASP.NET Core. Otherwise there's not much going on here.

In a typical application, the things I've needed to migrate over might include such settings as:

• Authentication
• Authorization
• Cookies
• Session state
• Data protection
• Static files
• HTTP request methods
• Initialization
• Custom headers
• Caching

Each of these has some analog in ASP.NET Core Kestrel configuration. But luckily for us, we don't have any custom handlers/modules to worry about, only porting ASP.NET runtime features to ASP.NET Core.

ASP.NET MVC 5 Middleware

Next up is ASP.NET MVC 5 middleware, which is typically set up in the Global.asax.cs file, something like:

AreaRegistration.RegisterAllAreas();                      
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);            
BundleConfig.RegisterBundles(BundleTable.Bundles);        

The global filters registered are:

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{                                                                       
    filters.Add(new HandleErrorAttribute());                            
    filters.Add(new ValidatorActionFilter());                           
    filters.Add(new MvcTransactionFilter());                            
}                                                                       

The first filter here is a built-in one from ASP.NET MVC to provide global error handling (with no extra configuration), but the second two are custom. The first custom filter provides some customization around handling validation errors and providing a common error result back to the UI:

public void OnActionExecuting(ActionExecutingContext filterContext)                                   
{                                                                                                     
    if (!filterContext.Controller.ViewData.ModelState.IsValid)                                        
    {                                                                                                 
        if (filterContext.HttpContext.Request.HttpMethod == "GET")                                    
        {                                                                                             
            var result = new HttpStatusCodeResult(HttpStatusCode.BadRequest);                         
            filterContext.Result = result;                                                            
        }                                                                                             
        else                                                                                          
        {                                                                                             
            var result = new ContentResult();                                                         
            string content = JsonConvert.SerializeObject(filterContext.Controller.ViewData.ModelState,
                new JsonSerializerSettings                                                            
                {                                                                                     
                    ReferenceLoopHandling = ReferenceLoopHandling.Ignore                              
                });                                                                                   
            result.Content = content;                                                                 
            result.ContentType = "application/json";                                                  
                                                                                                      
            filterContext.HttpContext.Response.StatusCode = 400;                                      
            filterContext.Result = result;                                                            
        }                                                                                             
    }                                                                                                 
}                                                                                                     

The front end does still need this, so we want to port this over. The second filter provides automatic transaction handling:

public class MvcTransactionFilter : ActionFilterAttribute                                              
{                                                                                                      
    public override void OnActionExecuting(ActionExecutingContext filterContext)                       
    {                                                                                                  
        // Logger.Instance.Verbose("MvcTransactionFilter::OnActionExecuting");                         
        var context = StructuremapMvc.ParentScope.CurrentNestedContainer.GetInstance<SchoolContext>(); 
        context.BeginTransaction();                                                                    
    }                                                                                                  
                                                                                                       
    public override void OnActionExecuted(ActionExecutedContext filterContext)                         
    {                                                                                                  
        // Logger.Instance.Verbose("MvcTransactionFilter::OnActionExecuted");                          
        var instance = StructuremapMvc.ParentScope.CurrentNestedContainer.GetInstance<SchoolContext>();
        instance.CloseTransaction(filterContext.Exception);                                            
    }                                                                                                  
}                                                                                                      

I might not do automatic transactions like this in a normal project but because the application code expects it, we'll need to migrate this over as well. The transaction filter is interesting because it highlights the shortcomings of ASP.NET MVC 5's dependency injection capabilities - namely there wasn't anything built in for filters. Instead of migrating this filter as-is, we need to translate to the equivalent ASP.NET Core filter:

public class DbContextTransactionFilter : IAsyncActionFilter                                              
{                                                                                                         
    private readonly SchoolContext _dbContext;                                                            
                                                                                                          
    public DbContextTransactionFilter(SchoolContext dbContext)                                            
    {                                                                                                     
        _dbContext = dbContext;                                                                           
    }                                                                                                     
                                                                                                          
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {                                                                                                     
        try                                                                                               
        {                                                                                                 
            _dbContext.BeginTransaction();                                                                
                                                                                                          
            var actionExecuted = await next();                                                            
            if (actionExecuted.Exception != null && !actionExecuted.ExceptionHandled)                     
            {                                                                                             
                _dbContext.CloseTransaction(actionExecuted.Exception);                                    
                                                                                                          
            }                                                                                             
            else                                                                                          
            {                                                                                             
                _dbContext.CloseTransaction();                                                            
                                                                                                          
            }                                                                                             
        }                                                                                                 
        catch (Exception ex)                                                                              
        {                                                                                                 
            _dbContext.CloseTransaction(ex);                                                              
            throw;                                                                                        
        }                                                                                                 
    }                                                                                                     
}                                                                                                         

And we register our filter:

builder.Services.AddControllersWithViews(opt =>
{
    opt.Filters.Add<DbContextTransactionFilter>();
});

Now our filter will have its DbContext injected instead of going out to a custom extension to mimic per-request service lifetimes.

Finally, let's look at the OWIN middleware.

OWIN Middleware

OWIN middleware can be found in classes with the OwinStartup attribute configured for them. Usually this is a "Startup" class but it could be anything. In my sample app, we have:

[assembly: OwinStartup(typeof(Startup))]
namespace ContosoUniversity
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();

            GlobalConfiguration.Configuration
                .UseSqlServerStorage("SchoolContext")
                .UseStructureMapActivator(IoC.Container)
                ;


            app.UseHangfireDashboard();
            app.UseHangfireServer(new BackgroundJobServerOptions
            {
                Queues = new[] { Queues.Default }
            });

            ConfigureAuth(app);
        }
    }
}

Basically, it's:

• SignalR
• Hangfire
• Authentication

Authentication might differ slightly than the ASP.NET authentication, so we'll want to port settings there. SignalR and Hangfire can be dealt with individually, but otherwise we don't have any custom OWIN middleware. This is fairly typical unless your application wholly relies on OWIN instead of say, IIS.

Middleware isn't the most exciting code to port over, but critical for ensuring our new application preserves the existing behavior of the .NET Framework application.

In our last post, we'll cover finishing up our migration and "turning off the lights".

This course approaches this topic from the perspective of refactoring an existing system to this architecture. We also look at larger and larger boundaries of cohesion, from applications to services to systems. I'm also doing something new, a Q&A at a pub where you can ask questions while we share authentic Dutch beer (Heineken).

More details here:

Vertical Slice Architecture Training

Hope to see you there!