Nullable extension method resolver

[iamzhaoxu]

https://gist.github.com/iamzhaoxu/533a047bec2a469e32b5c786b7d1fd3d

Source/destination types

    public enum YesNoType { Y,N }
    public class Source { 
       public class Inner {
         public bool? IsFlag {get;set;}
       }
    }
    public class Desitination{ 
        public YesNoType IsFlag {get;set;}
    }
   

Mapping configuration

CreateMap<Source , Desitination>()
.ForMember(d => d.Fragile, o => o.MapFrom(s => s.Inner.IsFlag == true ? YesNoType.Y : YesNoType.N))

Version: x.y.z

11.0.1

Expected behavior

When Source.Inner.IsFlag is null value, I will expect the mapping will be triggered and according to the mapping logic, the null value should be converted to YesNoType.N.

I expected Desitination.IsFlag value should be YesNoType.N

Actual behavior

Desitination.IsFlag is YesNoType.Y which looks like it pick the default value from the YesNoType Enum.
o.MapFrom(s => s.Inner.IsFlag == true ? YesNoType.Y : YesNoType.N) is not executed during the debug.

The expected behaviour is working with version 10.1.1 but not with version 11.0.1. I have a unit test to verify it with upgrading/downgrading the automapper version.

Steps to reproduce

var source = new Source { new Inner { IsFlag = null }};
var dest = _mapper.Map<Desintation>(source);
Assert.AreEqual(dest.IsFlag , YesNoType.N); // This one will fail since the value of dest.IsFlag is YesNoType.Y

[lbargaoanu]

cfg.CreateMap<Model, Dto>().ForMember(d => d.IsFlag, o => o.MapFrom(s => s.Inner.IsFlag));
cfg.CreateMap<bool?, YesNo>().ConvertUsing(s=>s.ConvertIsFlag());

Or you can use a Func based resolver, which is not null checked. What happens here is that the new null checking code doesn't call your extension method because IsFlag is null. That seems reasonable.

[rootix]

Is this new null checking behavior documented or mentioned as a breaking change? We upgraded from 10 to 11 and have many such issues with nullable source members which now don't get null. We relied (good or bad) on the behavior that it was set to null in such cases. It will be a real pain to review all mapping profiles for those issues. But sticking to Automapper 10 forever isn't a solution either.

[lbargaoanu]

I don't want to add a special case just for backward compatibility. This is a weird corner case and you're supposed to have tests :)
You can get the compiler to help by temporarily removing this so it's not an extension method anymore.