Letzten Monat saß ich bei einem Maschinenbauer mit 85 Mitarbeitenden. Die haben intern eine .NET-Warenwirtschaft, gebaut von einer Zwei-Mann-Agentur vor sieben Jahren. AutoMapper steckt tief drin — DTOs, ViewModels, EntityMappings. Der externe Entwickler, der heute noch die Wartung macht, hat mir offen gesagt: „Ich weiß ehrlich gesagt nicht mehr, welche Version wir haben. Läuft ja."
Das ist der Normalzustand in KMU-Projekten mit .NET-Altlasten. Kein Lizenzmanagement, kein SBOM, kein strukturiertes Dependency-Tracking. Läuft ja. Bis es nicht mehr läuft — oder bis ein Auftraggeber bei einer Lieferantenbewertung nach einem Software-Bill-of-Materials fragt und du drei Tage Krisenmanagement hast.
Was Jimmy Bogard veröffentlicht hat
Jimmy Bogard — Autor von AutoMapper und MediatR, zwei der meistgenutzten .NET-Bibliotheken überhaupt — hat diese Woche die Versionen 16.2.0 bzw. 14.2.0 veröffentlicht. Der Fokus dieses Releases ist ungewohnt explizit enterprise-orientiert: Lizenzschlüssel lassen sich jetzt sauber über Umgebungsvariablen setzen, Threading-Probleme bei der Lizenzvalidierung wurden behoben, und beide Pakete liefern jetzt SBOMs (Software Bill of Materials) als Teil der Releases mit.
Bogard schreibt selbst, dass die letzten Releases primär auf Anforderungen von Enterprise-Kunden zielten, die kommerzielle Pakete konsumieren. Das nächste Release soll sich wieder mehr auf Features und historische Bugs konzentrieren. Fairer, klarer Stand — kein Marketing, keine Übertreibung.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper 16.2.0 and MediatR 14.2.0 Released
Wie das im Mittelstand wirklich landet
Lass mich das in drei Schichten aufdröseln.
Schicht 1: Die Lizenzschlüssel-Thematik
AutoMapper und MediatR sind seit Version 13 bzw. 12 kommerziell lizenziert — für kommerzielle Nutzung zahlst du. Das ist Bogards gutes Recht, und die Preise sind fair. Was aber in KMUs regelmäßig passiert: der ursprüngliche Entwickler hat das Projekt aufgesetzt, die Lizenz läuft auf seiner E-Mail-Adresse, und drei Jahre später ist er weg. Oder das Projekt ist intern gewachsen, und niemand weiß mehr, ob die Lizenz noch gültig ist.
Die neue Möglichkeit, Lizenzschlüssel über Umgebungsvariablen zu setzen (AUTOMAPPER_LICENSE_KEY, MEDIATR_LICENSE_KEY oder wie auch immer das konkret heißt), ist für Deployment-Pipelines und containerisierte Anwendungen ein echter Schritt vorwärts. Du hardcodest keinen Schlüssel ins Repository, kannst ihn in deinem CI/CD-Secret-Store ablegen, und verschiedene Umgebungen (Staging, Prod) können sauber getrennt werden.
Für den Maschinenbauer aus meinem Eingangsbeispiel bedeutet das konkret: wenn sie irgendwann migrieren oder upgraden, sollten sie das neue Muster sofort nutzen. Lizenzschlüssel in appsettings.json oder — schlimmer — direkt im Code committet sind ein Sicherheits- und Compliance-Problem. Nicht dramatisch, aber vermeidbar.
Schicht 2: SBOMs — brauchst du das wirklich?
Ein SBOM ist eine maschinenlesbare Liste aller Softwarekomponenten in deinem Produkt, inklusive Versionen und Lizenzen. Im Enterprise-Kontext, vor allem bei Software die an Konzerne oder öffentliche Auftraggeber geliefert wird, wird das zunehmend verlangt. Die EU-Cyber-Resilience-Act-Anforderungen drücken in diese Richtung.
Für das typische KMU mit interner Eigenentwicklung, das keine Software verkauft? Noch nicht akut. Aber: Wenn du Software entwickelst, die du an Kunden lieferst — Stichwort ISV, Independent Software Vendor — dann solltest du wissen, dass deine Kunden in zwei bis drei Jahren danach fragen werden. Wer jetzt schon weiß, was in seinen Paketen steckt, ist dann nicht in Erklärungsnot.
Die praktische Frage ist: reicht es, dass AutoMapper und MediatR selbst SBOMs mitliefern, oder brauchst du ein Tool wie dotnet-sbom oder CycloneDX, das den gesamten Dependency-Graph deiner Anwendung abbildet? Antwort: für echte Compliance-Anforderungen brauchst du das vollständige Bild, nicht nur die SBOM einzelner Pakete. Aber es ist ein Schritt.
Schicht 3: Was Bogard nicht schreibt, weil es für Enterprise selbstverständlich ist
Hier liegt mein eigentlicher Punkt. Der Artikel richtet sich an Teams, die professionelles Dependency-Management schon betreiben. Die haben einen Artifact-Feed (Azure DevOps, Nexus, Artifactory), die haben automatisierte Vulnerability-Scans, die wissen welche Versionen sie im Einsatz haben.
Im Mittelstand — ich rede von 30 bis 300 Mitarbeitenden, intern entwickelte Software, kleines Entwicklerteam oder Einzelkämpfer — ist die Realität oft: packages.config mit händisch eingetragenen Versionen, keine automatisierten Updates, kein systematisches CVE-Monitoring. In diesem Kontext ist der Sprung zu „nutze Umgebungsvariablen für Lizenzschlüssel" zwar richtig, aber er setzt Infrastruktur voraus, die noch nicht da ist.
Was ich in solchen Mandaten empfehle: zuerst einmal sauber inventarisieren. dotnet list package --outdated gibt dir in zehn Sekunden einen Überblick. Dann entscheiden, ob Dependabot (GitHub) oder Renovate Bot automatische Update-PRs stellen soll. Das ist die Grundlage, auf der alles andere — Lizenzmanagement, SBOMs, Compliance — aufbaut.
Meine konkrete Einschätzung
Wenn du aktiv .NET-Projekte mit AutoMapper oder MediatR betreibst oder weiterentwickelst:
- Upgrade auf die aktuellen Versionen — nicht wegen der Enterprise-Features, sondern weil die Threading-Fixes real sind und alte Versionen in lizenzpflichtigen Bereichen irgendwann zu Problemen führen.
- Lizenzschlüssel sofort aus dem Code raus und in Umgebungsvariablen oder deinen Secret-Store. Das ist unabhängig vom Release sinnvoll, aber jetzt gibt es keine Ausrede mehr.
- SBOM-Anforderungen erstmal beobachten, nicht hektisch handeln — außer du lieferst Software an Konzerne oder öffentliche Stellen, dann jetzt anfangen.
- Den Artikel lesen — Bogard ist präzise, kein Blabla. Auch wenn das konkrete Release für dich operativ nichts ändert, zeigt die Richtung, wohin sich kommerzielle Open-Source-Pakete entwickeln: mehr Compliance, mehr Audit-Trail, mehr Verantwortung auf der Nutzerseite.
Was ich nach wie vor vermisse — und das ist kein Vorwurf an Bogard, das ist nicht sein Job — ist eine klare Orientierung für Teams ohne Lizenz-Governance-Prozesse. Die brauchen keinen Artikel über Umgebungsvariablen, die brauchen einen Einstiegspunkt: „Hier fängst du an, wenn du Ordnung in deine Dependencies bringen willst." Das ist Beratungsarbeit, keine Bibliotheksdokumentation.
Du nutzt AutoMapper oder MediatR in einem Projekt, das seit Jahren läuft, und weißt nicht genau, wo ihr steht? Oder du willst wissen, ob ein Upgrade gerade sinnvoll ist oder ob ihr erst Hausaufgaben machen müsst?
→ 30 Min Klartext-Sparring — kein Verkaufsgespräch, ich schau mir die Situation an und sage dir, was ich wirklich denke.
— Bernhard