Die fertige Version von .NET 10.0 steht seit den Abendstunden des 11. November 2025 auf der Downloadseite kostenfrei zur Verfügung. Für .NET 10.0 benötigen Entwicklerinnen und Entwickler die Entwicklungsumgebung Visual Studio 2026 (alias Version 18.0), die ebenfalls gestern erstmals in einer stabilen Version erschienen ist.

Support für 36 Monate

Microsoft gewährt für .NET 10.0 einen Long-Term Support (LTS) von 36 Monaten, also von November 2025 bis November 2028. Für die vorherige Version .NET 9.0 endet der Support ebenfalls im November 2028, nachdem Microsoft im September bekanntgab, den ursprünglich auf 18 Monate begrenzten Support auf 24 Monate zu erweitern.

Diese Erweiterung gilt ab .NET 9.0 für alle Versionen mit Standard-Term Support (STS). .NET 11.0, das im November 2026 erscheinen soll (voraussichtlich wieder am zweiten Dienstag im November, also am 10.11.2026), wird wieder eine solche Version mit Standard-Term Support sein.

.NET für Android läuft auch auf .NET Core Runtime

Der Aufbau von .NET 10.0 ist fast der gleiche wie bei .NET 9.0 (siehe Abbildung): zahlreiche Anwendungsarten laufen auf Basis eines gemeinsamen Software Development Kit (SDK), einer gemeinsamen Basisklassenbibliothek, den Sprachen C#, F# und Visual Basic .NET sowie dem in (fast) allen Anwendungsarten verwendbaren objektrelationalen Mapper Entity Framework Core. Anders als der Vorgänger Entity Framework Core 9.0, der auf .NET 8.0 und .NET 9.0 nutzbar war, läuft die Version 10.0 des objektrelationalen Mappers ausschließlich auf .NET 10.0. Im Untergrund von .NET 10.0 wirken weiterhin zwei verschiedene Runtimes, abhängig von Anwendungsart und Betriebssystem: die .NET Core Runtime und die Mono Runtime.

Neu in .NET 10.0 ist, dass Android-Anwendungen nicht nur wie bisher auf der Mono Runtime, sondern auch auf der .NET Core Runtime laufen können. Dieses Feature gilt aber in .NET 10.0 als experimentell. Ebenso gilt die Kompilierung von Konsolenanwendungen und Browseranwendungen (außer innerhalb von Blazor) zu WebAssembly weiterhin als experimentelles Feature.

Wieder zahlreiche Breaking Changes

Umsteiger von älteren .NET-Versionen auf .NET 10.0 müssen nicht nur das Target-Framework in der Projektdatei bzw. zentralen Build-Konfigurationsdatei Directory.Build.props auf net10.0 ändern, sondern auch einige Breaking Changes berücksichtigen.

Die Breaking Changes, von denen es in .NET 10.0 weniger als in den letzten Versionen gibt, dokumentiert Microsoft in drei Listen:

.NET 10.0 läuft schneller

Wie in den letzten Versionen hat Microsoft zahlreiche Leistungsverbesserungen eingebaut. Insbesondere sind das in .NET 10.0 Verbesserungen der Ausführungszeit und Speicherallokation bei zahlreichen .NET-Basisklassen, was sich positiv auf viele Anwendungen auswirkt. Erläuterungen zu den Performance- und Speicherverbrauchsverbesserungen und genaue Zahlen findet man in einem sehr langen Dokument.

Neuerungen in allen Bereichen

In .NET 10.0 gibt es viele neue Funktionen in allen Bereichen: bei der Programmiersprache C#, in der Basisklassenbibliothek, beim objektrelationalen Mapping mit Entity Framework Core, bei der JSON-Serialisierung mit System.Text.Json, den Webframeworks ASP.NET Core und Blazor sowie bei dem Cross-Platform-UI .NET MAUI. Auch bei den alten Windows-Desktop-Frameworks Windows Forms und WPF gibt es einzelne Verbesserungen.

heise Developer hatte über die Neuerungen in .NET 10.0 jeweils anhand der Preview- und Release-Candidate-1-Versionen berichtet, sofern es dort signifikante Neuerungen gab.

Für viele Unternehmen lautet die zentrale Frage nicht mehr, ob sie künstliche Intelligenz einsetzen, sondern wie sie diese verantwortungsvoll und nachhaltig integrieren. Bislang bremsen fragmentierte, nicht standardisierte Insellösungen und meist teure proprietäre KI-Stacks die Einführung noch. Besonders für Organisationen, die auf Datensouveränität, Compliance und langfristige finanzielle Stabilität setzen, stellt die unkoordinierte KI-Infrastruktur ein erhebliches Risiko dar – in Hybrid-Cloud-Umgebungen ebenso wie On-Premises.

Mit der im Rahmen der KubeCon + CloudNativeCon North America 2025 offiziell freigegebenen Version 1.0 des „Kubernetes AI Conformance“-Programms will die Cloud Native Computing Foundation (CNCF) nun Ordnung in die zersplitterte KI-Landschaft bringen. Das Programm geht dabei über eine Zertifizierung hinaus – es ist als eine weltweit getragene Open-Source-Initiative angelegt, die einen gemeinsamen technischen Standard für KI-Infrastrukturen schaffen soll. „Insbesondere für europäische Unternehmen liefert sie den Rahmen, um KI sicher und skalierbar einzusetzen“, erklärt Mario Fahlandt, der bei der CNCF unter anderem als Co-Chair der Technical Advisory Group (TAG) Operational Resilience sowie der Special Interest Group (SIG) Contributor Experience für Kubernetes aktiv ist. „Die Initiative definiert eine klare, zukunftssichere Roadmap, die Workload‑Portabilität, technische Konsistenz und digitale Souveränität gewährleistet.“

Technische Standards versus Prozess‑Frameworks

Während der KI-Markt durch eine Vielzahl an Zertifizierungen geprägt ist, müssen Entscheidungsträger klar zwischen technischen und organisatorischen Standards unterscheiden. Einige Anbieter konzentrieren sich auf Management- und Governance-Frameworks wie ISO 42001. Dieser internationale Standard legt Anforderungen für den Aufbau eines KI-Managementsystems (AIMS) fest. Er unterstützt Unternehmen dabei, Risiken, ethische Fragen, Datenschutz und regulatorische Vorgaben zu steuern. Außerdem bewertet er, ob interne Prozesse eine verantwortungsvolle Entwicklung und Bereitstellung von KI sicherstellen.

Das neue CNCF‑Programm „Kubernetes AI Conformance“ hebt sich grundlegend von Governance-Standards ab. Es fungiert primär als technischer Implementierungsstandard und legt dazu fest, welche Fähigkeiten, APIs und Konfigurationen ein Kubernetes-Cluster benötigt, um KI‑ und ML‑Workloads zuverlässig und effizient auszuführen. Damit zielt die CNCF-Konformität auf eine garantierte technische Portabilität ab, die auch zu weniger Abhängigkeit von einzelnen Herstellern beiträgt. Sie stellt sicher, dass Unternehmen ihre KI-Anwendungen künftig auf jeder konformen Plattform betreiben können – in der Public Cloud, im eigenen Rechenzentrum oder an Edge-Standorten. Diese Portabilität bildet die Grundlage digitaler und damit auch datengetriebener Souveränität.

Die Entwicklung des Standards treibt innerhalb des Kubernetes-Projekts eine neu gebildete Arbeitsgruppe voran, die durch die Special Interest Groups Architecture und Testing unterstützt wird. Seit der KubeCon Europe im Frühjahr 2025 hat die Gruppe zunächst zentrale technische Säulen definiert, die die besonderen Anforderungen von KI‑Workloads berücksichtigen. „Darauf aufbauend entstand ein verbindlicher Anforderungskatalog, den jede Plattform erfüllen muss, um als Kubernetes-AI-konform zu gelten“, erläutert Fahlandt.

Effizientes Management von Beschleunigern im KI-Training

KI‑Trainingsjobs setzen umfassende Hardware‑Ressourcen voraus und benötigen meist teure, häufig zudem knapp verfügbare GPUs. In nicht standardisierten Umgebungen ergeben sich daraus zwei Kernprobleme:

• Ressourcenfragmentierung: Wertvoller GPU‑Speicher bleibt ungenutzt.
• Topologie‑Blindheit: Das Scheduling ist nicht für Multi‑GPU‑Workloads optimiert.

Beide Aspekte tragen zur Überprovisionierung und steigenden Kosten bei.

Eine CNCF‑konforme Plattform muss daher die Kubernetes-API für Dynamic Resource Allocation (DRA) unterstützen. Seit Kubernetes-Version 1.34 gilt DRA als stabil und ermöglicht es, komplexe Hardware-Ressourcen flexibel anzufordern und zu teilen. Ähnlich dem PersistentVolumeClaim‑Modell für Speicher können Nutzerinnen und Nutzer gezielt Ressourcen aus definierten Geräteklassen anfordern. Kubernetes übernimmt dabei automatisch das Scheduling und die Platzierung aller Workloads.

Erweiterte Ingress‑Funktionen für KI-Inferenz

KI‑Inferenz‑Workloads – also KI-Modelle im Betrieb – unterscheiden sich stark von typischen, zustandslosen Webanwendungen. Sie laufen meist länger, beanspruchen viele Ressourcen und speichern Zustände. Standard‑Load‑Balancer sind für deren Lastverteilung ungeeignet. Das CNCF‑Konformitätsprogramm verlangt daher die Unterstützung der Kubernetes Gateway API und ihrer Erweiterungen für modellbewusstes Routing (model‑aware routing).

Die Gateway API Inference Extension, ein offizielles Kubernetes‑Projekt, erweitert Standard-Gateways zu spezialisierten Inference‑Gateways. Damit lassen sich Routing und Load Balancing gezielt für KI‑Workloads optimieren. Unterstützte Funktionen sind unter anderem gewichtete Verkehrsaufteilung (weighted traffic splitting) und Header‑basiertes Routing, das etwa für OpenAI-Protokoll‐Header relevant ist.

Zeitplanung und Orchestrierung von KI‑Workloads

Verteilte KI-Trainingsjobs bestehen aus mehreren Komponenten, die gleichzeitig starten müssen. Plant der Scheduler Pods einzeln ein, kann es zu Deadlocks kommen: Ein Job bleibt hängen, weil einige Pods keine Ressourcen finden, andere aber bereits Ressourcen blockieren. Eine Kubernetes-Plattform muss mindestens eine All‑or‑Nothing‑Scheduling‑Lösung unterstützen, beispielsweise Kueue oder Volcano. So starten verteilte KI‑Workloads nur, wenn alle zugehörigen Pods gleichzeitig platziert werden können.

Ist ein Cluster‑Autoscaler aktiv, soll er Knotengruppen mit bestimmten Beschleunigertypen je nach Bedarf automatisch vergrößern oder verkleinern. Ebenso muss der HorizontalPodAutoscaler Beschleuniger‑Pods korrekt skalieren und dabei auch benutzerdefinierte Metriken berücksichtigen, die für KI‑ und ML‑Workloads relevant sind.

Überwachung und Metriken

Moderne KI‑Workloads und spezialisierte Hardware erzeugen neue Lücken im Monitoring. Noch fehlt ein einheitlicher Standard, um Beschleuniger-Metriken zu erfassen – viele Teams verfügen daher nicht über geeignete Werkzeuge, um Infrastrukturprobleme schnell zu analysieren.

Jede CNCF‑konforme Plattform muss daher künftig eine Anwendung installieren können, die Leistungsmetriken für alle unterstützten Beschleunigertypen – etwa Auslastung oder Speichernutzung – über einen standardisierten Endpunkt verfügbar macht. Zusätzlich ist ein Überwachungssystem erforderlich, das Metriken automatisch erfasst und verarbeitet, wenn Workloads sie im Standardformat (z. B. Prometheus‑Expositionsformat) bereitstellen.

Sicherheit und Ressourcentrennung

Beschleuniger wie GPUs sind gemeinsam genutzte Ressourcen. Fehlt eine strikte Isolierung auf Kernel‑ und API-Ebene, können Container‑Workloads gegenseitig auf Daten oder Prozesse zugreifen und so Sicherheitsrisiken in Multi‑Tenant‑Umgebungen verursachen. Eine CNCF‑konforme Plattform muss daher den Zugriff auf Beschleuniger klar trennen und über Frameworks wie Dynamic Resource Allocation (DRA) oder Geräte-Plug-ins kontrollieren. Nur so lassen sich Workloads isolieren und unerlaubte Zugriffe oder Beeinträchtigungen verhindern.

Unterstützung für Operatoren

KI-Frameworks wie Ray oder Kubeflow sind verteilte Systeme, die auf Kubernetes als Operatoren laufen. Eine Plattform benötigt dafür eine stabile Basis, um zu verhindern, dass instabile Webhooks, CRD‑Verwaltung (Custom Resource Definition) oder eine unzuverlässige API-Server-Struktur dazu führen, dass Operatoren ausfallen und die gesamte KI-Plattform zum Stillstand kommt.

Eine CNCF-konforme Umgebung muss mindestens einen komplexen KI-Operator (etwa Ray oder Kubeflow) installieren und ausführen können. Sie muss nachweisen, dass Operator‑Pods, Webhooks und die Reconciliation der Custom Resources stabil und vollständig funktionieren.

Ein internationaler, Community‑getriebener Standard mit europäischer Beteiligung

Das Kubernetes-AI-Conformance‑Programm der CNCF schafft auf Basis der von der Arbeitsgruppe WG AI Conformance definierten Säulen einen stabilen, offenen und zukunftssicheren Standard für KI-Infrastrukturen. Plattformen, die auf den offenen Upstream-APIs basieren, eröffnen insbesondere auch europäischen Unternehmen die Chance, ihre KI-Strategien portabel und souverän umzusetzen – von der Public Cloud bis zum sicheren On‑Premises‑Rechenzentrum. „Verschiedene Anbieter‑Plattformen sind bereits ‚Kubernetes AI Conformant‘ für die Kubernetes-Versionen 1.33 und 1.34“, sagt Fahlandt. Dazu zählen auch Plattformen europäischer Anbieter wie Gardener, Giant Swarm, Kubermatic und SUSE.

Weitere Anforderungen werden laufend entwickelt und im Community‑Prozess diskutiert. Die CNCF lädt alle Interessierten ein, sich aktiv an dem offenen Standard zu beteiligen. Weitergehende Informationen rund um das Programm finden sich in der offiziellen Ankündigung im CNCF-Blog.

(map)

Die Entwickler der Shell fish haben Version 4.2.0 veröffentlicht. Zu den wichtigsten Neuerungen zählen mehrzeilige Befehle in der verlaufsbasierten Autovervollständigung sowie grundlegende Änderungen bei der Zeichenkodierung.

Die Autovervollständigung auf Basis der Befehlshistorie schlägt nun auch mehrzeilige Kommandos vor – eine Funktion, die bei komplexeren Shell-Skripten oder verschachtelten Befehlen für viele Nutzer im Alltag praktisch ist. Zudem wurden Probleme beim Löschen mehrzeiliger transienter Prompts behoben: Wenn ein solcher Prompt mehr Zeilen umfasst als der finale Prompt, wird er jetzt korrekt entfernt.

Ein weiteres praktisches Feature betrifft die Terminal-Konfiguration: Anwender können jetzt den Titel des Terminal-Tabs getrennt vom Fenstertitel setzen, indem sie die Funktion fish_tab_title definieren – gut für den Überblick. Bei sehr langen Kommandozeilen blendet fish außerdem den Teil des mehrzeiligen Prompts aus, der aufgrund der Bildlaufposition nicht mehr sichtbar ist. Das verhindert doppelte Zeilen nach dem Neuzeichnen.

UTF-8 jetzt vorausgesetzt

Eine grundlegende Änderung betrifft die Zeichenkodierung: fish geht jetzt immer von UTF-8 aus, selbst wenn das System kein UTF-8-Locale konfiguriert hat. Eingabebytes, die kein gültiges UTF-8 darstellen, werden weiterhin korrekt verarbeitet – Dateipfade mit veralteten Kodierungen lassen sich also nach wie vor verwenden, werden aber möglicherweise anders auf der Kommandozeile dargestellt. Auf Systemen ohne Multi-Byte-Locale verzichtet fish künftig auf ASCII-Ersatzzeichen für Unicode-Symbole wie das Auslassungszeichen.

Die Mausbedienung wurde flexibler: fish deaktiviert nicht mehr zwangsweise die Mauserfassung (DECSET/DECRST 1000), sodass Nutzer per Mausklick den Cursor bewegen oder Vervollständigungsvorschläge auswählen können. Die Tastenkombination alt-p fügt zudem kein überflüssiges Leerzeichen mehr zur Kommandozeile hinzu.

Standalone-Build nun Standard

Für Distributoren und Entwickler ist relevant, dass der Standalone-Build-Modus jetzt standardmäßig aktiv ist. Die Dateien in $CMAKE_INSTALL_PREFIX/share/fish werden künftig nicht mehr verwendet – mit Ausnahme der HTML-Dokumentation. Dadurch brechen künftige Updates laufende Shells nicht mehr ab, wenn sich interne Hilfsfunktionen geändert haben. Die Datendateien werden vorerst redundant installiert, um bereits laufende Shells zu schützen. Die minimale unterstützte Rust-Version wurde auf 1.85 geändert.

Release-Tags und Quellcode-Archive sind nun wieder GPG-signiert. Die Dokumentation in den Release-Paketen wird jetzt mit der aktuellen Sphinx-Version erstellt, wodurch die vorgenerierten Man-Pages OSC-8-Hyperlinks enthalten. Die Sphinx-Abhängigkeit ist jetzt in pyproject.toml spezifiziert, wodurch Nutzer uv für den Dokumentations-Build einsetzen können.

Plattform-spezifische Verbesserungen

Unter macOS setzt fish als Login-Shell die Variable MANPATH nun korrekt, wenn diese bereits in der Umgebung vorhanden war. Ein Windows-spezifisches Problem, bei dem die webbasierte Konfiguration nicht startete, wurde ebenfalls behoben. Für MSYS2 gibt es einen Workaround für Konsole und WezTerm, der verhindert, dass diese das falsche Arbeitsverzeichnis beim Öffnen neuer Tabs verwenden.

Im Rahmen der Version 4.0, die im Februar 2025 erschien, hatten die fish-Entwickler den Kerncode von C++ nach Rust portiert. Release 4.2.0 behebt mehrere Regressionen aus den Vorgängerversionen 4.0.0 und 4.1.0, darunter Probleme mit der webbasierten Konfiguration unter Python 3.9, falsche Terminal-Modi bei bestimmten Kommandos und Fehler beim Speichern universeller Variablen unter MSYS2. Auch VTE-basierte Terminals zeigen beim Ändern der Fenstergröße wieder das korrekte Verhalten.

Schließlich wurden auch die Übersetzungen erweitert: Neben den bereits vorhandenen Sprachen ist nun Chinesisch (Taiwan) mit an Bord, zudem wurden die französischen Übersetzungen ergänzt. Die Release Notes auf GitHub listen alle Änderungen detailliert auf. Für Linux stehen Standalone-Binaries für verschiedene CPU-Architekturen bereit, macOS-Pakete können über Homebrew bezogen werden. Windows-10- und -11-Nutzer müssen das Windows Subsystem for Linux (WSL) heranziehen, darüber hinaus lässt sich fish mit Cygwin und MSYS2 verwenden.

(fo)