Upgrade to AutoMapper 5.0.2 issue

[dmdymov]

I'm trying to upgrade my project from AutoMapper 4.1.1 / AutoMapper.Collection 1.1.2 to AutoMapper 5.0.2 / AutoMapper.Collection 2.0.1. I have a scenario which works fine with old dlls and I get unexpected null as a result of mapping with new dlls.

Gist with issue code.

Is this a bug or I am missing something?

[TylerCarlson1]

I think this is a bug with AutoMapper 5.0.2 and you need to upgrade that. When source or destination are null it defaults back to the CollectionMapper in AutoMapper to do the mapping.

I know Collection mapping has been updated recently in AutoMapper.

[dmdymov]

For the latest AutoMapper 5.1.1:

System.MethodAccessException at Mapper.Initialize:
"AutoMapper.Mappers.EquivlentExpressionAddRemoveCollectionMapper.IsMatch(AutoMapper.TypePair)" couldn't get access to "AutoMapper.Configuration.PrimitiveExtensions.IsEnumerableType(System.Type)"

Any thoughts on this?

[TylerCarlson1]

Now THAT is a bug that I need to fix.

I'll try to make a build that fixes it that works in 5.1.1 by the end of the week.

[TylerCarlson1]

2.1.0 Should fix this issue.

Removed as much of AutoMapper's internal code I was using before, so hopefully only refactors of the API will only require updates.

[dmdymov]

Yes, there's no exception with 2.1.0. But null as a result of mapping is still there. I think I'll try to create an Automapper issue.

[dmdymov]

I am here again. AutoMapper issue.

@lbargaoanu :

Then I guess @TylerCarlson1 should help you here.

What should I do know? This is getting a bit weird.

[TylerCarlson1]

I'll have to look into it some more then.

[TylerCarlson1]

Yea when updating the logic changed and the null check changed and caused the functionality to break for nulls.

[TylerCarlson1]

2.1.1 should fix the original issue. Wrote unit tests for it.

[dmdymov]

Everything is OK now, thank you.