Hand-rolled mapping code, though tedious, has the advantage of being testable. One of the inspirations behind AutoMapper was to eliminate not just the custom mapping code, but eliminate the need for manual testing. Because the mapping from source to destination is convention-based, you will still need to test your configuration.

AutoMapper provides configuration testing in the form of the AssertConfigurationIsValid method. Suppose we have slightly misconfigured our source and destination types:

public class Source
	public int SomeValue { get; set; }

public class Destination
	public int SomeValuefff { get; set; }

In the Destination type, we probably fat-fingered the destination property. Other typical issues are source member renames. To test our configuration, we simply create a unit test that sets up the configuration and executes the AssertConfigurationIsValid method:

Mapper.CreateMap<Source, Destination>();


Executing this code produces an AutoMapperConfigurationException, with a descriptive message. AutoMapper checks to make sure that every single Destination type member has a corresponding type member on the source type.

Overriding configuration errors

To fix a configuration error (besides renaming the source/destination members), you have three choices for providing an alternate configuration: With the third option, we have a member on the destination type that we will fill with alternative means, and not through the Map operation.

Mapper.CreateMap<Source, Destination>()
	.ForMember(dest => dest.SomeValuefff, opt => opt.Ignore());

Last edited Feb 23, 2009 at 2:37 AM by jbogard, version 1


kpetersen Jun 22, 2011 at 4:39 PM 
If you're stuck using VB like me, this is the syntax for Ignore() :
Mapper.CreateMap(Of Source, Destination)()
.ForMember(Function(dest) dest.SomeValue, Sub(opt) opt.Ignore())
Note the Sub instead of Function.

ntziolis Feb 24, 2011 at 9:46 AM 
I second that, it needs to be much clearer that a full mapping is not required when AssertConfigurationIsValid is not called. Maybe make make the assert configuration required, but add an IgnoreAllNotMapped methods to the MappingExpression, because usually you end up mapping 2 properties and adding ignore statements for all the others in order to be able to validate the configuration.

bartelink Nov 30, 2010 at 12:56 PM 
Can it be made clearer that none of this stuff is verified at runtime, and the positives and negatives of that (i.e., it took me a while to suss that if I'm doing obfuscation, I'd better have an AssertConfigurationIsValid happen on the final binaries too). If people think this is worth making an Issue of, let me know, thanks.