dotnet/runtime im Querschnitt: CoreCLR, Mono, die Bibliotheken und der Weg zum eigenen Build
.NET ist eine plattformübergreifende Laufzeit für Cloud-, Mobil-, Desktop- und IoT-Apps.
Auf einen Blick
- Was ist das?
- Das zentrale C#-Repository des .NET-Ökosystems enthält Laufzeit, Klassenbibliotheken und den dotnet-Host. Dieser Text ordnet Komponenten, Build-Konfigurationen, Release-Schienen und Beitragswege ein.
- Für wen ist es gedacht?
- dotnet/runtime ist die Codebasis hinter fast jeder .NET-Anwendung: CoreCLR und Mono als Ausführungsengines, die Klassenbibliotheken und der dotnet-Host als Muxer. Anwender installieren Releases über dotnet.microsoft.com und brauchen das Repository nicht; relevant wird es für Bibliotheksautoren, die Dogfood-Builds testen wollen, und für Mitwirkende, die mit build.sh -subset clr+libs starten.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C#, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Laufzeit, Bibliotheken und der dotnet-Host als Muxer
Das Repository dotnet/runtime enthält laut README den Code zum Bauen der .NET-Laufzeit, der Bibliotheken und der Installer für den gemeinsam genutzten Host namens dotnet, für alle unterstützten Plattformen, dazu die Quellen von Laufzeit und Bibliotheken selbst. Die Projektbeschreibung fasst .NET als plattformübergreifende Laufzeit für Cloud-, Mobile-, Desktop- und IoT-Anwendungen zusammen. Die Metadaten zeigen 18.235 Sterne, 5.569 Forks und 7.621 offene Issues; Sprache C#, Lizenz MIT nach License.TXT.
Der Host verdient eine eigene Erwähnung: Das README nennt ihn sometimes known as the muxer, also als Binärstück, das zwischen mehreren installierten .NET-Versionen vermittelt. Issues zu seiner Installation gehören ausdrücklich in dieses Repository, ebenso solche zu Laufzeit und Klassenbibliotheken. Alles andere wird auf die Schwester-Repositories verteilt; die Auswahlseite dafür ist github.com/dotnet/runtime/issues/new/choose.
Zwei Ausführungsengines und eine unterste Bibliothek
Innerhalb der Codebasis gibt es zwei Implementierungen der Laufzeit, beide in C oder C++ geschrieben. CoreCLR ist die umfassende Engine, die aus dem .NET Framework hervorgegangen ist; Mono ist die schlankere Laufzeit, die als Open-Source-Projekt begann, um .NET- und C#-Unterstützung auf Nicht-Windows-Plattformen zu bringen. Darüber liegt System.Private.CoreLib, kurz CoreLib, die unterste verwaltete Bibliothek.
Für das Bauen gilt eine Kopplung: CoreLib muss in derselben Konfiguration wie die jeweilige Laufzeit gebaut werden, während die übrigen Bibliotheken unabhängig davon eine eigene Konfiguration fahren können. Diese Aufteilung erklärt die Subset-Logik des Build-Skripts, die weiter unten folgt, und warum man für reine Bibliotheksarbeit nicht die gesamte Laufzeit bauen muss.
Debug, Checked und Release als Build-Konfigurationen
Die Workflow-Dokumentation in docs/workflow/README.md definiert drei Konfigurationen. Debug-Builds verwenden nicht optimierten Code mit aktivierten Assertions, laufen am langsamsten und bieten die beste Debugging-Erfahrung. Checked-Builds existieren ausschließlich für CoreCLR: optimierter Code bei aktivierten Assertions, also der Kompromiss für Laufzeitarbeit.
Release-Builds nutzen optimierten Code mit deaktivierten Assertions, laufen am schnellsten und eignen sich am besten für Performance-Messungen, machen das Debugging aber durch Compiler-Optimierungen schwer. Ein weiteres Baustellendetail: Der Build behandelt Warnungen als Fehler, eingeschlossen Code-Style-Warnungen. Wer das für einen lokalen Versuch abschalten will, setzt vor dem Build die Umgebungsvariable TreatWarningsAsErrors auf false.
build.sh, Subsets und der Platzbedarf von bis zu 20 GB
Das Haupt-Build-Skript heißt build.sh, auf Windows build.cmd, und liegt im Stammverzeichnis. Es akzeptiert Subsets, um einzelne Komponenten zu bauen: Clr für die vollständige CoreCLR-Laufzeit plus CoreLib, Libs für alle Bibliothekskomponenten ohne Tests, Packs für Shared-Framework-Pakete und Installer, Host für die .NET-Hosts samt Hosting-Bibliotheken und Mono für die Mono-Laufzeit mit ihrem CoreLib. Mehrere Subsets lassen sich mit Pluszeichen verbinden, etwa ./build.sh -subset clr+libs -configuration Release.
Die Größenordnungen sind beträchtlich: Das vollständige Klonen der Historie kostet laut Workflow-Dokumentation rund 400 bis 500 MB Netzwerkübertragung und belegt lokal 1 bis 1,5 GB, ein Build je nach Umfang 10 bis 20 GB für eine einzelne Kombination aus Betriebssystem und Plattform. Gebaut wird aus einem normalen Terminal, ohne sudo oder Administratorrechte. Cross-Compiling ist die Ausnahme, nötig etwa für WebAssembly- und mobile Ziele, die nicht auf sich selbst gebaut werden können; ARM-Builds entstehen auf x64.
Plattformmatrix der Entwickler-Builds
Die Workflow-Dokumentation unterscheidet die Build-Plattform, auf der die Tools laufen, von der Zielplattform der Artefakte. Auf x64 werden Windows, Linux, macOS und FreeBSD als Build-Plattformen unterstützt, x86 nur unter Windows, Arm32 nur unter Linux, Arm64 unter Windows, Linux und macOS. Pro Betriebssystem existiert eine eigene Seite mit den Voraussetzungen.
Die praktische Folge: Nicht jede Zielplattform lässt sich auf sich selbst bauen, und nicht jede Architektur ist für Entwicklung gedacht. Wer etwa für mobile Geräte baut, cross-kompiliert von einem Desktop-Betriebssystem aus. Welche Kombinationen für einen konkreten Zweck brauchbar sind, steht in der Matrix der Workflow-Dokumentation; das Haupt-README selbst geht auf diese Details nicht ein.
Drei Schienen am gleichen Tag: .NET 8, 9 und 10
Die Release-Historie zeigt parallele Wartung: v10.0.11 erschien am 11. August 2026 um 21:42 UTC, v9.0.19 am selben Tag um 21:16 UTC, v8.0.30 um 19:46 UTC. Drei Hauptversionen wurden also innerhalb weniger Stunden mit Patch-Releases versorgt, und der letzte Push des Repositories datiert auf denselben Abend.
Support-Zeiträume und OS-Matrix liegen nicht im README, sondern im Support-Dokument des Repositories dotnet/core unter support.md; die Roadmap dort listet die geplanten Versionen. Für Betreiber bedeutet der Schienenverbund, dass ein Sicherheitspatch üblicherweise gleichzeitig für alle aktiven Versionen erscheint, weshalb Testkapazität für mehrere Schienen eingeplant werden sollte.
Dogfooding, MSRC-Portal und Issue-Zuständigkeit
Wer nächtliche Builds der Laufzeit und Bibliotheken in eigenen Projekten testen will, folgt dem Dokument docs/project/dogfooding.md; der Build- und Test-Workflow ist in docs/workflow/README.md beschrieben, Beitragsarten in CONTRIBUTING.md. Die Issue-Liste führt die Labels help wanted und good first issue als Einstiegspunkte.
Sicherheitslücken werden privat über das MSRC Researcher Portal gemeldet, mit erwarteter Antwort innerhalb von 24 Stunden; Details stehen in SECURITY.md und im Security TechCenter, Belohnungen regelt das Microsoft .NET Bounty Program. Organisatorisch ist das Projekt Teil der .NET Foundation, verwendet den Contributor Covenant, und die Quellcode-Navigation läuft über source.dot.net; der API-Katalog apisof.net listet auch APIs aus Tages-Builds.
Redaktionelles Fazit
dotnet/runtime ist die Codebasis hinter fast jeder .NET-Anwendung: CoreCLR und Mono als Ausführungsengines, die Klassenbibliotheken und der dotnet-Host als Muxer. Anwender installieren Releases über dotnet.microsoft.com und brauchen das Repository nicht; relevant wird es für Bibliotheksautoren, die Dogfood-Builds testen wollen, und für Mitwirkende, die mit build.sh -subset clr+libs starten. Mit drei parallel gepflegten Release-Schienen und 7.621 offenen Issues ist die Issue-Disziplin wichtig: Runtime-, Bibliotheks- und Installationsfragen gehören hierher, alles andere in die Schwester-Repositories.
Community-Notizen