mapster tool generates non-public interface method/property implementation

[zaigr]

When generating mapper from interface containing mapping method/property with internal classes mapster tool generates internal implementation of this method/property

• Mapster.Core v1.2.0
• mapster.tool v8.2.1
• executed on net5

[Mapper(IsInternal = true)]
internal interface IMyMappers
{
    PocoDto Map(Poco source);

    Expression<Func<Poco, PocoDto>> ProjectToDto { get; }
}

public record Poco(string Name, string Description);

internal record PocoDto(string Name, string Description);

Generated mapper class is:

internal partial class MyMappers : IMyMappers
{
    internal Expression<Func<Poco, PocoDto>> ProjectToDto => p1 => new PocoDto(p1.Name, p1.Description);
    internal PocoDto Map(Poco p2)
    {
        return p2 == null ? null : new PocoDto(p2.Name, p2.Description);
    }
}

CS0737: 'MyMappers.Map(Poco)' cannot implement an interface member because it is not public.
CS0737: 'MyMappers.ProjectToDto' cannot implement an interface member because it is not public.

Maybe internal class with proper implementations should be generated even in case MapperAttribute.IsInternal hasn't been specified

[andrerav]

@zaigr After looking at the code I suspect that this is a shortcoming in the ExpressionTranslator library. It seems like it would be an easy fix though (take a look at line 1179-1181 and 1210-1212).

[ueeckwil]

Any movement on this? Our team is looking to migrate from AutoMapper, but the source classes are internal, so I am looking to ease transition and boilerplate with this approach.

Additional context, the entire point of these mappers is because the project is encapsulating data entities (EF models) from the core Domain models. There are many SQL tables that are overly flattened or less than ideal shapes, but we are exposing them via OData for flexible UI filtering.

Currently the workaround I'm proposing for us is some kind of adapter which is pretty clunky IMO

delegate T GeneratedMap<TSource, T>(TSource source) where TSource : class where T : class;

internal record MapsterCodeGenAdapter<TSource, TDestination>
(
    Expression<Func<TSource, TDestination>> Projection,
    GeneratedMap<TSource, TDestination>? Mapper,
    GeneratedMap<TDestination, TSource>? ReverseMapper
)
: IEntityMapper<TSource, TDestination>
    where TSource : class
    where TDestination : class
{
    public IQueryable<TDestination> Project(IQueryable<TSource> source) => source.Select(Projection);
    public TDestination Map(TSource entity) => Mapper?.Invoke(entity) ?? throw new NotSupportedException($"MapsterCodeGenAdapter<{typeof(TSource).Name},{typeof(TDestination).Name}> has no generated Mapper delegate.");
    public TSource ReverseMap(TDestination entity) => ReverseMapper?.Invoke(entity) ?? throw new NotSupportedException($"MapsterCodeGenAdapter<{typeof(TSource).Name},{typeof(TDestination).Name}> has no generated ReverseMapper delegate.");
}

Mapster.Core v10.0.11
mapster.tool v10.0.11
executed on net8.0 (and net10.0)

[DocSvartz]

If I understand correctly, the main problem is the following:

1. All interface members are public by default.
2. The implementation must either be public, or declareted members must be implemented as members of the interface itself, not the class member

 internal class SrcRequest
 {
     public string Data { get; set; }
 }

 internal interface IRequest 
 {
     string ModData { get; set; }
     SrcRequest Data { get; set; }
 }

// if you need to keep the internal access level
 internal class Impl : IRequest
{
    string IRequest.ModData { get ; set ; }
    SrcRequest IRequest.Data { get ; set ; }
}
 
// or it if need only implementation  

internal class Impl : IRequest
{
    public string ModData { get ; set ; }
    public SrcRequest Data { get ; set ; }
}

[DocSvartz]

@andrerav @stagep
If a mapper is always used through an interface, then generating members of the class itself is actually not required. 🤔

But if a mapper is used as a standalone class, then something like this should be generated:

 internal interface IRequest 
 {
     string ModData { get; set; }
     SrcRequest Data { get; set; }
     SrcRequest Map(string value);
 }

 internal class Impl : IRequest
 {
     internal string ModData { get => (this as IRequest).ModData; set => (this as IRequest).ModData = value; }
     internal SrcRequest Data { get => (this as IRequest).Data; set => (this as IRequest).Data = value; }
     internal SrcRequest Map (string value)
     {
        return (this as IRequest).Map(value);
     }
     string IRequest.ModData { get ; set ; }
     SrcRequest IRequest.Data { get ; set ; }
     SrcRequest IRequest.Map(string value)
     {
         // ... 
     }
 }

Or always generate its as public if that works 😅

[ueeckwil]

If I understand correctly, the main problem is the following:

1. All interface members are public by default.
2. The implementation must either be public, or declareted members must be implemented as members of the interface itself, not the class member

 internal class SrcRequest
 {
     public string Data { get; set; }
 }

 internal interface IRequest 
 {
     string ModData { get; set; }
     SrcRequest Data { get; set; }
 }

// if you need to keep the internal access level
 internal class Impl : IRequest
{
    string IRequest.ModData { get ; set ; }
    SrcRequest IRequest.Data { get ; set ; }
}
 
// or it if need only implementation  

internal class Impl : IRequest
{
    public string ModData { get ; set ; }
    public SrcRequest Data { get ; set ; }
}

@DocSvartz correct. I have a public interface, but for this project, I have internal DTOs. Therefore the implementation must be internal, but the compiler expects one or the other, internal modifiers on the implementing properties/methods are not allowed.

Reasoning: manually registering generated extension methods is tedious at scale, and a manual step in an otherwise well-design library that does most of the work for us.

Goal: generated code is DI friendly allowing for abstractions.

public interface IEntityMapper<TSource, TDestination>
    where TSource : class
    where TDestination : class
{
    Expression<Func<TSource, TDestination>> Projection;
    TDestination Map(TSource dataEntity);
    TSource ReverseMap(TDestination entity);
}

[Mapper(IsInternal = true)]
internal interface IMyTypeMapper : IEntityMapper<MyTypeSource, MyType>
{ }

//yields with compile errors
internal class MyTypeMapper : IMyTypeMapper
{
    internal Expression<Func<MyTypeSource, MyType>> Projection;
    internal MyType Map(MyTypeSource dataEntity);
    internal MyTypeSource ReverseMap(MyType entity);
}

Another workaround or solution would be more extensibility in the .GenerateMapper(...) method?

[DocSvartz]

Another workaround or solution would be more extensibility in the .GenerateMapper(...) method?

@ueeckwil I don't think this generator should be doing registration in DI. At a minimum, this will create a dependency relationship between the resulting code and a specific dependency container, which may not be used.

@andrerav @stagep What do you think about this?

The only thing can do is add a specific attribute to the mapper to make it easier to find these classes when building DI container.

[MapsterToolGeneratedMapper] //  create this 
internal partial class CustomerMapper : IMyTypeMapper
{
    public AddressDTO Map(Address p1) {};
    AddressDTO TemplateTest.IMyTypeMapper.Map(Address p1) {};
    public Expression<Func<AddressDTO, Address>> Projection => p2 => new Address() {};
    Expression<Func<AddressDTO, Address>> TemplateTest.IMyTypeMapper.Projection => p2 => new Address(){};
}

[andrerav]

@DocSvartz Agree about not coupling the generator to DI. A marker attribute might be useful independently, but I don't think it's necessary to solve this issue. For an internal generated mapper the interface implementations can simply be public. Their effective accessibility is still limited by the internal containing class. We shouldn't need explicit interface implementations or duplicate members. I think my original suggestion from 2022 is still a valid way to fix this. Let me give that a try and see if that will be sufficient.

[DocSvartz]

@andrerav I also took a quick look at what's going on. And I think the dual-implementation solution actually solves all possible use cases for such cases.
Except for the violation of the DRY principle. 😆

When TypeDefinitions install IsInternal = false, create not valid mapper

internal interface IMyTypeMapper
{
     AddressDTO Map(Address p1);
     Expression<Func<AddressDTO, Address>> Projection { get; }
}

ps. This solution is already ready.

[DocSvartz]

I also noticed that mappers are not being created for the following interfaces:

internal interface IMyTypeMapper
{
     internal AddressDTO Map(Address p1);
     internal Expression<Func<AddressDTO, Address>> Projection { get; }
}

public interface IMyTypeMapper
{
     internal AddressDTO Map(Address p1);
     internal Expression<Func<AddressDTO, Address>> Projection { get; }
}

Although apparently this is valid form of interface.