Automapper: `CreateMissingTypeMaps` doesn't work for destination object if source and destination types are the same

[llRandom]

Source/destination types

class A
{
    public string X { get; set; }
}

class B
{
    public string X { get; set; }
}

Mapping configuration

var config = new MapperConfiguration(cfg => cfg.CreateMissingTypeMaps = true)

Version: 5.1.1

Expected behavior

I pass an existing object to be filled. The type of source and destination objects are the same. I expect the destination object to be filled.

Actual behavior

The destination object is not filled. If I use a different destination type, it works fine. If I create a new object of the same type, it also works fine.

Steps to reproduce

var config = new MapperConfiguration(cfg => cfg.CreateMissingTypeMaps = true);
var mapper = config.CreateMapper();
var a1 = new A { X = "sample" };
var a2 = new A();
mapper.Map(a1, a2); // a2.X was not set, looks like a bug
var a3 = mapper.Map<A>(a1); // a3.X is set, ok

var b = new B();
mapper.Map(a1, b); // b.X is set, ok

[jbogard]

This is expected behavior. If the source/destination types are assignable to each other, AutoMapper simply assigns them (as AutoMapper is not a cloning library).

If you want to explicitly map between two assignable types in a pseudo-cloning behavior, you need to explicitly create the map.

CreateMissingTypeMaps should be used with extreme caution - it's not meant to be a fix for developer laziness. It's really when you don't know all the maps at config-time.

You're also not even cloning, but filling in an existing object. Just call CreateMap. That works.

[llRandom]

But the cloning actually works (case with a3 variable). It's really not clear why this call just returns the source object and doesn't modify the destination. Could you please explain it in more details?

[jbogard]

This kind of behavior, mapping to itself PLUS CreateMissingTypeMaps isn't a supported scenario, so the behavior is unknown.

[llRandom]

But why it could not or should not be supported? Why this case is an exception?

[jbogard]

It's just a scenario that has any tests around it. That's what I mean "not
supported", it's not designed for this scenario. Things also tend to act
not ideal for CreateMissingTypeMaps, which is why I discourage its use as
much as possible. Be explicit about what you intend to map, and things tend
to work just fine.

On Mon, Jun 5, 2017 at 1:38 PM, Eugene [e-mail] wrote:

But why it could not or should not be supported? Why this case is an
exception?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2129#issuecomment-306268768,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMuCU5FWXM2DC1pJp-QgANR4OVyfUks5sBEsZgaJpZM4Nub7f
.

[llRandom]

I still don't understand, is it some design limitation that blocks from implementing it or is there a logical reason why this particular case should not be supported?

[feafarot]

I also can't understand what is the real reasoning behind this. Why do you need to create a mapping between the same type explicitly? What is the point?

[jbogard]

AutoMapper isn’t a cloning library. Never has been as part of its design.

Specifically what’s going on here is there is a fallback mapping strategy,
that if two types are assignable, just assign them. If you want to
explicitly map these two types, call CreateMap or remove the
AssignableMapper from the list of mappers. I don’t know what those side
effects will be, likely making your mapping slow since everything has to
now go through some mapping strategy. Primitive types will be wonky for
example.

So while you can clone in some scenarios, it’s not an out of the box
behavior.

On Wed, Dec 27, 2017 at 4:22 AM feafarot [e-mail] wrote:

I also can't understand what is the real reasoning behind this.

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2129#issuecomment-354091668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMkHJ-nuNqmPBQUBk5XIVv-HMCLGCks5tEhpwgaJpZM4Nub7f
.

[lock[bot]]

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.