AssertConfigurationIsValid fails after upgrade to 8.0
See original GitHub issueCode working using version 7.0.1 fails with exception after upgrade to 8.0. Mapping was using resolver with ResolveUsing which is now changed to MapFrom. AssertConfigurationIsValid seems to not see the mapping. (I dont think my usage is one that is called out by the upgrade guide as a breaking case, and looks to be as shown in documentation - http://docs.automapper.org/en/latest/Custom-value-resolvers.html). I tried with a converter instead of a resolver with same results.
Source/destination types
public class DoctorViewModel
{
public string FirstName { get; set; }
...
}
public class DoctorDetailViewModel : DoctorViewModel
{
public List<int> DoctorSpecialties { get; set; }
...
}
public class Doctor
{
public string FirstName { get; set; }
public ICollection<DoctorSpecialty> DoctorSpecialties { get; set; }
...
}
public class DoctorSpecialty
{
public int SpecialtyId { get; set; }
...
}
Mapping configuration
// Using Resolver shown, same failure using converter
CreateMap<DoctorDetailViewModel, Doctor>(MemberList.Source)
.ForMember(dest => dest.DoctorSpecialties, opt => opt.MapFrom<SpecialtyFromIdResolver>());
private class SpecialtyFromIdResolver : IValueResolver<DoctorDetailViewModel, Doctor, ICollection<DoctorSpecialty>>
{
ICollection<DoctorSpecialty> IValueResolver<DoctorDetailViewModel, Doctor, ICollection<DoctorSpecialty>>.Resolve(DoctorDetailViewModel source, Doctor destination, ICollection<DoctorSpecialty> destMember, ResolutionContext context)
{
List<DoctorSpecialty> specialties = new List<DoctorSpecialty>();
source.DoctorSpecialties?.ForEach(s => specialties.Add(new DoctorSpecialty() { SpecialtyId = s }));
return specialties;
}
}
Version: 8.0.0
Expected behavior
Configuration and mapping should succeed as expected as it does using 7.0.1
Actual behavior
Get exception:
{AutoMapper.AutoMapperConfigurationException: The following property on Doctor cannot be mapped:
DoctorSpecialties
Add a custom mapping expression, ignore, add a custom resolver, or modify the destination type Doctor.
Context:
Mapping to property DoctorSpecialties from DoctorDetailViewModel to Doctor
Exception of type 'AutoMapper.AutoMapperConfigurationException' was thrown.
at AutoMapper.ConfigurationValidator.DryRunTypeMap(ICollection`1 typeMapsChecked, TypePair types, TypeMap typeMap, PropertyMap propertyMap) in C:\projects\automapper\src\AutoMapper\ConfigurationValidator.cs:line 97}
Steps to reproduce
Mapper.AssertConfigurationIsValid();
Issue Analytics
- State:
- Created 5 years ago
- Comments:9 (3 by maintainers)
Top Results From Across the Web
AssertConfigurationIsValid call fails but mapping still works ...
One of the enums you can pass to CreateMap . Essentially it tells Automapper to check that all source members are mapped. Default...
Read more >Configuration Validation
AutoMapper provides configuration testing in the form of the AssertConfigurationIsValid method. Suppose we have slightly misconfigured our source and ...
Read more >Validate Automapper Configurations with ...
This tip gives a solution by using the verification feature of AutoMapper, AssertConfigurationIsValid. Introduction. Automapper permits to map a ...
Read more >Missing type map configuration or unsupported mapping
After rebuilding the solution it works fine again. I tried unit testing with Mapper.AssertConfigurationIsValid() as mentioned in https://github.
Read more >I hate AutoMapper : r/dotnet
Yes, you can definitely get run-time checks that the map won't fail.. You can also use configuration.AssertConfigurationIsValid(); in a unit ...
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
Thanks!
@jonsagara You can workaround it by not using a class for your resolver.