You are currently viewing Configure AutoMapper For ASP .NET Core API App
.NET Core Web API and AutoMapper

Configure AutoMapper For ASP .NET Core API App

AutoMapper is one of the widely used package. Especially when new project is setting up, this is generally used to speed up the development. Let’s see how to configure AutoMapper for .NET Core Web API project.

How does it work ?

When an application is being developed and it has multiple layers. Every layer of application might have its own contracts, its own interfaces and its own data objects. Generally when two different layers of application interact, we need to write code to map one layer’s object into other layer’s object.

For example, sometimes, data from database tables gets mapped to C# POCO objects and vice-a-versa. Sometimes, the server side code calls more than one API to aggregate the output from multiple APIs. In such cases, the code to assign values from one object to other object might be time consuming and boring. There AutoMapper comes handy.

AutoMapper is helpful to reduce the boring mapping code. AutoMapper is object to object mapper. It enables object mapping via some configurations and conventions. AutoMapper when used to map two objects, it gets property from source object, then it finds property with same name in the destination object and assigns the value (as long as source and destination types are same or support conversion). In addition to this, AutoMapper also supports flattening.

You can read more about it in its documentation. Let’s get back to our main objective of this post.

Demo Setup

Create a new .NET Core web API project using .NET CLI or Visual Studio.

Then add below mentioned nuget package to this project

This package has extensions required for registering AutoMapper with .NET Core applications. Actually, the Nuget package, AutoMapper, brings all AutoMapper implementation. But the dependency injection package allows its setup via .NET Core host and dependency injection.


Now, let’s go through the demo step by step.

Demo Objects

This step is required only for demo. In real world applications, you might already have classes defined and that’s why you are probably looking for AutoMapper.

Let’s create two classes, Source and Destination, with same properties. We will populate Source object somehow (by hardcoding in this sample) and then use AutoMapper to map destination properties.

Mapping Profile

AutoMapper profile is the class which holds all object mapping configurations together at one place. We just need to create a new class, which is derived from Profile class. Ideally, if application has multiple layers, I personally would prefer creating profiles in every layer which maps that layer’s objects to the objects from the layer which is abstracted by that layer.

For example, business layer might have a profile which maps data objects from business objects to data layer objects. Web API layer might have mappings to map objects from web API layer to business layer.

For this demo, we assume that the source and destination objects have same properties with same data types. So setting up profile is easy. We are using CreateMap and ReverseMap APIs provided by AutoMapper to map the objects.

Add AutoMapper

This is something that needs to be configured in Startup.ConfigureServices as shown below. This API – AddAutoMapper – adds all dependencies and resolvers required for mapping objects. It loads the profiles from the specified assembly. The parameter that is passed in below snippet is a type Startup. Based on this, it loads the required assemblies from where profiles should be loaded.

Inject IMapper

IMapper type can be injected in any class where mapping of objects is required to be done. For this demo, let’s inject this in the API controller and then add one HTTP GET action GetDestination as shown in below code.

Although below code hardcodes property values for Source object, it is just to simplify the demo. In real world apps, the Source object might get populated from some internal/external APIs or from some other layer in application.

Run and Verify

Now, the setup is done and let’s see if it works.

After running the application we should be able to call the API via swagger. The result would show which values were assigned to the destination object by AutoMapper.

So, we have successfully configured AutoMapper. There can be complex configurations required for some object mappings. Those configurations can be specified in profiles, but rest of the code would still be same as the code in this demo.

I hope you find this information useful. Let me know your thoughts.

Leave a Reply

This Post Has 2 Comments

  1. shriramkardile

    Hello Manoj,
    Thanks for the info on Auto Mapper.

    One query over this – as source and destination objects would be mapped based on property names, it seems that reflection would be used for this. So due to reflection, is this AutoMapper is slower than normal manual mapping for large objects?

    1. Manoj Choudhari
      Manoj Choudhari

      Yep internally it uses reflection. The slowness generally does not surface in smaller projects/objects. But as the project size grows, business logic might play with increasing number of business entities, causing some slowness in applications.

      I would say, use AutoMapper to speed up new developments, but then plan to replace its usage step by step if performance issues start surfacing in the application. This plan may include writing some automated tools to generate mapping code OR it may be as simple as writing that code manually. Hope this helps.