Blog
Built with .NET:
Wo die Anwendungen sind, die niemand mitzählt
Stell die Frage in einer beliebigen Entwicklerrunde: Welche echte Anwendung, die Menschen täglich benutzen, ist mit .NET gebaut? Die erste Antwort ist KeePass. Die zweite ist Paint.NET. Dann wird es still.
Diese Stille ist das Thema dieses Beitrags. Denn sie hat weniger mit .NET zu tun als mit der Art, wie wir Verbreitung messen.
Warum Paint.NET das falsche Beispiel ist
Paint.NET ist ein solides Programm. Aktuell ist Version 5.1.12 vom 08.03.2026, und seit Version 5.0 ist der alte C++/CLI-Code komplett nach C# portiert. Aber sobald es genannt wird, beginnt derselbe Vergleich: Warum sollte jemand Paint.NET installieren, wenn es GIMP gibt? Diese Diskussion lässt sich kaum gewinnen, und deshalb endet sie dort fast immer.
Der Fehler liegt nicht in der Antwort, sondern in der Kategorie. .NET hat seine Endnutzer nicht bei der Bildbearbeitung. Es hat sie bei Spielen und bei Windows-Werkzeugen. Und dort sieht die Bilanz völlig anders aus.
Der Messfehler
Der naheliegende Weg zu einer Bestandsaufnahme führt über GitHub: nach language:C# filtern, nach Sternen sortieren, die ersten zehn nehmen. Das Ergebnis taugt nicht, aus drei Gründen.
Erstens verliert der Sprachfilter genau die großen Anwendungen.
GitHub ordnet ein Repository der Sprache mit den meisten Bytes zu. Microsofts PowerToys mit 138.662 Sternen läuft deshalb unter “C”, obwohl knapp ein Drittel des Codes (32,49 Prozent) C# ist. HandBrake mit 24.386 Sternen läuft ebenfalls unter “C”, obwohl die gesamte Windows-Oberfläche mit 24,02 Prozent C#-Anteil eine WPF-Anwendung ist. Eine Suche nach language:C# findet beide nicht.
Zweitens messen Sterne Entwickler-Aufmerksamkeit, nicht Nutzung.
Die meistgesternte .NET-Anwendung auf GitHub ist v2rayN, ein Proxy-Client mit 116.177 Sternen, den in Deutschland kaum jemand kennen dürfte. Direkt dahinter shadowsocks-windows mit 59.557.
Drittens sind die größten .NET-Anwendungen gar nicht auf GitHub.
KeePass liegt auf SourceForge. Paint.NET, MusicBee, Terraria und Stardew Valley sind Closed Source. Null Sterne, Millionen Nutzer.
Forks messen etwas anderes als erwartet
Der berechtigte Einwand gegen Sterne lautet: Forks kann man nicht kaufen. Das stimmt, aber Forks zählen Entwickler, nicht Nutzer. Was sie tatsächlich verraten, zeigt sich erst im Verhältnis Sterne pro Fork (Stand 26.07.2026):
| Repository | Sterne pro Fork | Was es wirklich ist |
|---|---|---|
| eShopOnContainers | 2,4 | Microsoft-Beispielprojekt |
| shadowsocks-windows | 3,7 | Client, den jeder für sich selbst baut |
| CleanArchitecture | 4,8 | Projekt-Vorlage |
| ShareX | 10,0 | fertige Anwendung |
| Files | 15,9 | fertige Anwendung |
| Playnite | 20,9 | fertige Anwendung |
| Flow Launcher | 24,4 | fertige Anwendung |
| G-Helper | 26,4 | fertige Anwendung |
| UniGetUI | 29,0 | fertige Anwendung |
Das ist die Umkehrung der verbreiteten Deutung. Viele Forks bedeuten Vorlage, Bibliothek oder Selbstbau-Client. Wenige Forks bei vielen Sternen bedeuten fertige Anwendung, die man installiert statt kopiert. Für eine Liste echter Anwendungen ist ein hohes Verhältnis also das Gütesiegel, nicht ein niedriges.
Die einzige harte Nutzungszahl
Es gibt eine Zahl, die tatsächlich Installationen zählt: die Summe aller Asset-Downloads über alle GitHub-Releases. Abgefragt am 15.09.2026:
| Anwendung | Asset-Downloads | Releases |
|---|---|---|
| osu!lazer | 259.537.775 | 651 |
| PowerToys | 146.228.248 | 139 |
| v2rayN | 65.668.425 | 337 |
| HandBrake | 59.037.961 | 54 |
| Greenshot | 54.752.741 | 126 |
| ShareX | 33.681.209 | 90 |
| NAPS2 | 14.117.083 | 109 |
| Subtitle Edit | 13.406.642 | 181 |
| G-Helper | 10.314.782 | 298 |
| Playnite | 4.481.099 | 164 |
| Duplicati | 1.486.880 | 268 |
| Files | 90.125 | 141 |
Zwei Vorbehalte, ohne die die Tabelle unehrlich wäre. Updates zählen mit, Projekte mit vielen Releases stehen dadurch systematisch besser da. Und gezählt wird nur der GitHub-Kanal: Files kommt auf 90.125 Downloads bei 45.413 Sternen, weil es über den Microsoft Store verteilt wird. Genau dieser Widerspruch zeigt, dass diese Zahlen verschiedene Dinge messen.
Spiele
Hier steht der stärkste Fall, und er wird in der .NET-Diskussion praktisch nie geführt.
Terraria hat im Mai 2026 zum 15. Jubiläum die Marke von 70 Millionen verkauften Kopien überschritten: 39,6 Millionen auf PC, 19,7 Millionen mobil, 10,7 Millionen auf Konsolen. Im Jahresschnitt spielen es täglich rund 461.000 Menschen auf PC, der Spitzenwert liegt bei 1,4 Millionen, die durchschnittliche Spielzeit pro Käufer bei 101 Stunden. Geschrieben in C# auf Microsofts XNA.
Stardew Valley hat laut seinem Entwickler Eric Barone zum zehnten Jubiläum im Februar 2026 die Marke von 50 Millionen verkauften Kopien überschritten. Ursprünglich XNA, seit 2021 MonoGame. Barone hat MonoGame daraufhin 125.000 US-Dollar gespendet plus einen laufenden monatlichen Beitrag, was für ein Ein-Mann-Projekt eine bemerkenswerte Geste ist.
Celeste läuft auf C# über ein eigenes kleines Framework namens Monocle auf XNA, portiert mit FNA und MonoGame. osu! hat über 18,5 Millionen registrierte Konten (Stand September 2024). OpenRA, die offene Engine für die frühen Command-and-Conquer-Titel, hat 17.374 Sterne.
Und dann kommt der Punkt, an dem die Diskussion eigentlich vorbei sein dürfte: Unity. Nach eigenen Angaben stecken 70 Prozent der 1.000 erfolgreichsten Mobile-Spiele in Unity, dazu kommen über drei Milliarden Mobile-Downloads pro Monat und mehr als 1,3 Millionen aktive Entwickler monatlich. Bekannte Titel sind etwa Among Us, Hearthstone, Genshin Impact, Subnautica und Cities: Skylines II.
Die Skriptsprache ist C#, in ihr wird das Spiel selbst programmiert. Die Engine besteht dagegen nur zum Teil aus C#.
Bisher lief das auf Mono, weshalb man sauber trennen musste zwischen “benutzt C#” und “läuft auf .NET”. Diese Trennung soll wegfallen: Unity 7 baut auf CoreCLR, der Laufzeitumgebung des heutigen .NET, und lässt Mono komplett hinter sich. Angekündigt ist eine frühe Beta für Dezember 2026 und das finale Release für das erste Quartal 2027.
Windows-Anwendungen, die viele kennen
PowerToys ist Microsofts eigener Werkzeugkasten für Poweruser und kommt auf 146,2 Millionen Downloads. HandBrake gehört mit 59,0 Millionen Downloads zu den bekanntesten freien Werkzeugen, um Videos umzuwandeln. Der Kern ist C, aber die Windows-Oberfläche ist WPF.
Bei Screenshots liegen zwei der meistgeladenen Werkzeuge auf .NET: Greenshot mit 54,8 Millionen und ShareX mit 33,7 Millionen Downloads. Wer unter Windows Bildschirmaufnahmen macht, benutzt also womöglich eine C#-Anwendung, ohne es zu wissen. Dazu NAPS2 für Scannen und PDF mit 14,1 Millionen und Subtitle Edit für die Bearbeitung von Untertiteln mit 13,4 Millionen.
KeePass schließlich, C# auf .NET Framework und per Mono auch auf Linux und macOS: Consumer Reports zählte es bereits 2017 zu den vier meistgenutzten Passwort-Managern überhaupt.
Mobilgeräte, ehrlich betrachtet
Auf Mobilgeräten ist die Bilanz dünner, aber nicht leer. Microsoft selbst baut seine Azure-App mit .NET MAUI, und in Microsofts Kundenübersicht steht zum Beispiel My Ride K-12 von Tyler Technologies.
Und weil eine Liste ohne Gegenbeispiel Werbung wäre:
Bitwarden hat seine Xamarin-Apps nicht auf MAUI migriert.
Der Passwort-Manager hat im Januar 2025 auf natives Swift und Kotlin umgestellt und das mit Performance, schnelleren Updates und besserem Zugang zu Plattform-Neuerungen begründet. Wer über .NET auf Mobilgeräten schreibt, sollte diesen Abgang erwähnen.
Und im Backend
Viele .NET-Anwendungen sieht man gar nicht, weil sie auf Servern laufen. Zwei Beispiele, die fast jeder schon benutzt haben dürfte:
Bing läuft auf .NET. Die Suchmaschine hat laut Microsoft schon die Release Candidates von .NET 10 in Produktion eingesetzt, mit spürbar besseren Antwortzeiten.
Stack Overflow nutzt für seine öffentlichen Seiten seit jeher SQL Server. Beim Umzug in die Google Cloud im Jahr 2025 liefen einige ältere Anwendungen dort noch auf dem klassischen .NET Framework, in einem Kubernetes-Cluster mit Windows. Stack Overflow for Teams läuft dagegen komplett auf modernem .NET.
Zum Lesen empfohlen
Der eigentliche Wert dieser Liste liegt woanders. Hier liegen ausgereifte Desktop-Anwendungen offen herum, an denen man Architektur lernen kann. Fünf davon lohnen einen genaueren Blick. Die Angaben stammen aus dem Quellcode, die Zahlen wurden am 15.09.2026 zuletzt abgeglichen.
OpenRA treibt Komposition an die Grenze. Im Verzeichnis OpenRA.Mods.Common/Traits/ liegen 501 Dateien, und die meisten sind winzig. Der eigentliche Inhalt von Huntable.cs besteht aus drei Zeilen:
[Desc("This actor can be targeted by the Hunt activity.")]
public class HuntableInfo : TraitInfo<Huntable> { }
public class Huntable { }Eine Fähigkeit ist hier eine leere Markierungsklasse, und das [Desc]-Attribut ist gleichzeitig die Dokumentation, aus der die Mod-Referenz generiert wird. Kein Vererbungsbaum, keine Basisklasse mit dreißig virtuellen Methoden. Wer verstehen will, was Komposition statt Vererbung praktisch bedeutet, findet hier 501 Beispiele.
osu! löst ein Problem, an dem die meisten Projekte gar nicht erst ansetzen: Wie testet man eine Oberfläche automatisiert? Die Antwort sind 888 Dateien mit dem Namensmuster TestScene*. Ein vollständiger visueller Test sieht so aus:
AddStep("create initial", () => { Child = explosion = new ParticleExplosion(...); });
AddWaitStep("wait for playback", 5);
AddRepeatStep(@"restart animation", () => { explosion.Restart(); }, 10);Das ist ein deklaratives Skript, das in der Continuous Integration durchläuft und das ein Mensch im mitgelieferten Test-Browser gleichzeitig ansehen kann. Für ein Rhythmus-Spiel, bei dem Timing und Animation die Kernfunktion sind, ist das keine Spielerei, sondern die einzige belastbare Absicherung.
Lively Wallpaper ist mit rund 430 C#-Dateien klein genug, um es an einem Abend zu verstehen, und zeigt trotzdem Prozessisolation im Ernstfall. Die WinUI-Oberfläche spricht über gRPC mit dem Kern, jede Abspiel-Technik läuft in einem eigenen Prozess (CefSharp, WebView2, VLC, Windows Media Foundation), und dazu kommt ein eigenes kleines Programm namens Watchdog. Sein einziger Zweck steht in seinem Klassenkommentar: Es räumt die als Hintergrundbild laufenden Fremdprogramme auf, wenn Lively selbst über den Taskmanager abgeschossen wird. Gesteuert wird es über ein Protokoll aus drei Kommandos auf der Standardeingabe: ADD, RMV, CLR. Die ganze Datei ist keine hundert Zeilen lang und löst ein Problem, das in großen Anwendungen gern in einem Wartungs-Thread mit Zustandsmaschine endet.
Files ist der beste Blick auf heutige Windows-Entwicklung, aber nicht als Stilvorbild. Der Datei-Manager bringt WinUI 3, einen eigenen Quellcode-Generator, CsWin32 für die Windows-Aufrufe, einen separaten Server-Prozess und zwei Testprojekte mit. Der gesamte Dienstgraph der Anwendung steht in AppLifecycleHelper.cs, einer Datei mit 638 Zeilen und 77 AddSingleton-Aufrufen.
Das ist lehrreich in beide Richtungen: Man sieht die komplette Abhängigkeitsstruktur einer echten Anwendung an einer Stelle, und man sieht, wohin es führt, wenn alles ein Singleton ist. Dazu greift Files über Ioc.Default auf einen Service Locator zu statt über Konstruktor-Injektion, und ShellViewModel.cs ist auf 117 Kilobyte angewachsen.
Subtitle Edit ist der Fall, der mich am meisten überrascht hat. Ich hatte einen gewachsenen WinForms-Altbau erwartet. Tatsächlich ist der Hauptzweig eine vollständige Neuentwicklung auf .NET 10 mit Avalonia 12, CommunityToolkit.Mvvm und Microsoft.Extensions.DependencyInjection, plattformübergreifend bis Linux. Version 5.2.0 ist am 10.09.2026 erschienen. Die Projektstruktur ist sauber getrennt in Kernlogik, UI-Logik, Oberfläche und ein eigenes Konsolen-Werkzeug, dazu fünf Testprojekte inklusive Benchmarks.
Und dann liegt in src/ui/Features/Main/MainViewModel.cs eine Klasse mit 33.894 Zeilen in einer einzigen Datei. Im Juli waren es noch knapp 24.000.
Beides gleichzeitig, im selben Projekt: moderner Stack, vorbildliche Schichtung, fünf Testprojekte, und ein ViewModel von 1,3 Megabyte. Wer wissen will, wie echte Software aussieht statt Konferenzfolien, sollte genau das lesen. Aufräumen ist eine Aufgabe an der Klasse, nicht an der Architektur, und die Architektur stimmt hier.
Fazit
Es gibt keinen Grund für die Stille. Eines der erfolgreichsten Spiele aller Zeiten ist in C# geschrieben, Unity skriptet in C# und wechselt mit Version 7 auf CoreCLR, und zwei der meistgeladenen Screenshot-Werkzeuge unter Windows sind .NET-Anwendungen.
Man sieht es nur nicht. Zum einen, weil diese Anwendungen nicht damit werben: Es gibt kein “Built with .NET”-Abzeichen im Startbildschirm von Terraria. Zum anderen, weil die üblichen Ranglisten Repositories zählen statt Nutzer, und weil selbst der Sprachfilter auf GitHub die größten Kandidaten übersieht.
Die Anwendungen sind da. Sie waren nur nirgends zusammengetragen.