AutoMapper 5.1 released

Release notes here: AutoMapper 5.1

Some big things from this release:

  • Supporting portable class libraries (again), profile 111. Because converting projects from PCL to netstandard is hard
  • More performance improvements (mainly in complex mappings), 70% faster in our benchmarks
  • Easy initialization via assembly scanning

As part of the release, we closed 57 issues. With the new underlying mapping engine, there were a few bugs to work out, which this release worked to close.


About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in AutoMapper. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Paulo

    Hey, Thanks for the great work!

    I am migrating 4->5.1 and I have on global.asax an Init that configure all my mapping (I have a static InitAutoMapper method in each controller), like that:

    var assemblies = Assembly.GetExecutingAssembly().GetTypes().ToList();

    foreach (var controller in assemblies)
    var methodInfo = controller.GetMethod(“InitAutoMapper”);
    if (methodInfo != null) {
    methodInfo.Invoke(controller, new object[] { });
    Is that a good approach to use on 5.1? What you think?

    • jbogard

      What do your InitAutoMapper methods look like? Remember you’re only supposed to call Mapper.Initialize once per AppDomain.

      • Paulo

        Like that:

        public static void InitAutoMapper()
        Mapper.CreateMap ();


        All my controllers have that and there are about 400 controllers, so Im looking for an “easy” way to migrate…

        So I cant use that approach, any workaround?

        • jbogard

          Well, profiles are the way to have configuration separated out. You might be able to do some regular expression magic (I’ve done this myself) to replace all those calls to with a Profile class inside each controller. Then you just need to call Mapper.Initialize(cfg => cfg.AddProfiles(typeof(SomeController)));

          Better than copy-paste 400 times, but it might take you 15-30 minutes to get the “right” regex. But Visual Studio can help you out here.

  • TheEdge

    Hi Jimmy,

    Appreciate you making AM available. I am interested in using the scanning functionality that is part of 5.1 and in particular this pattern:

    // Marker types for assemblies
    Mapper.Initialize(cfg =>
    cfg.AddProfiles(new [] {

    A couple of questions:

    1) If MyType exists in AssemblyA will that assembly be scanned in its entirety for for any classes descending from AutoMapper.Profile?
    2) Do those profile classes have to be declared public?

    • jbogard

      Yes, and I don’t know, try it?

  • RogerB

    Hi Jimmy,

    I’m very interested in using AutoMapper, however there’s lots of stuff on the Internet on it not being very performant when used in combination with an ORM framework like Entity Framework unless you take some additional action. Would you say this is still the case in this last version?

    Thanx for the great work so far!!!


    • jbogard

      Nope, we don’t have problems with it. Really never had, either. People do bad/wrong stuff and say it’s bad performance. You still have to watch out for Select N+1, that is always a problem if you use AutoMapper or not. This latest though makes it more possible to use in-memory mapping, but I still try to use ProjectTo when possible.

  • RogerB

    I’m having a testdrive right now, looking very good so far. Thanks again for this!

  • Ninos Denkha

    Hi Jimmy,

    I’ve posted my issue on SOF,

    I’d appreciate your input as I can’t find what I’m missing with AutoMapper. I’ve used it in the past without issues, but not on this new project I have.