Exception Due To Replacing ForAllOtherMembers With MemberList.None

[jwbats]

Source/destination types

Source (Short Version)

public class PaymentIntent : StripeEntity<PaymentIntent>, IHasId, IHasMetadata, IHasObject
{
    [JsonProperty("id")]
    public string Id { get; set; }
}

Destination (Short Version)

[Table("PaymentIntentLog")]
public class PaymentIntentLog : IEntity
{
	public int ID { get; set; } = 0;
	public string PaymentIntentID { get; set; } = null;
}

Mapping configuration

cfg.CreateMap<PaymentIntent, PaymentIntentLog>(MemberList.None)
	.ForMember(dest => dest.PaymentIntentID,
		opt => opt.MapFrom(src => src.Id)
	);

Version: 11.0.1

Coming from 10.1.1.

Expected behavior

Upgrading from 10 to 11 and replacing '.ForAllOtherMembers(opt => opt.Ignore())' with 'MemberList.None', I expected everything to work as it always has.

Actual behavior

Instead, the above configuration throws an exception, saying that the "input string was not in a correct format" for destination property 'ID'.

The string property 'Id' from the source object must be mapped to the string property 'PaymentIntentID' property on the destination object.

Why is it even attempting to do anything for destination property 'ID', when it shouldn't, due to MemberList.None?

I am forced to explicitly tell it to not do anything with the destination object's 'ID' property, in order to get it back to working again:

.ForMember(dest => dest.ID,
		opt => opt.Ignore()
	);

Looks like it's trying to match the destination's uppercase 'ID' int property to the source's camelcase 'Id' string property, even though the latter is already explicitly being mapped to the destination's 'PaymentIntentID' string property.

Parsing an int fails, because Stripe's Payment Intent 'Id' string property gets a value of the form:

pi_3LU8CHANe7YaWXoA4EHsnlVi

Could it be that AutoMapper 10 was case sensitive and AutoMapper 11 isn't?

This unexpected behavior makes me feel like it could unexpectedly go wrong with other mappings, as well. Feels a bit risky updating to version 11.

Exception

AutoMapper.AutoMapperMappingException: Error mapping types. Mapping types: PaymentIntent -> PaymentIntentLog Stripe.PaymentIntent -> ContentBase.Model.PaymentIntentLog Type Map configuration: PaymentIntent -> PaymentIntentLog Stripe.PaymentIntent -> ContentBase.Model.PaymentIntentLog Destination Member: ID ---> System.FormatException: Input string was not in a correct format. at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, TypeCode type) at System.Int32.Parse(String s) at lambda_method2649(Closure , PaymentIntent , PaymentIntentLog , ResolutionContext ) ...

Steps to reproduce

PaymentIntentLog paymentIntentLog = this.mapper.Map(paymentIntent, paymentIntentLog);

[jbogard]

.ForAllOtherMembers(opt => opt.Ignore()) is not equivalent to MemberList.None exactly. It does not cover the case where members actually map.

I'm not sure I'd use AutoMapper for this case, I have yet to see a case for the above where manual code wasn't more obvious. If you have to ignore every mapping except for what is explicitly mapped, you don't have AutoMapper you have ManualMapper. That method was removed because it was so confusing about what the expected behavior should be. I regret ever adding it in the first place.

[jwbats]

The documentation itself suggests MemberList.None instead of ForAllOtherMembers. So that's the best I got.

In my view, this is exactly the kind of stuff you'd use AutoMapper for. Keep in mind, these entities are shortened versions, that I edited for brevity. There are many other properties in these entities. I only want to map a select set of my choosing, explicitly, to whichever properties I want.

I dislike the idea of having to explicitly list every member I want to ignore. At some point, you'll add more properties to your entities, and you forget to add them to your AutoMapping's growing list. Now you've got exceptions from AutoMappings that used to work.

I think we have a real use case here for ForAllOtherMembers. Can we have it back, please?

[jbogard]

No because what you're describing is ExplicitMapper. Only map the properties that are explicitly mapped. AutoMapper was never intended for that use case. What is more obvious and explicit is to just manually write the code:

CreateMap<Source, Dest>()
    .ForMember(d => d.Property1, opt => opt.MapFrom(src => src.PropertyA))
    .ForMember(d => d.Property2, opt => opt.MapFrom(src => src.PropertyB))
    .ForMember(d => d.Property3, opt => opt.MapFrom(src => src.PropertyC))
    .ForMember(d => d.Property4, opt => opt.MapFrom(src => src.PropertyD))
    .ForMember(d => d.Property5, opt => opt.MapFrom(src => src.PropertyE))
    .ForAllOtherMembers(opt => opt.Ignore());

// then, sometime later

var dest = _mapper.Map<Dest>(src);

vs

var dest = new Dest {
    PropertyA = src.Property1,
    PropertyB = src.Property2,
    PropertyC = src.Property3,
    PropertyD = src.Property4,
    PropertyE = src.Property5
};

In the second case, we simply perform an explicit map. If you STILL MUST USE AutoMapper because reasons, then use ConvertUsing:

CreateMap<Source, Dest>()
    .ConvertUsing(src => new Dest {
        PropertyA = src.Property1,
        PropertyB = src.Property2,
        PropertyC = src.Property3,
        PropertyD = src.Property4,
        PropertyE = src.Property5
   });

That will let you map only the properties you explicitly want to and skips anything you don't.

[jwbats]

I should've posted my other replies as actual replies under a single answer thread. And I consider the ConvertUsing() suggestion to be the answer. Don't see a way to mark it, though.

[jwbats]

What's wrong with Manual/Explicit Mapper functionality in a lib called AutoMapper?

If AutoMapper was never intended for that purpose, then why did it include ForAllOtherMembers() up to version 11?

Why would it matter if your example 1 is more verbose than example 2, when example 1 is stuffed into an AutoMappings file?

You're supposed to be able to map one object to another with this. It says so right on the frontpage:

Takes out all of the fuss of mapping one object to another.

For me, it just put some fuss back in.

But thanks for the ConvertUsing() suggestion. Guess I'll refactor to that. Added benefit: I move towards less verbosity.

[jwbats]

What's AutoMapper intended for, actually?

Mapping an object to another object with equal properties?

So why not just call it Cloner, then?

Why even allow for mappings between 2 different objects?

[jbogard]

https://jimmybogard.com/automappers-design-philosophy/

That is what AutoMapper is intended to be used for and why I built it. It is not intended for types that are highly dissimilar. That creates code that is more confusing than say, just writing the code manually.

Cloning is for objects of the same type. AutoMapper is also not a cloning library. It does not support common cloning use cases and does not perform object creation like actual cloning libraries do.

The "Auto" part refers to automatically lining properties up and setting them by a simple convention (taking a complex structure and flattening it). That's it.