views:

1496

answers:

2

Is there a way to tell AutoMapper to ignore all of the properties except the ones which are mapped explicitly?

I have external DTO classes which are likely to change from the outside and I want to avoid specifying each property to be ignored explicitly, since adding new properties will break the functionality (cause exceptions) when trying to map them into my own objects.

+1  A: 

The only infromation about ignoring many of members is this thread - http://groups.google.com/group/automapper-users/browse_thread/thread/9928ce9f2ffa641f . I think you can use the trick used in ProvidingCommonBaseClassConfiguration to ignore common properties for similar classes.
And there is no information about the "Ignore the rest" functionality. I've looked at the code before and it seems to me that will be very and very hard to add such functionality. Also you can try to use some attribute and mark with it ignored properties and add some generic/common code to ignore all marked properties.

zihotki
Perhaps one way would be to use ForAllMembers method and implement my own IMemberConfigurationExpression which receives a string containing the property names of those properties which should not be ignored, and then go through the rest of them and call Ignore(). Just an idea, I'm not sure if it would work.
Igor Brejc
Yes, this can work too, but this method is more tricky than using attributes but it offers more flexibility. It's a pity that there are no silver bullet :(.
zihotki
+4  A: 

How would you prefer to specify that certain members be ignored? Is there a convention, or base class, or attribute you would like to apply? Once you get into the business of specifying all the mappings explicitly, I'm not sure what value you'd get out of AutoMapper.

Jimmy Bogard
Jimmy, you have a point about explicitness. As for the way on how to achieve this in a most elegant way: base classes and attributes would not work in this situation, since the target classes aren't really under my control - they are autogenerated from XSD data contract, so one would have to manually edit this code after each generation cycle.I guess the solution depends on a concrete case. Maybe a fluent interface similar to the one Windsor Castle provides for selecting which components to register in the container could be a solution?
Igor Brejc
Ah that makes more sense now. That's an interesting feature, I'll look at that one in the 2.1 timeframe.
Jimmy Bogard