Mapping to child properties defined with auto-property pattern silently fails
See original GitHub issueSource/destination types
class Child { }
class ChildViewModel { }
class Parent
{
public Parent()
{
Children = new List<Child>();
NeglectedChildren = new List<Child>();
}
public ICollection<Child> Children { get; private set; }
public ICollection<Child> NeglectedChildren { get; private set; }
}
class ParentViewModel
{
public ParentViewModel()
{
Children = new List<ChildViewModel>();
}
public ICollection<ChildViewModel> Children { get; private set; }
public ICollection<ChildViewModel> NeglectedChildren { get; } = new List<ChildViewModel>();
}
Mapping configuration
private class TestProfile : Profile
{
public TestProfile()
{
CreateMap<Child, ChildViewModel>();
CreateMap<Parent, ParentViewModel>();
}
}
Version: x.y.z
6.0.2
Expected behavior
I expect the ParentViewModel.NegelectedChildren collection to contain the same number of elements as source Parent.NeglectedChildren.
Actual behavior
ParentViewModel.NegelectedChildren is empty regardless of the number of elements in the source Parent.NegelectedChildren collection.
Steps to reproduce
Given a class with both a collection property defined with { get; private set; } and a collection property using the auto-property with initializer pattern:
private IMapper _mapper;
[TestInitialize]
public void TestInitialize()
{
var config = new MapperConfiguration(cfg =>
{
cfg.AddProfile<TestProfile>();
});
_mapper = config.CreateMapper();
}
[TestMethod]
public void WillPopulateAllElementsIntoChildrenCollection_WhenSourceChildrenIsNotEmpty()
{
// Arrange
var packet = new Parent();
packet.Children.Add(new Child());
packet.Children.Add(new Child());
packet.NeglectedChildren.Add(new Child());
packet.NeglectedChildren.Add(new Child());
// Act
var result = _mapper.Map<ParentViewModel>(packet);
// Assert
result.ShouldSatisfyAllConditions(
() => result.ShouldNotBeNull(),
() => result.Children.Count.ShouldBe(2),
() => result.NeglectedChildren.Count.ShouldBe(2));
}
The test fails:
Test method WillPopulateAllElementsIntoChildrenCollection_WhenSourceChildrenIsNotEmpty threw exception:
Shouldly.ShouldAssertException: result
should satisfy all the conditions specified, but does not.
The following errors were found ...
--------------- Error 1 ---------------
result.NeglectedChildren.Count
should be
2
but was
0
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (9 by maintainers)
Top Results From Across the Web
Mapping to readonly IEnumerable property · Issue #2064
When trying to map to a readonly IEnumerable property backed by an instance of an IList field AutoMapper throws a NullReferenceException.
Read more >Best way to project ViewModel back into Model
I believe best way to map from ViewModel to Entity is not to use AutoMapper for this. AutoMapper is a great tool to...
Read more >Common Hibernate Exceptions
Many conditions can cause exceptions to be thrown while using Hibernate. These can be mapping errors, infrastructure problems, SQL errors, ...
Read more >Use composition and inheritance for DTOs
One reason not to use concrete inheritance among DTOs is that certain tools will happily map them to the wrong types.
Read more >Spring Boot Reference Documentation
The properties that map to @ConfigurationProperties classes available in Spring Boot, which are configured via properties files, YAML files, ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I wonder, would adding a MapFrom along with UseDestinationValue work?
An aside, maybe it’s a bit weird that we just skip adding property maps that don’t have a setter vs. adding them and then deciding how to deal with it.
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.