Letzte Woche saß ich bei einem Kunden — Maschinenbauer, 180 Mitarbeitende, eigenes ERP-Umsystem in .NET. Der Lead-Dev zeigte mir stolz, dass sie endlich auf .NET 8 migriert hatten. Erschienen ist das Projekt vor fünf Jahren auf .NET Framework 4.7.2. Ich habe nicht gefragt, wann sie .NET 10 planen. Die Antwort wäre unbequem gewesen.
Das ist keine Kritik. Das ist die Realität, in der die meisten deutschen KMU-Dev-Teams arbeiten. Und genau deshalb lohnt es sich, einen kurzen Blick auf die frische Ankündigung von Jimmy Bogard zu werfen — nicht weil sie dringend ist, sondern weil sie einige Dinge sichtbar macht, über die man in mittelständischen Entwicklungsabteilungen reden sollte.
Was Jimmy Bogard ankündigt
Jimmy Bogard — der Autor beider Libraries — hat AutoMapper 16.0.0 und MediatR 14.0.0 veröffentlicht, beide mit Support für .NET 10. Der eigentliche Inhalt der Release Notes ist überschaubar: keine Breaking Changes gegenüber den vorherigen Minor-Versionen. Das Interessanteste an diesem Release ist struktureller Natur: Bogard richtet den Major-Release-Zyklus künftig an den .NET-Major-Releases aus. Neu und erwähnenswert ist außerdem NuGet Package Signing — die Pakete tragen jetzt eine verifizierte digitale Signatur von Lucky Penny Software, seinem Unternehmen. Das schützt vor Supply-Chain-Angriffen durch Namens-Hijacking. Wer Details will: Bogard beschreibt den Prozess anschaulich, inklusive Selfie mit Reisepass.
Wie das in einem KMU wirklich landet
Lass mich direkt sein: Für die meisten KMU-Dev-Teams ändert dieses Release kurzfristig gar nichts.
Der .NET-10-Support ist irrelevant, solange ihr nicht auf .NET 10 seid. Und die wenigsten mittelständischen Teams sind das. .NET 10 ist seit November 2025 aktuell — ein Non-LTS-Release. Für Teams, die produktive Systeme betreiben und nicht den Luxus eines dedizierten Upgrade-Sprints haben, bleibt .NET 8 (LTS, Support bis November 2026) oder .NET 9 die pragmatische Wahl. .NET 10 selbst ist wieder LTS — aber bis das in einem KMU mit 3-8 Entwicklern im produktiven Code landet, vergehen realistisch 12 bis 24 Monate.
Das Release-Cadence-Alignment ist eine gute Nachricht, wird aber kaum jemanden im Mittelstand elektrisieren. Die eigentliche Botschaft dahinter ist Stabilität: Bogard sagt damit indirekt, dass Major-Version-Bumps nicht mehr aus API-Änderungen entstehen, sondern aus Dependency-Upgrades. Für Teams, die Renovate oder Dependabot nutzen, ist das eine hilfreiche Signale — aber ehrlich gesagt sollte man in einem KMU ohne automatisiertes Dependency-Management zuerst dort ansetzen, bevor man über Library-Versionen nachdenkt.
Package Signing: wichtiger als es klingt, aber niemand schaut hin. Das ist der Punkt, den ich in Beratungsgesprächen immer wieder anspreche. Die NuGet-Supply-Chain ist in kleineren Teams praktisch unüberwacht. Ich habe in Audits schon Pakete gesehen, die seit Jahren nicht mehr vom Original-Publisher stammten — Typosquatting, verwaiste Forks, gespiegelte Pakete aus internen Registries ohne Abgleich. Bogard macht hier das Richtige. Aber der Nutzen materialiert sich nur, wenn die Teams auch tatsächlich die Signatur-Validierung in ihrer CI-Pipeline konfigurieren. Das ist ein Handgriff — aber einer, den in meiner Erfahrung weniger als 20% der KMU-Dev-Teams gemacht haben.
Die eigentliche Frage, die dieser Release aufwirft
AutoMapper und MediatR sind beides Libraries mit einer sehr klaren Zielgruppe: Teams, die komplexe Domänenlogik strukturiert abbilden wollen. Das CQRS-Pattern hinter MediatR ist mächtig. Aber es ist auch eines der meistvermisbrauchten Patterns, die ich in Mittelstands-Codebases sehe.
Konkret: Ich habe in den letzten zwei Jahren vier Projekte gesehen, in denen MediatR eingesetzt wurde — ausschließlich als glorifizierter Service-Locator. Keine echte Trennung von Read- und Write-Modellen, kein sinnvolles Pipeline-Behavior, keine Domain Events. Nur IRequest/IRequestHandler statt einer normalen Service-Klasse. Das ist kein Architekturgewinn, das ist Komplexität ohne Nutzen.
Bei AutoMapper ist es ähnlich: In einem 50-Personen-Unternehmen mit einer Handvoll Entwicklern, die ein internes Tool pflegen, ist AutoMapper oft ein Overhead, der sich nicht rentiert. Ich sehe regelmäßig Projekte, in denen die Mapping-Konfigurationen länger sind als die Business-Logik selbst — weil jemand vor Jahren "das macht man so" gelesen hat.
Das bedeutet nicht, dass die Libraries schlecht sind. Im Gegenteil. Bogard liefert seit Jahren hervorragende, gut gepflegte Arbeit. Aber der Kontext für ihren sinnvollen Einsatz ist ein anderer als der, in dem viele KMU-Teams sich befinden.
Meine konkrete Empfehlung
Drei Szenarien, drei Antworten:
Ihr seid auf .NET 8 oder 9 und nutzt AutoMapper/MediatR bereits: Kein Handlungsbedarf durch dieses Release. Wartet auf .NET 10 LTS, wertet dann den Upgrade-Aufwand. Konfiguriert in der Zwischenzeit Signatur-Validierung in eurer CI — das ist eine Stunde Arbeit und lohnt sich sofort.
Ihr startet ein neues Projekt und überlegt, ob ihr MediatR einsetzen sollt: Stellt euch zuerst die Frage, ob ihr CQRS wirklich braucht. Habt ihr unterschiedliche Read- und Write-Modelle? Braucht ihr Cross-Cutting Concerns wie Logging, Validation oder Retry-Logic an einem zentralen Ort? Wenn ja — MediatR ist eine solide Wahl. Wenn nicht — eine normale Service-Schicht tut es auch.
Ihr habt AutoMapper im Einsatz und die Mappings werden unübersichtlich: Das ist meist ein Symptom, kein Fehler der Library. Entweder die Domäne ist zu komplex für simples Property-Mapping und ihr braucht explizite Fabrik-Methoden — oder ihr mapped zu viel zu früh und zu spät zugleich. Ein Architektur-Gespräch hilft mehr als ein Library-Upgrade.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper 16.0.0 and MediatR 14.0.0 Released with .NET 10 Support
Wenn du wissen willst, ob AutoMapper und MediatR in eurer konkreten Codebasis Sinn ergeben — oder ob sie euch gerade eher bremsen als voranbringen — spar dir die Recherche und setz dich 30 Minuten mit mir hin.
— Bernhard