AutoMapper 4.2.1 released – Static is back (limited) edition

After a bit of feedback and soul searching and honestly tired of dealing with questions, some of the static API is restored in this release. You can now (and in the future) use Mapper.Initialize and Mapper.Map:

https://github.com/AutoMapper/AutoMapper/releases/tag/v4.2.1

The big pain from the static API was that the configuration could be changed at any time, and I couldn’t enforce a clear configuration step. Thinking about it, there was really nothing wrong with having a static API but just forcing you to initialize before mapping. That’s what will be allowed going forward – the instance API is now completely flushed out, and the static API is truly a thin veneer on top of it, where you call a static Initialize method instead of a constructor.

This release removes some of the obsolete attributes and restores the LINQ projections that use the static configuration.

Enjoy!

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.
  • Oh, dear. Are you saying I’ve wasted an hour converting one of my projects from static to instance API?

    • jbogard

      Only if you were using Mapper.Initialize. If you were using Mapper.CreateMap, then yeah you needed to change.

  • IMHO, this change – removing static APIs – should have been kept for 5.0. I see lots of people struggling with the changes. But, hey, done is done! :-)

    • jbogard

      The static APIs weren’t removed. Just marked obsolete. This release removes a few obsolete attributes.

  • Very pragmatic choice.

  • Yay! :)

  • drydenmaker

    That sounds great. My first impression that it sounded like Singletons were the issue and not necessarily static methods, and it sounds like you have all that figured out. I am one of the users of AutoMapper that would like to see less configuration, but I understand the Singleton configuration sounds like it will work out nicely to keep the API from breaking.

    • jbogard

      It was Mapper.CreateMap, that was the biggest issue really. I couldn’t count on someone jacking up the configuration at runtime.

  • Senthil

    Just wanted to check if I can get an answer to one of the question I had. I want a singleton instance of MapperConfiguration and a instance per request for Mapper and want to be able to use repository per instance within auto mapper profiles. Would this be possible with the new approach. We struggled to implement this with the static mapper, is it going to be any easier with the new approach?

    • jbogard

      Yeah you’ll be able to instantiate a Mapper class directly, passing in the config object exposed through the static Mapper class.

      • Senthil

        I think I might have not asked my question clearly enough. Here’s what I want to do. I want the MapperConfiguration registered into a dependency container as Singleton and want mapper class to be registered as per request in the dependency container and want it injected in controllers. I also want to inject repositories in the profiles which has be injected per request. I will add the profiles as per request in the container. Would this setup work? All I want to achieve is to contain all the transformation logic within profile itself.

        • jbogard

          You actually don’t want to inject anything into an AutoMapper profile. Instead, use value resolvers and type converters, and when creating a Mapper instance you can pass it the factory method to build out your resolvers, which have injected repositories.

          There are many ways to pass runtime dependencies and values into AutoMapper, but keeping state in a Profile is not one of them.

          • Senthil

            Thanks for your reply. I will give the approach you have outlined a try.

  • Chris Moseley

    Jimmy, It’d be really good if you could post a full example of how you’d like newcommers to use AutoMapper, in a full N-tier architecture, with DI. There’s a lot of old articles out there on how to do it with the old static implementation. It’s difficult for me to figure out what I should be injecting and how my configuration across DDD layers should be done. I’d like to do things the right way if possible, the way the author intends the software to be used.

  • Rafael

    This method is obsolete -> Mapper.GetAllTypeMaps()
    What can i use instead ?
    Thanks

    • jbogard

      Mapper.Configuration.GetAllTypeMaps() ?

  • Lisa-Marie Thompson

    I wonder how to use Automapper now when we make subprojects into nuget packages and from the main project need to initialize automapper in the subprojects. It seems that if doing Mapper.Initialize more than once.. the mapping gets overwritten.

    We are using StructureMap… and passing inn containers to build the containers in each project. But so far, unsure about how to archieve the same with Automapper.
    Tried to follow this example: https://github.com/AutoMapper/AutoMapper/wiki/Migrating-from-static-API

    Problem is finding a way to add profiles in the subprojects… as I don’t have the same Mapper instance inside the Registry. and so far not found a way to get that instance inside a registry.

  • Gianpiero

    Let’s suppose I have a mapper initialized somewhere in this way:

    Mapper.Initialize(cfg => {
    cfg.CreateMap();
    cfg.AddProfile();
    });

    Is it possible to add new maps to it or to reinitialize it by adding new maps?
    For example:

    Mapper.Initialize(cfg => {
    cfg.CreateMap();
    cfg.AddProfile();
    // here I get the old maps and/or profiles
    cfg.CreateMaps(Mapper.GetOriginalMaps()); ???
    cfg.AddProfiles(Mapper.GetOriginalProfiles()); ???
    });

    Obviously I have not direct access to the original FooProfile and maps.

    Last question. Another attempt I did without success is by using TypeMap:

    var typeMap = Mapper.Instance.ConfigurationProvider.FindTypeMapFor();
    if (typeMap != null) {
    // modify/extend it
    typeMap.ForMember(src => …); ???

    } else {
    // Add it to the current Mapper
    Mapper.Instance CreateMap().ForMember(..) ???
    }