@jbogard Any chance of a review on this one?

So I think this is an easy, but wrong way to fix this problem. To me, the larger problem we have here is that there is configuration that affects a group of TypeMaps, and currently the only way to affect of type map creation is a Profile. Additionally, the final configuration result, ProfileMap is standalone. The most you can do is give it the root configuration, and those values are copied over.

The way you can adjust configuration so specific kinds of TypeMaps is what you're doing - applying a flag and propagating it everywhere. That's something I generally want to avoid.

Affecting TypeMap creation is even more difficult - the only hook for that is anything on a ProfileMap as it stands today. Even something like ForAllTypeMaps doesn't let you modify configuration in the ProfileMap.

As I see it, if we don't want to start adding one-off flags for behaviors like this, we can:

• Apply a sensible default - like automatically reverse the naming conventions anyway. Usually they're the same.
• Devise some new way of applying configuration to groups of TypeMaps, but in such a way that the result is the thing getting passed down to TypeMapFactory.

@lbargaoanu it would be a breaking behavioral change to reverse naming conventions on ReverseMap, but that does seem rather reasonable. Your only other option today is to separate profiles, but then it's no longer a reverse map.

Yes, the fix is arbitrary. The way I see it, reverse maps are not that special. If the setting is per profile, I wouldn't want to special case reverse maps. But we could say that the setting is per map. We could then allow users to define their own extension method to opt in or to be able to configure reverse maps some other way. Or do it by default as you've said and take the breaking change. It could be done, but I'm not sure it's worth the trouble. It's clumsy, but it works. I don't think many people complained over the years. And ReverseMap is already complicated enough.

Yes, the fix is arbitrary. The way I see it, reverse maps are not that special. If the setting is per profile, I wouldn't want to special case reverse maps. But we could say that the setting is per map. We could then allow users to define their own extension method to opt in or to be able to configure reverse maps some other way. Or do it by default as you've said and take the breaking change. It could be done, but I'm not sure it's worth the trouble. It's clumsy, but it works. I don't think many people complained over the years. And ReverseMap is already complicated enough.

AutoMapper has the naming convention functionality already. It seems bizarre to say "this feature works fine unless you're reversing the mapping". Surely that is a bug. Yeah, I set 2 separate mappers up now to handle it. But it's inelegant.

Well, reverse mapping was only recently a "thing" in AutoMapper. Of course lots of things don't make sense in the reverse direction - it was never originally designed to do this (I never use reverse mapping on any of my projects either). Just because it doesn't work the way you like, does not make it a bug.

I don't want to make the overall design worse with reverse mapping, since it's not a thing I nor any of my clients use. But I'm OK making reasonable defaults, it's just that naming conventions happen so early in the process there's no hook for it.

Rather than make this configurable, I'd vote for just reversing them by default. If you don't want that behavior, THEN we can have you split the mappings.

Suits me.

Then the mappping configuration should have the naming conventions reversed and the code applying the conventions should just use what's set in the configuration.

The problem is naming conventions aren't applied at a TypeMap level, they're applied at a ProfileMap level. You can't reverse the naming conventions on a type map, you can only reverse how they're applied when we create them.

That's why I was saying it makes sense for the setting to be changed per map. If it's per profile, why change it for a reverse map, it's in the same profile after all :)

The reverse mapping does a number of helpful things though, reversing the other configuration. To me this is in a similar vein - why wouldn't you want the member naming convention to be reversed?

All I'm saying, it makes a lot more sense if somehow the naming convention is per map, not per profile (the profile setting is just the default). Then, as you say, ReverseMap will just reserve the base map configuration.

Oh my god this api compat file

I guess we should exclude somehow what's public but not in the API.

I modified this PR to reverse the naming conventions based on if the type map is a reverse map or not.

The naming conventions stuff tbqh I don't really understand too much, but we don't set naming conventions on a type map. We use the results of applying a naming convention to set a type map, so I thought the next best thing would be to at least mark a type map as a reverse map.

It's ad hoc. But I do agree that code is difficult to understand/change.

It is ad-hoc, but I thought rather than the profiles or type maps having instructions for lower-level components, instead they describe what they are and lower level components adjust their mapping strategies accordingly.

So you didn't want to simply pass the naming conventions to MapDestinationPropertyToSource.

Granted, that interface is terrible :)

I think we might have to figure out some other solution for the ApiCompat file. These merge conflicts are killing me

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