MapFrom variable 'src' of type 'Xyz' referenced from scope '', but it is not defined

[adam-resdiary]

I've having an issue where I have a mapping using MapFrom, where the expression passes the object being mapped into a method call. I'm not quite sure how to explain this properly, but I've managed to create a set of tests that highlight the issue.

I've tested this against the MyGet alpha version of AutoMapper.

So say I have the following classes:

public interface IDateProvider
{
	DateTime CurrentRestaurantTime(Restaurant restaurant);
}

public class Result
{
	public Booking Booking { get; set; }
}

public class Restaurant
{
}

public class Booking
{
	public Restaurant Restaurant { get; set; }

	public int? CalculateTotal(DateTime currentTime)
	{
		return null;
	}
}

public class ResultDto
{
	public BookingDto Booking { get; set; }
}

public class BookingDto
{
	public int? Total { get; set; }
}

And I create the following mapping:

var mapperConfiguration = new MapperConfiguration(cfg =>
{
	cfg.CreateMap<Result, ResultDto>();
	cfg.CreateMap<Booking, BookingDto>()
		.ForMember(d => d.Total,
			o => o.MapFrom(b => b.CalculateTotal(_dateProvider.CurrentRestaurantTime(b.Restaurant))));
});

When I try to map from a Result to a ResultDto, I get the following exception:

System.InvalidOperationException : variable 'src' of type 'AutoMapperRepros.Class1+Booking' referenced from scope '', but it is not defined
   at System.Linq.Expressions.Compiler.VariableBinder.Reference(ParameterExpression node, VariableStorageKind storage)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitParameter(ParameterExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitMember(MemberExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitArguments(IArgumentProvider nodes)
   at System.Linq.Expressions.ExpressionVisitor.VisitMethodCall(MethodCallExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitArguments(IArgumentProvider nodes)
   at System.Linq.Expressions.ExpressionVisitor.VisitMethodCall(MethodCallExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitTry(TryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitBinary(BinaryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitTry(TryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitConditional(ConditionalExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitBinary(BinaryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitTry(TryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitBlock(BlockExpression node)
   at System.Linq.Expressions.ExpressionVisitor.VisitConditional(ConditionalExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
   at System.Linq.Expressions.Compiler.VariableBinder.VisitLambda[T](Expression`1 node)
   at System.Linq.Expressions.Compiler.VariableBinder.Bind(LambdaExpression lambda)
   at System.Linq.Expressions.Compiler.LambdaCompiler.Compile(LambdaExpression lambda, DebugInfoGenerator debugInfoGenerator)
   at AutoMapper.MapperConfiguration.CreateMapperFuncs(MapRequest mapRequest)
   at AutoMapper.LockingConcurrentDictionary`2.<>c__DisplayClass2_1.<.ctor>b__1()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at AutoMapper.MapperConfiguration.GetUntypedMapperFunc(MapRequest mapRequest)
   at AutoMapper.Mapper.AutoMapper.IMapper.Map[TDestination](Object source)
   at AutoMapperRepros.Class1.FailingMapping() in C:\Users\AdamConnelly\github.com\adam-resdiary\AutoMapperRepros\AutoMapperRepros\Class1.cs:line 40

I can work around this by extracting the lambda into a separate method instead of writing it inline.

Here's a link to a gist with one test that fails, highlighting the issue, and another test that passes showing the workaround: https://gist.github.com/adam-resdiary/137396c167c03cda15d42816d953461b

[lbargaoanu]

Try ResolveUsing instead.

[adam-resdiary]

Yeah - that works fine.

Just so I know - is that expected behaviour, or is ResolveUsing just another workaround for now?

[lbargaoanu]

Well, I guess it should work with MapFrom too, but really what you're doing means ResolveUsing. Because you're taking over the mapping, it's not just a simple redirect or smth that could be used for ProjectTo. So MapFrom is not useful here, bug or no bug.

[adam-resdiary]

Ok - I'll try to get into the habit of using ResolveUsing. I just got used to being able to use MapFrom because it seemed to have the same effect.

[jbogard]

Even further than that - you've got a closure in your expression. In general, you'd want to use a resolver to pass that object through. When you use closures in MapFrom, AutoMapper assumes that you want that parameter swapped at runtime. Those kinds of dependencies that you use, really should be done via DI, not a scoped parameter.

[adam-resdiary]

@jbogard can I just double check I'm understanding what you mean?

So basically what you're saying is that in any situation like this where we have a closure, we should really create a separate custom resolver class to handle it.

So instead of:

public class MyMapperConfig
{
    private readonly IDateTimeProvider _dateTimeProvider;

    public MyMapperConfig(IDateTimeProvider dateTimeProvider)
    {
        _dateTimeProvider = dateTimeProvider;
    }

    public void Configure(IMapperConfigurationExpression config)
    {
        config.CreateMap<Booking, BookingDto>()
            .ForMember(d => d.Total,
                o => o.MapFrom(b => b.CalculateTotal(_dateProvider.CurrentRestaurantTime(b.Restaurant))));
    }
}

What we'd actually do is:

public class MyMapperConfig
{
    public void Configure(IMapperConfigurationExpression config)
    {
        config.CreateMap<Booking, BookingDto>()
            .ForMember(d => d.Total, o => o.ResolveUsing<BookingTotalCalculator>());
    }
}

public class BookingTotalCalculator : IValueResolver<Booking, BookingDto, int>
{
    private readonly IDateTimeProvider _dateTimeProvider;

    public BookingTotalCalculator(IDateTimeProvider dateTimeProvider)
    {
        _dateTimeProvider = dateTimeProvider;
    }

    public int Resolve(Booking source, BookingDto dest, int destMember, ResolutionContext context)
    {
        return source.CalculateTotal(_dateProvider.CurrentRestaurantTime(source.Restaurant));
    }
}

If so, I'll need to think about that for a while. I can sort of understand why it could be a problem, but I also feel like it's adding an extra layer of complication.

On another note, why is the destination member passed into a value resolver? I could sort of understand the source member being passed in, but I'm scratching my head as to why the destination gets passed in.

[jbogard]

So, this is a bug. I'm fixing it - the underlying cause is we were not properly replacing some expressions underneath the covers.

In previous versions we merely compiled the expression, this time we're trying to be smart about it.

[adam-resdiary]

Cool - thanks for fixing it.

Sorry for bombarding you guys with questions. It's just that I've been upgrading quite a large code-base to the latest version because of the massive performance improvements you've made, and I'm noticing things / thinking about how we can use AutoMapper better.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.