I just shipped a new version of Heroic.AutoMapper.
Unfortunately, AutoMapper 4.2.0 introduces some breaking changes between 4.1.0 (semvar, anyone?), and Heroic.AutoMapper was impacted. That means anything that uses Heroic.AutoMapper is also impacted.
[more]
Fortunately, the change is mechanical, and a NuGet package update followed by some find-and-replace should have you back up and running.
First, update to Heroic.AutoMapper 2.0.0.
Next, do a find-and-replace, replacing “CreateMappings(IConfiguration” with “CreateMappings(IMapperConfiguration”. Any type that implements IHaveCustomMappings should have changed from this:
public void CreateMappings(IConfiguration configuration) { configuration.CreateMap<Foo, FooViewModel>() .ForMember(x => x.Name, opt => opt.MapFrom(x => x.FullName)); }
To this:
public void CreateMappings(IMapperConfiguration configuration) { configuration.CreateMap<Foo, FooViewModel>() .ForMember(x => x.Name, opt => opt.MapFrom(x => x.FullName)); }
Going forward, AutoMapper 5.0 is going to be a big change. I’m still not sure how I feel about it. On the one hand, I totally agree that having a non-static version of Mapper could be useful, and it will probably clean up a lot of things internally. But, in every application I’ve ever created, I’ve only ever needed a single Mapper. I can’t think of a single time I’ve needed a second one. So, this change is going to add quite a bit of noise to my apps with no real benefit to me. I’ll have to inject my IMapper now, plus I’ll have to pass the configuration around each time I want to use ProjectTo<T> (which is all the time). Not good.
Because of that, I do plan to ship a new version of Heroic.AutoMapper that provides a static Mapper when AutoMapper 5.0 is released. I don’t know exactly what it’ll look like yet, but it may very well expose the same API as the old static Mapper (just backed by a static instance of IMapper now). The goal is to minimize changes to my existing apps while also keeping things clean and simple.