AutoMapper 4.2.0 released

Yesterday I bit the bullet and pushed out the 4.2.0 release. This was a fairly large internal refactoring, with the entire static API marked as obsolete and a new instance-based API exposed. Some helpful links for the move:

Some interesting things in this release that you might have missed:

It’s been a long journey with this static API, but its time is near the close. In the 5.0 release, the entire static API will be removed, making me quite happy.


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.
  • Adam Kirkton

    I am really excited about the removal of the static interface. I had been doing some hackiness for a while now so I could easily inject IMappingEngine in a Web API project and not have to set the ConstructUsing option when calling Map to get my request instanced container. Thanks Jimmy!

  • Mel Grubb

    If your internal code name for this release wasn’t “stoner”, I’m sorely disappointed.

    • jbogard


  • Peter Morlion

    Am I correct this release no longer works on .NET 4.0, whereas 4.1.x still does?

  • wally

    How would you recommend adding profiles with dependencies with this new API?

    • wally

      I was able to modify your sample code to work:

    • jbogard

      Profiles with dependencies? Eh? Profiles shouldn’t have dependencies, it’s just static config.

      • wally

        I chose to inject lookup services and configuration file instances for string formatting and thought profiles were the best place since that’s where the mapping was actually taking place.

  • Dzmitry.Lahoda

    Hi, I see performance stuff about automapper and Where any changes in last release? It is considered to split automapper for fast and slow parts? Is it possible to have 2 builds – one is client side based on method calls and server side relying on il emit for performance (may be using for correctness). Is it possible to provide single hard coded delegate during mapping registration? So it will be part of other mapping, but as called on own being of maximal performance?

  • Stéphane

    Let’s imagine,I use automapper to map my entity to some DTO, and I’ve got a LINQ query on my DTO on the presentation layer that I want to map back to entity so that I can I execute the query on the db.

    Now, I know that automapper can create linq expression to handle the SELECT part of the query and have all the projection happening directly in SQL, but I would like also have ORDER & WHERE translated the same way, even if the case where the mapping from entity to dto use complex aggregation logic (ex. total with a group by) as long as that logic can be expressed as SQL.

    Can automapper Unproject queries this way ?

    • Stéphane

      Why i want to do that ? Because, now we got javascript grid (kendo for example) that can be bound to any ODATA webapi backend, and have all the user interaction like paging, filtering or sorting be translated as ODATA queries sot that can be handled server side, in SQL, for good performance on large dataset.

      However, some people argue that this architecture violate encapsulation, as your odata backend becomes likes exposing a linq provider to your db (basically your data layer) to the world. That’s why, I do not want to expose my entities directlty in my odata backend,

      • Stéphane

        but want to use dto instead, and have maybe queries on several entity with agregation (things like count, sum) happening. However, as my client to not know about my data model (encapulation) it will create linq query on the dto, that i would like to translate to equivalent query on the entity.

        I do not know if automapper can do such translation ? If it does not, I’ve considered started some open source project to do it…

        • jbogard

          Maaaaaaybe open a GH request for this?

  • dismuter

    I had not followed the evolution of AutoMapper closely so this comes as a surprise.
    I myself always avoided the static calls, so I can only applaud this very wise decision.
    Indeed, the lifetime of an object should be the application’s responsibility, not the library’s.

  • Arnaud

    Gorgeous thing to delete static, just had somes questions
    Why CreateMapper method does not exist in configuration interface ?
    -How do you register subclass map in profile ?
    .ForMember(album => album.Pictures, expression => expression.ResolveUsing(src => Mapper.Map<IList>(src.Pictures))); is using Static Mapper.Map