Mapping output affected by the order of base class maps in a profile

[danielgreen]

The order that maps are set up in a profile seems to affect the output of mapping operations.

Full repro in this minimal .NET 6 console app:
https://github.com/danielgreen/AutoMapperScratchApp

Source/destination types

// Source type and interface
public interface IFoo { public string? FooText { get; set; } }
public class Foo : IFoo { public string? FooText { get; set; } }

// Destination type and base class
public abstract class Bar { public string? FooText { get; set; } }
public class Boo : Bar { }

Mapping configuration

public class ProfileA : Profile
{
    public ProfileA()
    {
        this.CreateMap<object, IFoo>()
            .ForMember(d => d.FooText, o => o.Ignore())
            .IncludeAllDerived();

        this.CreateMap<Bar, IFoo>()
            .ForMember(d => d.FooText, o => o.MapFrom(s => s.FooText))
            .IncludeAllDerived();

        this.CreateMap<Boo, Foo>();
    }
}

public class ProfileB : Profile
{
    public ProfileB()
    {
        this.CreateMap<Bar, IFoo>()
            .ForMember(d => d.FooText, o => o.MapFrom(s => s.FooText))
            .IncludeAllDerived();

        this.CreateMap<object, IFoo>()
            .ForMember(d => d.FooText, o => o.Ignore())
            .IncludeAllDerived();

        this.CreateMap<Boo, Foo>();
    }
}

Version: 12.0.0

Expected behavior

Expected the behaviour of both profiles would be the same.
Thought that FooText would be mapped in both cases, because the <Bar, IFoo> map (which maps the property) is more derived than the <object, IFoo> map (which ignores the property).

That was based on my reading of these docs:
https://docs.automapper.org/en/stable/Mapping-inheritance.html

Actual behavior

The FooText property value is not mapped when using ProfileA, but the value is mapped when using ProfileB.
The only difference between ProfileA and ProfileB is the <Bar, IFoo> and <object, IFoo> maps appear in a different order.

Is it expected behaviour that the order that maps appear in a profile would determine the output?
If it is expected, is that documented (sorry if I missed it), or how should developers work with that?
If it is not expected, which profile is producing the correct output here?

Steps to reproduce

Console.WriteLine("AutoMapper scratch app");

TestProfileA();
TestProfileB();

Console.WriteLine("done");

void TestProfileA()
{
    var config = new MapperConfiguration(c => c.AddProfile<ProfileA>());
    config.AssertConfigurationIsValid();

    var mapper = config.CreateMapper();
    var boo = new Boo { FooText = "Hi" };
    var foo = mapper.Map<Foo>(boo);

    Console.WriteLine("Testing ProfileA - what is the value of Foo.FooText?");
    Console.WriteLine(foo.FooText ?? "(null)");
    Console.WriteLine();
}

void TestProfileB()
{
    var config = new MapperConfiguration(c => c.AddProfile<ProfileB>());
    config.AssertConfigurationIsValid();

    var mapper = config.CreateMapper();
    var boo = new Boo { FooText = "Hi" };
    var foo = mapper.Map<Foo>(boo);

    Console.WriteLine("Testing ProfileB - what is the value of Foo.FooText?");
    Console.WriteLine(foo.FooText ?? "(null)");
    Console.WriteLine();
}

[lbargaoanu]

Just by looking at your maps, I cannot say what the result should be :)
So just don't write this code. What happens if you simply use Include when you need it, without IncludeAllDerived?
Either way, you're welcome to look deeper into it and come up with a proposal.
But my point is that someone is supposed to look at your mappings and have a good idea what they mean. That seems very unlikely here.

[lbargaoanu]

Some did fail and I fixed them. We want to say that the new behaviour is that an ignore override is inherited. So, in your case, as you can see in the test, you only need to include the most derived map and you inherit both the config in the base class and the ignore override in the derived class.

[danielgreen]

The fix doesn't change the outcome when using the IncludeAllDerived approach that I started with - I assume that was not your intention anyway - I'm stepping through the source to try to understand why the execution plan is different when using IncludeAllDerived depending on the order of the maps in the profile...

[danielgreen]

Would you mind having a look at this commit on my fork please?
danielgreen@be66ea7

It's an attempt to sort the inherited TypeMaps before applying them, by looking at which inherited TypeMap is closest to the current TypeMap in the hierarchy.

Since each TypeMap obviously has source and destination types with their own hierarchies, the TypeMapComparer works out the total number of hops from the current TypeMap's source & destination types to the inherited TypeMap source & destination types.
Those with the least hops are applied first, which means that the order the maps appear in the profile no longer has an effect when using IncludeAllDerived.

A caveat is where the TypeMaps use an interface as source or destination type. Since an interface does not appear in a type's hierarchy, TypeMapComparer treats them as having an arbitrary high number of hops in order to push them to the end of the sorted list. In other words, inherited maps that work on concrete classes will be applied before those that work on interfaces. For the purely interface-based maps, the order they appear in the profile will still matter.

The tests I've added (and all the other existing tests) pass.

[lbargaoanu]

I'm sorry, but that's exactly the kind of code I, for one, don't want to see in AM anymore. Complex and slow. And what exactly is the benefit here? To allow you to call IncludeAllDerived, which on every call would go through all your maps, looking for derived maps.
I'd rather you implement smth like IncludeAllDerived in your own code somehow. Stuff is usually public so I think you can do it, but if smth is missing, we can expose it.

[danielgreen]

There would be a performance hit due to the extra sorting code so understandable if it's not worth it.

IncludeAllDerived already goes through all the maps doesn't it(?) to add the base maps into the internal inherited maps list maintained by all the derived maps, so there is no change there.

It's later on, when the inherited maps are about to be applied, that the sorting code runs. But yeah there's still a cost to running the sort.