Letzten Herbst saß ich in einem Audit bei einem Maschinenbauer, 180 Mitarbeitende, Standort Süddeutschland. Die hatten ein .NET-Backend, das Sensor-Daten von der Shopfloor-Ebene entgegennahm — alles in C#, alles selbst gebaut von einem Team aus damals zwei, inzwischen drei Entwicklern. Irgendwo tief in der Codebase steckte ein unsafe-Block, den keiner mehr anfassen wollte. Nicht weil er kaputt war. Sondern weil keiner mehr wusste, warum er dort war, wer ihn geschrieben hatte und was genau er tat. Der ursprüngliche Entwickler hatte das Unternehmen 2019 verlassen. Der Block war seither unberührt.
Das ist der Normalfall, nicht die Ausnahme.
Was Microsoft ankündigt
Microsoft überarbeitet grundlegend, wie C# mit dem unsafe-Keyword umgeht. Bisher markierte unsafe hauptsächlich Pointer-Syntax — du sagst dem Compiler: "Ich weiß, was ich tue, lass mich durch." Mit C# 16 wird daraus ein echter Vertrag: Wer unsicheren Code aufruft, übernimmt explizit Verantwortung. Diese Verantwortung propagiert durch den Call-Graph, ist im Code sichtbar, reviewbar und wird vom Compiler durchgesetzt. Auch Bibliotheken wie System.Runtime.CompilerServices.Unsafe und System.Runtime.InteropServices.Marshal werden rückwirkend mit diesen Markierungen versehen. Das Feature kommt als Preview in .NET 11 und soll in .NET 12 produktionsreif sein — opt-in zunächst, ähnlich wie damals Nullable Reference Types.
Die Analogie, die Microsoft selbst benutzt, ist gut: Fahrbahnmarkierungen versus Leitplanken. Bisheriges unsafe war die gelbe Linie auf der Straße — eine Konvention, die auf Compliance durch den Fahrer setzt. Das neue Modell baut die Leitplanke.
Wie das im KMU wirklich landet
Lass mich direkt sein: Für 80 Prozent der .NET-KMU-Teams, die ich kenne, ändert sich operativ erst mal wenig. Die meisten schreiben kein unsafe — sie nutzen Entity Framework, ASP.NET Core, vielleicht noch ein paar NuGet-Pakete für Excel-Export oder PDF-Generierung. Kein Pointer-Arithmetik, keine nativen Interop-Aufrufe. Diese Teams werden beim Upgrade auf .NET 12 eine neue Compiler-Option sehen, aktivieren, und feststellen: alles grün, nichts zu tun.
Aber es gibt eine Minderheit von Teams, für die das massiv relevant ist — und die merken das erst, wenn es zu spät ist. Ich spreche von:
Industrienahe Softwareentwicklung. Maschinenbauer, Automobilzulieferer, Anlagenbauer. Die haben häufig Interop-Schichten zu nativen Bibliotheken — SPS-Treiber, Kameraframeworks, proprietäre Hardware-SDKs. Dort lebt unsafe-Code. Oft geschrieben von jemandem, der die Hardware kannte, aber C# eher als Hilfsmittel sah. Der ist inzwischen Rentner oder beim Wettbewerber.
Legacy-Performance-Code. Unternehmen, die vor fünf oder acht Jahren auf Hochleistungs-Datenverarbeitung optimiert haben, als Span<T> und Memory<T> noch nicht existierten oder noch zu jung für den Produktionseinsatz waren. Die haben unsafe-Blöcke für Buffer-Manipulation, Serialisierung oder Bitmask-Operationen. Manches davon könnte man heute sauber mit modernen APIs lösen. Aber "könnte man" ist keine Roadmap.
KI-generierter Code — das unterschätzte Risiko. Microsoft erwähnt das selbst kurz, und ich bin froh, dass sie es tun: Wenn Code-Generierung schneller skaliert als Human Review, wird Safety-Enforcement am Compiler-Level zur Notwendigkeit. Ich sehe in Mandaten zunehmend, dass Entwickler Teile der Codebase per LLM generieren — manchmal ohne genaues Verständnis, was der generierte Code eigentlich macht. Wenn ein Sprachmodell einen unsafe-Block generiert und der Entwickler das nicht versteht, ist das neue Modell tatsächlich eine wichtige Schutzschicht. Der Compiler zwingt zur Auseinandersetzung.
Was im Artikel fehlt
Ich respektiere die technische Tiefe des Original-Beitrags. Aber er ist aus der Perspektive eines Platform-Teams geschrieben, das Dutzende Entwickler hat, Code-Review als selbstverständlich voraussetzt und annehmen darf, dass jemand den Migrationspfad für bestehende unsafe-Bibliotheken strukturiert begleitet.
Im KMU mit drei .NET-Entwicklern ist das anders. Konkret drei Lücken:
1. Migrations-Aufwand bestehender Codebase. Was passiert mit Legacy-Code, der heute unsafe-Markierungen nutzt, wenn ich das neue Modell aktiviere? Microsoft sagt "opt-in" — aber irgendwann kommt der Punkt, wo neue Tooling-Versionen, neue Libraries oder neue Team-Mitglieder das neue Modell als Standard erwarten. Der Artikel beschreibt die Zielarchitektur sehr präzise, sagt aber wenig darüber, wie der Weg von einer 8 Jahre alten Codebase mit 40 unsafe-Stellen dorthin aussieht. Aus Beratungssicht: Das ist die eigentliche Arbeit.
2. Wer reviewt die unsafe-Boundaries? Das neue Modell macht Safety-Contracts sichtbar und reviewbar. Gut. Aber reviewbar heißt nicht automatisch: reviewed. Wenn niemand im Team versteht, was ein unsafe-Block mit nativen Speicheradressen tut, hilft die Annotation wenig. Das ist kein Vorwurf an Microsoft — das ist eine Personalfrage. Aber sie sollte laut ausgesprochen werden.
3. Supply-Chain ohne eigene Kontrolle. Microsoft nennt Supply-Chain-Sicherheit explizit als Motivation. Richtig. Aber ein KMU kontrolliert seine Supply Chain nur bedingt — die meisten unsafe-Abhängigkeiten kommen aus NuGet-Paketen, die von Drittanbietern gepflegt werden. Ob und wann die ihre Pakete mit C#-16-konformen Annotationen versehen, liegt nicht in deiner Hand. Das neue Modell hilft hier langfristig, aber es gibt eine Übergangsphase, in der du auf viele gemischte Signale stoßen wirst.
Meine konkrete Empfehlung
Für die meisten KMU-Teams gilt: Kein Handlungsbedarf heute. Beobachten, nicht hechten. Das Feature ist als Preview in .NET 11 angekündigt, Produktionsreife in .NET 12. Du hast Zeit.
Was ich dennoch empfehle — und zwar jetzt, nicht in zwei Jahren:
Mach eine unsafe-Inventur deiner bestehenden Codebase. grep -rn "unsafe" reicht als Einstieg. Wie viele Stellen? Wer hat sie geschrieben? Gibt es einen aktuellen Entwickler, der sie erklären kann? Das Ergebnis dieser 30-Minuten-Übung sagt dir mehr über dein tatsächliches Risiko als jeder Blogpost.
Wenn du in der industrienahen Entwicklung arbeitest und Interop-Schichten zu nativer Hardware hast: Dieses Feature ist für dich gebaut. Es lohnt sich, es ernsthaft in die mittelfristige Roadmap aufzunehmen — nicht als Nice-to-have, sondern als technische Schuld, die durch das neue Modell sichtbarer und damit adressierbarer wird.
Und wenn du gerade dabei bist, eine neue .NET-Anwendung zu bauen: Warte mit unsafe so lange wie möglich. Nicht weil es falsch ist — sondern weil du in zwei Jahren die besseren Werkzeuge dafür haben wirst.
Der vollständige Original-Beitrag von .NET Blog (MS): Improving C# Memory Safety
Wenn du wissen willst, wo unsafe-Code in deiner Codebase tatsächlich zum Risiko wird — oder einfach einen Klartext-Check zu deiner .NET-Strategie brauchst:
— Bernhard