Activities of "pareeks@gccontractor.org"

I’m looking for a way to handle this either via a global Mapperly configuration or a mapper-level configuration, without having to make widespread nullable changes across the domain and DTO models.

For context, here’s a simple example:

public partial class HrCountryWithNavigationPropertiesToDtoMapper 
    : MapperBase<HrCountryWithNavigationProperties, HrCountryWithNavigationPropertiesDto>
{
    public override partial HrCountryWithNavigationPropertiesDto Map(HrCountryWithNavigationProperties source);
    public override partial void Map(HrCountryWithNavigationProperties source, HrCountryWithNavigationPropertiesDto destination);
}

public class HrCountryWithNavigationProperties
{
    public HrCountry HrCountry { get; set; }
    public HrMailCountry HrMailCountry { get; set; }
}

public class HrCountryWithNavigationPropertiesDto
{
    public HrCountryDto HrCountry { get; set; }
    public HrMailCountryDto HrMailCountry { get; set; }
}

During runtime, if HrMailCountry (or any navigation property) is null, Mapperly throws a NullReferenceException. This differs from AutoMapper’s behavior, where null navigation properties were implicitly ignored or mapped to default values. Making these properties nullable (HrMailCountry?, HrMailCountryDto?) resolves the issue, but that would require extensive refactoring across the solution, which I’d like to avoid if possible.

• Exception message and full stack trace: System.NullReferenceException: 'Object reference not set to an instance of an object.' source was null.
• Steps to reproduce the issue: I recently upgraded an existing ABP.io project from .NET 9 to .NET 10. As part of the upgrade, ABP is moving from AutoMapper to Mapperly. After migrating an ABP application from AutoMapper to Mapperly, we are encountering numerous NullReferenceExceptions across the application during DTO mapping. The root cause is that AutoMapper implicitly handled null source navigation properties by skipping mapping or creating default values, whereas Mapperly is strict and assumes non-nullable mappings unless nullability is explicitly modeled.
• Expected behavior A migration path similar to AutoMapper, where:

• null source navigation properties are handled gracefully
• Mapping either skips assignment or assigns default values
• No runtime NullReferenceException occurs by default

• Actual behavior

• Mapperly generates mapping code that assumes non-nullable source objects
• NullReferenceException is thrown when optional navigations are null
• No global configuration option exists to preserve AutoMapper-style default handling

• Question / Request Is there any global or framework-level configuration in ABP / Mapperly that allows:

• Automatic handling of null source navigation properties
• Default-value assignment or safe skipping (similar to AutoMapper)
• Reducing the need to update hundreds of DTOs with explicit nullable annotations (?) If not, is there a recommended migration strategy from AutoMapper to Mapperly for large existing ABP applications that relied on AutoMapper’s implicit null-handling behavior?

I didn't find this fix in the ABP documentation anywhere. Could you please share the documentation here so that I can have a look. Thanks!

It worked, thanks!

Hi, I've shared the application code for one of the module with you. Please have a look. It's a production app, not a test app, so I cannot share the whole source code with you. Thanks!

I can give you the remote access of my system, let me know when you're comfortable to connect Thanks!

Yes, it's already configured

[DependsOn(
    typeof(IseCoreDomainModule),
    typeof(IseCoreApplicationContractsModule),
    typeof(AbpDddApplicationModule),
    typeof(AbpMapperlyModule)
    )]
public class IseCoreApplicationModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.AddMapperlyObjectMapper<IseCoreApplicationModule>();
    }
}

Trying to do: var filter = ObjectMapper.Map<HrMissionaryLookupRequestDto, HrMissionaryLookupFilter>(input); but getting error.

Here is the configuration for mapperly in file IseCoreApplicationMappers.cs

[Mapper]
public partial class HrMissionaryLookupRequestDtoToHrMissionaryLookupFilterMapper
    : MapperBase<HrMissionaryLookupRequestDto, HrMissionaryLookupFilter>
{
    public override partial HrMissionaryLookupFilter Map(HrMissionaryLookupRequestDto source);

    public override partial void Map(
        HrMissionaryLookupRequestDto source,
        HrMissionaryLookupFilter destination
    );
}

Issue: AutoMapperMappingException after migrating from AutoMapper to Mapperly in ABP (.NET 9 → .NET 10)

Exception message and stack trace

AutoMapper.AutoMapperMappingException
HResult=0x80131500
Message=Missing type map configuration or unsupported mapping.
Source=AutoMapper
StackTrace: <Cannot evaluate the exception stack trace>

Steps to reproduce

1. I upgraded an existing ABP.io project from .NET 9 to .NET 10.
2. As part of the upgrade, ABP is moving from AutoMapper to Mapperly.
3. I followed the official migration documentation:
   • https://abp.io/docs/10.0/release-info/migration-guides/AutoMapper-To-Mapperly
   • https://abp.io/docs/latest/framework/infrastructure/object-to-object-mapping
4. I converted all AutoMapper profiles to Mapperly mappers as per the documentation.

Observed behavior

• When I use ObjectMapper.Map<TSource, TDestination>(), I get the AutoMapperMappingException shown above.
• However, when I inject the generated Mapperly mapper directly into the consuming class and use it, the mapping works correctly.

Expected behavior

• I would like to continue using ObjectMapper.Map (ABP’s abstraction) instead of injecting individual Mapperly mapper classes everywhere.

Question

• How can I correctly configure or register Mapperly mappers so that ObjectMapper.Map works as expected in ABP?
• Is there any additional setup required to make ObjectMapper resolve Mapperly-based mappers instead of falling back to AutoMapper?