Syntrony.Mapping 1.1.0

Syntrony.Mapping

Object-to-object mapping contracts for the Syntrony framework — the attributes and interfaces, with zero mapping engine behind them.

This package only declares the surface: IObjectMapper, the [AutoMapFrom]/[AutoMapTo]/[AutoMap]/[IgnoreMap] attributes, and the fluent configuration contracts (IMapperConfigurationExpression, IMappingExpression<,>, IMemberConfigurationExpression<,,>). It has no dependency on AutoMapper, EF Core, or ASP.NET Core — it can be referenced from a console app, a worker, or a class library with no runtime cost.

To actually map anything, install an engine package alongside it:

Why the split

AutoMapper went commercial on 2 de julio de 2025 (Lucky Penny Software). Rather than depend on it directly, Syntrony.Mapping defines its own contracts under its own names, and a separate adapter package implements them on top of whichever engine is installed. Changing the engine later means swapping the installed package, not rewriting call sites. The public contracts here never expose a single AutoMapper type — verified by building Syntrony.Mapping with zero reference to the AutoMapper NuGet package.

Migration rule

If you're moving a mapping file from AutoMapper or Abp.AutoMapper, the goal is that the only line that changes is the using:

- using AutoMapper;
+ using Syntrony.Mapping;

internal static class DtoMappings
{
    public static void Map(IMapperConfigurationExpression mapper)   // signature unchanged
    {
        mapper.CreateMap<CreateAppInput, OpeApplication>()
            .ForMember(d => d.ClientId, opt => opt.MapFrom(s => Guid.NewGuid()));
    }
}

Every public type here keeps the exact name it has in AutoMapper or in Abp.AutoMapper — that's a design constraint, not a coincidence.

Supported subset (v1)

[IgnoreMap] is applied on whichever side the property is declared: as a destination member it excludes the member from both the mapping and MemberList.Destination validation; as a source member it excludes it from MemberList.Source validation. It works the same for pairs declared by attribute and for fluent pairs. An explicit ForMember on the same member wins — what's written by hand overrides what's inherited from the attribute. ReverseMap() does not propagate the exclusion — the reverse map is a different pair.

Known limitation: a pair is either attribute-declared or fluent-declared, not both

[AutoMapFrom]/[AutoMapTo]/[AutoMap] and a fluent CreateMap<TSource,TDestination>() for the same type pair don't compose — the AutoMapper v1 engine treats that as a duplicate map registration and fails at startup with a clear error naming both types. If a pair needs a ForMember override, configure that whole pair fluently and don't also decorate it with an attribute. This is a real constraint of delegating to AutoMapper (not a bug we chose not to fix — see Syntrony.Mapping.AutoMapper's test suite for the exact scenario), and would need re-verifying if the engine ever changes.

Credit

The public API here is deliberately shaped after ASP.NET Boilerplate (MIT), which this package replaces:

• IObjectMapper mirrors Abp.ObjectMapping.IObjectMapper and Abp.AutoMapper.AutoMapperObjectMapper (src/Abp.AutoMapper/AutoMapper/AutoMapperObjectMapper.cs) — same three members, same names.
• AutoMapFromAttribute, AutoMapToAttribute, AutoMapAttribute and their MemberList parameter mirror src/Abp.AutoMapper/AutoMapper/AutoMapFromAttribute.cs, AutoMapToAttribute.cs and AutoMapAttribute.cs — same constructors, same MemberList defaults per direction (AutoMapFrom → Destination, AutoMapTo → Source).
• The attribute-to-pair resolution in Syntrony.Mapping.AutoMapper's AttributeMappingScanner reproduces the algorithm in AutoMapAttributeBase.CreateMap and AbpAutoMapperModule.FindAndAutoMapTypes (src/Abp.AutoMapper/AutoMapper/AbpAutoMapperModule.cs), including which side of a pair gets MemberList.Source vs MemberList.Destination.

None of ASP.NET Boilerplate's source is copied verbatim — the contracts here are independent types with no dependency on ABP or on AutoMapper — but the shape, names and defaults are intentionally identical so that migrating a project already using Abp.AutoMapper costs a using line, not a rewrite.