Automapper: Remove dynamic maps (CreateMissingTypeMaps)

[jbogard]

After having these out for a bit, is there any real value to them? They seem to cause more problems than they solve.

I don't use them, none of our teams do, and they go against the original design philosophy.

This would mean convention-based stuff would go too, to be replaced with scanning-based conventions. The only late-created maps I'd want are closing generic types.

• Version 8.1.1 - Deprecate CreateMissingTypeMaps and change the default to false #3102
• Version 9.0 - Remove all means of creating dynamic/inline map #3134

[lbargaoanu]

Well, I agree, but disruptive it is :)

[TylerCarlson1]

I use them for convention based maps. For things like transfer EF objects to and from DTO objects if they go to-from the EF namespace to a DTO namespace.

The design philosophy is to form conventions, but the one convention you don't have accounted for are destination view models have a convention by name. With convention-based generation, you can enforce names of class follow a rule as well. Like OrdersViewModel can only be mapped to Orders and OrdersVM shouldn't work, or be there because it breaks convention. I believe I read something you wrote where you explained this, and you ended up writing a unit test making sure the class names ended with ViewModel for maps and if any of them didn't the test would fail and therefore the build.

If you are going to use the conventions to scan and create the maps at initialization based on a convention I can see that being better possibly, minus the initial start time to scan everything. As you can assert configuration is valid at startup, instead of at the moment you use the feature for the first time.

[jbogard]

I get the point of conventions and it makes sense, but I'd rather the maps be added up front. I just wasn't sure how that would look from the convention perspective - you'd want to scan without having an O(n^2) problem

[TylerCarlson1]

One way would be to take the existing convention and do a source type filter, destination type filter, and a type pair filter, instead of just TypePair filter that we have now.

Instead of O(n^2) it would be O(s*d) with s and d being source and destination filtered list, and being a smaller subset of n. In my example s would be EF types and d would be DTO types. And vice versa for mapping back, or have both in one filtering. So maybe two 50x50 comparisons, or one 100x100 comparison instead of one 2000x2000 comparisons at startup, having to query every type in every assembly.

The only weird thing would be conveying that to the user, that they need to provide 3 filters for a convention, instead of the 1 currently. Also better the pre-filters the better the initial startup performance

[MoienTajik]

Removing this feature entirely may cause breaking changes in some libraries as they depend on InlineMappings.

What's the actual problem with the ability to Enable/Disable this feature ( as what it is now ) instead of removing it entirely?

[jbogard]

I don’t use it, will never use it, and don’t want to support the extra code
and work necessary to keep it, with all the bugs and weird behavior that
comes with it.

On Sat, Jun 8, 2019 at 9:13 AM Moien Tajik [e-mail] wrote:

Removing this feature entirely may cause breaking changes in some
libraries as they depend on InlineMappings.

What's the actual problem with the ability to Enable/Disable this feature
( as what it is now ) instead of removing it entirely?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/3063?email_source=notifications&email_token=AAAZQMRWYZVNON6GAKRCWX3PZPLDZA5CNFSM4HJ6L5R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXUJY#issuecomment-500136487,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMTZKQD5G3KXCWPURRLPZPLDZANCNFSM4HJ6L5RQ
.

[MoienTajik]

That's true and I know it's hard to support such a feature, but what about breaking changes in other libraries that depends on this feature? This way, that libraries should implement this feature manually again.

[lbargaoanu]

But the thing is, a higher level library knows a lot more than AM about the types it is mapping. So it's in a better place to know when a default map would help and when not. So all what a higher level library can do is create the needed maps statically, at config time, but at least it can create helpful maps.

[jbogard]

The one that’s most affected right now is the conventions stuff. That’ll
have to change to use explicit scanning.

On Sun, Jun 9, 2019 at 1:30 AM Lucian Bargaoanu [e-mail]
wrote:

But the thing is, a higher level library knows a lot more than AM about
the types it is mapping. So it's in a better place to know when a default
map would help and when not. So all what a higher level library can do is
create the needed maps statically, at config time, but at least it can
create helpful maps.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/3063?email_source=notifications&email_token=AAAZQMRR6IE5X35KF2VQX5TPZSPQFA5CNFSM4HJ6L5R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIENBA#issuecomment-500188804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMSKWDG4S4QSUEHJ7N3PZSPQFANCNFSM4HJ6L5RQ
.

[mobius7777]

I just saw this in the code with VS flagged the "CreateMissingTypeMaps" method as obsolete:
"Support for automatically created maps will be removed in version 9.0. You will need to explicitly configure maps, manually or using reflection."

This distresses me greatly. Our project has thousands of DTO mappings, and many do so simply by convention, as 90% of the mappings are one-to-one properties. It's always worked perfectly. The entire reason we chose AutoMapper over other, similar libraries, was because of the dynamic mapping. If this goes away, we are going to have a massive mess on our hands.

I understand the need to clean up code and move forward with a leaner, meaner library. Clearly, Automapper currently has the functionality to do this. Perhaps it could be spun-off as an extension? Those who want to use can include the extension in their project, but those don't need it can just ignore it.

[lbargaoanu]

Surely there is some convention for the types you're mapping. You can use reflection to create those maps. And for the rest, you can use the attributes. It doesn't seem difficult.

[TylerCarlson1]

@mobius7777 You still can use a convention it's just that it will create all the type maps after configuration instead of making the maps on the fly the first time they are used.

[roblugt]

It seems that the ability to use the AutoMapper.Data package to convert from IDataReader to a collection of C# objects without any explicit mapping configuration has been disabled in v8.1.1. Is this related to this change? If so is there a setting to re-enable dynamic mappings in v8.x.x - and how does one do this?

[norachuga]

While I completely support @jbogard 's decision to deprecate dynamic maps, I am blown away that you would make such a consequential change on a patch release.

[lbargaoanu]

Why, because you get a compiler warning?

[jbogard]

You don’t because that setting was default true before, we changed the
default behavior and you don’t see a compiler warning for that.

On Fri, Jul 5, 2019 at 12:25 PM Lucian Bargaoanu [e-mail]
wrote:

Why, because you get a compiler warning?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/3063?email_source=notifications&email_token=AAAZQMQUXSXM4YEHNJO2EQLP557XBA5CNFSM4HJ6L5R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJ76CI#issuecomment-508821257,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMS7VJ7DXK5OLOHDEVTP557XBANCNFSM4HJ6L5RQ
.

[roblugt]

Users of @jbogard's other creation -AutoMapper.Data - get a very nasty surprise: no warnings and suddenly not working even though the (albeit scanty) instructions are followed.

[lbargaoanu]

AM.Data is not our concern. But using AM itself you get an error message telling you exactly what's wrong.