You’ve probably heard by now, AutoMapper has gone commercial.

If you’re starting a new project or can easily move away from AutoMapper, you’re in a much better position.

However, if your solutions relies heavily on it, this shift might put you in a tough spot. Replacing AutoMapper isn’t always straightforward, it can take considerable time and effort.

Your options?

• Stick with the older version and miss out on updates
• Pay for a license (thankfully, the pricing seems reasonable)
• Start migrating away

In this post, we’ll briefly revisit AutoMapper and explore some viable alternatives for those considering a switch.

Mapster

Mapster is my go to mapping library for the last few years.

To get started with Mapster, you need to install the NuGet package. You can do this via the NuGet Package Manager or by running the following command in the Package Manager Console:

Install-Package Mapster

One of the great things about Mapster is that you can start using it without any configuration. It offers a static extension method called Adapt, which is available on any object:

var product = _productDto.Adapt<Product>();

It automatically maps properties with matching names from the source to the destination object.

For more control over the mapping process, you can define custom configurations by implementing the IRegister interface:

public class BookProfile : IRegister
{
    public void Register(TypeAdapterConfig config)
    {
        config
            .NewConfig<Book, BookDto>()
            .TwoWays()
            .Map(dest => dest.Author, src => src.Author.Name);
    }
}

This allows you to customize property mappings and enable two-way conversion if needed.

To register Mapster in your dependency injection container:

services.AddMapster();

This enables you to inject IMapper interface into your services, which is especially useful if you're migrating from AutoMapper, minimazing changes in your codebase.

Additionally, you don't even need to write DTO classes manually. Mapster provides Mapster.Tool to help you generate models. And if you would like to have explicit mapping, Mapster also generates mapper classes for you.

It performs well, while not the best in terms of performance it's faster than AutoMapper and easy to use. If your use case involves mostly simple mappings, its automatic mapping without profiles is big advantage.

Mapperly

Another alternative I find relevant is Mapperly.

Mapperly is a modern .NET source generator designed to create efficient object mappings at compile time.

Because Mapperly generates mapping code during the build process, it incurs almost no runtime overhead, and any mapping errors are caught early as compile-time errors making code more reliable.

To get started with Mapperly, you need to install the NuGet package. You can do this via the NuGet Package Manager or by running the following command in the Package Manager Console:

Install-Package Riok.Mapperly

Mapperly requires minimal configuration. You define your mappings by creating a partial class annotated with [Mapper] and declare the mapping methods you need:

[Mapper]
public partial class MapperlyConfiguration
{
    public partial Product Map(ProductDto dto);
    public partial ProductDto Map(Product source);
}

var product = _mapperlyMapper.Map(_productDto);

Mapperly is currently one of the fastest and most efficient mappers available for .NET. It combines excellent performance with minimal setup, making it an excellent choice.

Rise and Fall of AutoMapper

AutoMapper has long been a cornerstone of .NET development. For years, it was the go-to solution for object-to-object mapping.

However, in recent times, strong alternatives have emerged and they’re becoming increasingly competitive.

What many developers may not realize is that AutoMapper was one of the earliest widely adopted libraries in the .NET ecosystem. Its first commit dates all the way back to January 2009.

It dominated the space for years and for many developers (myself included) became an essential part of every application.

In my opinion, it was ahead of its time for years, packed with features, many of which were missused.

With the rise of source generators and a growing focus on raw performance and transparency, the landscape has started to shift.

While performance differences might not be noticeable in most real-world applications, libraries like Mapster and Mapperly have begun to outperform AutoMapper in benchmarks.

At the same time, there's a growing trend toward manual mapping as a cleaner and more explicit alternative.

Many contributors have since distanced themselves from the project. Some have even begun mocking Jimmy Bogard’s libraries, once beloved pillars of the .NET world.

That said, Jimmy’s decision to turn AutoMapper and MediatR into commercial products gives me hope that the projects will continue to live on and evolve as they once did.

Whether they rise again remains to be seen, but their legacy in .NET development is already written.

Conclusion

.NET offers several other alternatives as well, such as TinyMapper and others.

However, many of these other mappers are either poorly maintained, significantly slower or require more configuration than I prefer.

While I do use manual mapping in some of my projects, for the most part I favor Mapster because it handles simple mappings automatically with its Adapt method.

You can check the benchmarks by downloading the source code and even add more alternatives to test and choose your favorite. You can find the source code here:

I hope you enjoyed it, subscribe and get a notification when new blog is up!