Claude Code und .NET 10 - unser Entwicklungsstack

Rohit Birdi 03. October 2026 42 Aufrufe

Blick hinter die Kulissen: warum wir auf .NET 10 statt Node.js setzen, wie Claude Code und der C# Compiler zusammenspielen und wie ihr unser Setup in 2 Minuten nachbaut.

← Zurück zum Blog

Heute gibt's mal einen Blick hinter die Kulissen: Womit entwickeln wir eigentlich? Kurz gesagt mit .NET 10 und Claude Code. In diesem Beitrag erzähle ich euch, warum ich bei .NET geblieben bin, wie unser Setup aussieht und wie ihr die Struktur aus unserem aktuellen Kundenprojekt in 2 Minuten nachbauen könnt.

Meine Geschichte mit .NET

Ich bin mit Microsoft Technologien groß geworden. Das erste Mal bin ich in der HTL damit in Berührung gekommen und habe seitdem den Werdegang von Microsofts eigener IDE miterlebt - nämlich Visual Studio. Zwischen Visual Studio 2013 und Visual Studio 2026 liegen Welten.

Damals war .NET noch das große, schwere Framework, das nur unter Windows läuft. Wer was Modernes wollte, ist woanders hingegangen. Ehrlich gesagt war ich selbst eine Zeit lang skeptisch.

2014 kam dann der Moment, der für mich alles geändert hat: Microsoft hat .NET Core angekündigt. Open Source, plattformübergreifend, unter MIT Lizenz und öffentlich auf GitHub entwickelt. Heute, über 12 Jahre später, entwickeln wir alles mit .NET.

Warum .NET und nicht Node.js?

Die Frage kommt oft. Node.js ist ehrlich gesagt ein super Ökosystem, ich habe selbst viele Kundenprojekte damit gebaut, und für viele Teams ist es genau das Richtige. Bei mir hat auf persönlicher und natürlich auch auf beruflicher Ebene am Ende aber .NET gewonnen. Warum?

1. Typsicherheit eingebaut, nicht nachgerüstet

TypeScript ist in der Node Welt zwar Standard, aber eben eine Schicht obendrauf: eigene Config, eigener Build Schritt und zur Laufzeit wieder JavaScript. In C# ist das Typsystem das Fundament. Was der Compiler durchlässt, passt meistens auch zur Laufzeit.

2. Eine Standardbibliothek, die den Namen verdient

HTTP, JSON, Dependency Injection, Logging, Konfiguration, Kryptografie - alles ist direkt dabei und wird von Microsoft gepflegt. Bei Node brauche ich dafür einiges aus npm, und der node_modules Ordner hat schnell hunderte transitive Abhängigkeiten. Jede davon ist eine potenzielle Baustelle, bei Updates genauso wie bei der Security.

3. Ein Tool für alles

dotnet new, build, test, format, publish. Ein CLI, ein Weg. Keine Diskussion npm vs. yarn vs. pnpm, Jest vs. Vitest oder welcher Bundler gerade in ist.

4. Langlebigkeit

Code, den ich vor Jahren in C# geschrieben habe, kann ich heute noch lesen und mit überschaubarem Aufwand migrieren. Das Ökosystem bewegt sich, aber kontrolliert.

Unser Stack aktuell

  • .NET 10 (LTS)
  • Visual Studio und Visual Studio Code als IDEs
  • Claude Code als AI Agent direkt im Terminal
  • xUnit fürs Testen
  • GitHub und Azure DevOps

Warum .NET und Claude Code so gut zusammenpassen

Jetzt wird's spannend. Claude Code schreibt Code, führt Befehle aus und prüft seine eigene Arbeit. Dafür ist ein streng typisiertes Ökosystem ideal:

  • Compiler = erstes Sicherheitsnetz: Nach jeder Änderung ein dotnet build. Falsche Typen, fehlende Methoden oder vergessene Null Checks (Stichwort Nullable Reference Types) fallen sofort auf und nicht erst in Prod.
  • Tests = zweites Sicherheitsnetz: dotnet test gibt Claude Code ein klares Ja oder Nein, ob es funktioniert.
  • Einheitliche Konventionen: .NET Projekte sind fast immer gleich aufgebaut. Der Agent findet sich sofort zurecht - genau wie neue Kollegen.

Wie das konkret läuft: In Visual Studio Code hängt sich die Claude Code Extension direkt in die IDE ein. Klasse markieren, beschreiben was ich will - Claude Code sieht die Auswahl, liest den Kontext, schlägt Änderungen vor, baut das Projekt und lässt die Tests laufen. In Visual Studio läuft Claude Code im integrierten Terminal daneben. Dort gibt es keine direkte Verbindung zur Markierung im Editor, also verweise ich im Prompt einfach mit @ auf die jeweilige Datei. Funktioniert genauso gut ;)

Schnellstart: die Struktur in 2 Minuten

Das Grundgerüst unseres Kundenprojekts ist komplett mit den Standard Templates aus dem .NET 10 SDK entstanden. Ihr könnt es 1:1 nachbauen:

1. SDK Version festnageln

Damit alle im Team mit derselben SDK Version bauen:

dotnet new globaljson --sdk-version 10.0.203 --roll-forward latestFeature

Tipp: Tragt hier die Version ein, die bei euch installiert ist (dotnet --version).

2. Projektmappe anlegen

.NET 10 legt standardmäßig das neue .slnx Format an:

dotnet new sln -n Kunde.Analyzer

3. Klassenbibliothek und Testprojekt

dotnet new classlib -n Kunde.Analyzer -o src/Kunde.Analyzer
dotnet new xunit -n Kunde.Analyzer.Tests -o tests/Kunde.Analyzer.Tests

4. Alles verdrahten

dotnet sln add src/Kunde.Analyzer tests/Kunde.Analyzer.Tests
dotnet add tests/Kunde.Analyzer.Tests reference src/Kunde.Analyzer
dotnet add src/Kunde.Analyzer package Microsoft.CodeAnalysis.CSharp

5. .gitignore für .NET

dotnet new gitignore

6. Testen, ob alles läuft

dotnet build
dotnet test

Danach Terminal auf, claude starten und loslegen!

Die Struktur am Ende

Kunde.Analyzer.slnx
global.json
src/Kunde.Analyzer/
tests/Kunde.Analyzer.Tests/

In src/Kunde.Analyzer/ sind im Laufe des Projekts dann die Ordner Abstractions, Analyzers, Configuration, Models, Reporting und Services dazugekommen - die legt das Template nicht an, die entstehen mit der Zeit.

Fazit

.NET ist für mich keine Nostalgie Entscheidung, auch wenn ich damit groß geworden bin. Es ist offen, verlässlich, super gepflegt und mit Claude Code an der Seite so produktiv wie noch nie. Compiler und Tests halten den Agenten auf Kurs, und ich kann mich auf das konzentrieren, was zählt: gute Software für unsere Kunden.

Wie entwickelt ihr eure Software? Schreibt uns! ;)

Der Text dieses Beitrags wurde mithilfe von KI sprachlich überarbeitet und korrigiert.

Dieser Beitrag wurde 42 mal aufgerufen – Wie findest du diesen Beitrag?

Kommentare

Kommentar hinterlassen

Kommentare werden moderiert und bei Regelverstößen oder Missbrauch ausnahmslos entfernt.