Minicon.CodeMapper 0.2.2

Minicon.CodeMapper

Schlanker Objekt-zu-Objekt-Mapper für .NET auf Basis eines Source Generators – als Ablösung für AutoMapper. Die vertraute Profile / CreateMap-DSL bleibt erhalten, die Mappings werden jedoch zur Compile-Zeit als statischer, reflection-freier Code erzeugt.

• ⚡ Schnell – keine Reflection im heißen Pfad, nur direkte Zuweisungen und Delegate-Lookups
• 🧩 Vertraute API – Profile, CreateMap<,>(), ForMember, MapFrom, Ignore, ReverseMap
• 🔍 Compile-Zeit-Diagnostics – nicht zuordenbare Ziel-Member werden direkt im Build gemeldet
• 🪶 Trimming-/AOT-freundlich – der generierte Mapping-Code ist vollständig statisch
• 🆓 MIT-Lizenz – keine kommerzielle Lizenzpflicht

Status: v0.1 – die Kern-Features stehen und sind getestet. Siehe Roadmap.

Installation

Projektreferenz (während der Entwicklung):

<ProjectReference Include="path/to/src/Minicon.CodeMapper/Minicon.CodeMapper.csproj" />

Der zugehörige Source Generator ist im Paket enthalten und wird automatisch aktiv.

Schnellstart

1. Profile definieren – exakt wie gewohnt:

using Minicon.CodeMapper;

public class PersonProfile : Profile
{
    public PersonProfile()
    {
        CreateMap<Address, AddressDto>().ReverseMap();
        CreateMap<Order, OrderDto>();
        CreateMap<Person, PersonDto>()
            .ForMember(d => d.FullName, o => o.MapFrom(s => s.FirstName + " " + s.LastName))
            .ForMember(d => d.Secret,   o => o.Ignore());
    }
}

2. Registrieren (Microsoft.Extensions.DependencyInjection):

services.AddCodeMapper(typeof(PersonProfile).Assembly);

3. Mappen:

public class PersonService(IMapper mapper)
{
    public PersonDto ToDto(Person p) => mapper.Map<PersonDto>(p);
    public List<PersonDto> ToDtos(IEnumerable<Person> people) => mapper.Map<List<PersonDto>>(people);
}

Ohne DI geht es auch statisch über Mapper.Instance:

var dto = Mapper.Instance.Map<PersonDto>(person);

Unterstützte Features (v0.1)

Konstruktoren

Hat der Zieltyp einen zugänglichen parameterlosen Konstruktor, wird wie gewohnt new Dest { ... } erzeugt. Andernfalls wählt der Generator den Konstruktor mit den meisten Parametern, die sich vollständig aus der Quelle befüllen lassen – Parameternamen werden dabei case-insensitiv gegen Quell-Member und ForMember-Konfigurationen aufgelöst, optionale Parameter dürfen offenbleiben:

public class Process
{
    public Process(string name, int priority = 5) { Name = name; Priority = priority; }
    public string Name { get; }
    public int Priority { get; }
    public List<ProcessParameter> Parameters { get; set; } = new();
}

// generiert:
var dest = new Process(name: source.Name, priority: source.Priority)
{
    Parameters = mapper.Map<List<ProcessParameter>>(source.Parameters),
};

Bereits per Konstruktor befüllte Member werden im Objekt-Initializer nicht erneut gesetzt.

Passt kein Konstruktor – etwa weil die Parameter aus verschachtelten Quellen stammen –, gibt ConstructUsing die Erzeugung vor. Anders als ConvertUsing ersetzt es nur die Konstruktion; alle übrigen Member werden danach weiterhin automatisch gemappt:

CreateMap<ProcessEntity, string>()
    .ConstructUsing(e => e.Name);

CreateMap<ProcessParameterEntity, ProcessParameter>()
    .ConstructUsing(e => new ProcessParameter(
        e.Process.Name,
        e.Name,
        e.Value,
        Enum.Parse<ParameterSourceType>(e.ParameterSource.Name, true)));

init-only Properties lassen sich nach ConstructUsing nicht mehr setzen und gehören deshalb in den Konstruktor-Ausdruck.

Enums

Enum-Werte werden ohne zusätzliche Konfiguration konvertiert – sowohl für Member als auch für Konstruktor-Parameter:

Nullable-Quellen auf nicht-nullable Ziele laufen wie bisher über GetValueOrDefault() (int? → TEnum ergibt bei null also den Enum-Wert 0). Benutzerdefinierte explicit operator-Konvertierungen werden ebenfalls genutzt.

Diagnosen

Migration von AutoMapper

In den meisten Fällen genügt das Ersetzen des Namespaces und der DI-Methode:

Wie es funktioniert

1. Der Source Generator findet alle Profile-Subklassen und liest deren CreateMap/ForMember-Deklarationen aus dem Syntaxbaum.
2. Pro Typ-Paar wird eine statische Methode erzeugt (new TDest { ... } mit direkten Zuweisungen).
3. Alle Methoden werden per [ModuleInitializer] in der MapperRegistry registriert – ganz ohne Assembly-Scan zur Laufzeit.
4. IMapper.Map<T>() ist nur noch ein Dictionary-Lookup auf den passenden Delegate.

Auszug aus generiertem Code:

internal static PersonDto Map_3(Person source, IMapper mapper)
{
    if (source is null) return default!;
    return new PersonDto
    {
        Id        = source.Id,
        FullName  = ((Func<Person, string>)(s => s.FirstName + " " + s.LastName))(source),
        LuckyNumber = source.LuckyNumber.GetValueOrDefault(),
        HomeAddress = mapper.Map<AddressDto>(source.HomeAddress),
        Orders      = mapper.Map<List<OrderDto>>(source.Orders),
        // Secret wird ignoriert
    };
}

Trimming & AOT

Der generierte Mapping-Code ist vollständig statisch typisiert und reflection-frei. Einzige Ausnahme ist ein Komfort-Fallback in Mapper für Top-Level-Collection-Aufrufe wie Map<List<T>>(...), der minimale Reflection nutzt (sauber annotiert). Für NativeAOT empfiehlt es sich, registrierte Element-Mappings direkt zu verwenden; die automatische Generierung dedizierter Collection-Maps ist auf der Roadmap.

Roadmap

• Inline-Codegen für Collections (vollständige AOT-Reinheit ohne Reflection-Fallback)
• BeforeMap / AfterMap im Codegen
• Condition, NullSubstitute, ValueResolver
• Flattening (Order.Customer.Name → OrderDto.CustomerName)
• NuGet-Veröffentlichung
• Drop-in-Kompatibilitätspaket (Namespace-Alias AutoMapper)

Build & Test

dotnet build
dotnet test

Lizenz

MIT © Michael Nikolaus