ResolutionContext lost in nested mapping

[riiight]

When using MapFrom(), any IMappingOperationOptions.Items that are passed in are not passed along to nested ResolutionContext.Mapper.Map() calls. I realize that I can then manually readd the Items to the nested Map() call, but I believe it should happen automatically.

(NOTE: The example below is extremely simplified. You may think, "these mappings should just be handled through _____ (e.g. conventions)", but just keep in mind the main point is that the IMappingOperationOptions.Items are lost.

Source/destination types

public class FromGarage
	{
		public List<FromCar> FromCars { get; set; }
	}

public class ToGarage
	{
		public List<ToCar> ToCars { get; set; }
	}

public class FromCar
	{
		public int Id { get; set; }
		public string Name { get; set; }
		public Door Door { get; set; }
	}

public class ToCar
	{
		public int Id { get; set; }
		public string Name { get; set; }
		public Door Door { get; set; }
	}

Mapping configuration

CreateMap<FromGarage, ToGarage>()
                .ForMember(dest => dest.ToCars, opts => opts.MapFrom((src, dest, destVal, ctx) => 
                {
                    var toCars= new List<ToCar>();

                    ToCar toCar;
                    foreach (var fromCar in src.FromCars)
                    {
// I KNOW I COULD PASS IN THE ITEM "DOOR" MANUALLY RIGHT HERE, BUT SHOULDN'T THIS HAPPEN AUTOMATICALLY?
                        toCar = ctx.Mapper.Map<ToCar>(fromCar);
                        if (toCar == null)
                            continue;

                        toCars.Add(toCar);
                    }

                    return toCars;
                }));

CreateMap<FromCar, ToCar>()
                .ConvertUsing((src, dest, ctx) =>
                {
                    ToCar toCar = null;

                    if (fromCar.Name != null)
                    {
                        toCar.Id= fromCar.Id;
                        toCar.Name = fromCar.Name;

                            // ERROR OCCURS HERE. ITEMS ARE NOT THERE.
                            var door = ((Door)ctx.Items["Door"]);

                        toCar.Door = door;
                    }

                    return toCar;
                });

Version: 8.0.0

Expected behavior

I would expect that the nested "ctx.Mapper.Map" call would pass along the IMappingOperationOptions.Items that were passed to it via the ResolutionContext.

Actual behavior

The ResolutionContext of the nested "ctx.Mapper.Map" call does not contain any of the Items that were originally passed in.

Steps to reproduce

var toGarage = _mapper.Map<ToGarage>(fromGarage, opts =>
            {
                opts.Items.Add("Door", _door);
            });

[lbargaoanu]

There is one context per Map call, and you're calling Map multiple times. That's manual mapping and maybe there is no surprise you should pass the context yourself. It should be easy to write an extension method that does what you want.

[jbogard]

I think this is a bug - the point of the context was for it to be instantiated once and flow through any map calls when you call ResolutionContext.Mapper.Map.

[lbargaoanu]

No, not really. That's why we added context.Map.

[jbogard]

That's internal though.

[lbargaoanu]

It's always has been. Most people don't care. We could make it public, but then you'd have to explain the difference. It's a minor inconvenience in my view. And it still wouldn't work like the built in mapping because there's no member map to pass.

[lbargaoanu]

It would matter more for PreserveReferences, because if you forget to pass it then, it can crash with SO.

[jbogard]

The intent of context.Mapper was that the same context would flow through all calls from the initial IMapper.Map call. Instead of you calling Mapper.Map inside converters, resolvers etc. you would use the context map instead. If that's not what is happening, then I think it's a bug (or at least a missing feature here).

[lbargaoanu]

It never tried to do that. So you're actually describing context.Map.

[jbogard]

Well nuts, I've been telling folks to use context.Mapper.Map for that purpose.

[lbargaoanu]

:) Well, in most cases it doesn't matter. And starting to replicate all those Map overloads on context, is much worse in my view. So what happens now is not by accident.