Connect with us

Entwicklung & Code

.NET 11.0 Preview 4: Ein bunter Strauß von API-Erweiterungen


Die vierte Vorschauversion der kommenden .NET-Version 11.0 ist erschienen und steht zum Download bereit. Parallel dazu hat Microsoft auch die Version 11811.120 von Visual Studio 2026 Insiders veröffentlicht, die zum Entwickeln von .NET-11.0-Anwendungen benötigt wird. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.

Weiterlesen nach der Anzeige


Dr. Holger Schwichtenberg

Dr. Holger Schwichtenberg

Dr. Holger Schwichtenberg hat Fachbücher zu .NET 10.0, C# 14.0, Blazor 10.0 und Entity Framework Core 10.0 veröffentlicht. Er arbeitet als Berater und Trainer bei www.IT-Visions.de.


Installation des .NET 11.0 SDK in der Version Preview 4

Installation des .NET 11.0 SDK in der Version Preview 4

Installation des .NET 11.0 SDK in der Version Preview 4


betterCode() .NET 11.0

betterCode() .NET 11.0

(Bild: King / stock.adobe.com)

Das ist neu in .NET 11.0: Dr. Holger Schwichtenberg und weitere Experten präsentieren am 17. November 2026 auf der Online-Konferenz betterCode() .NET 11.0 die Änderungen für Entwicklerinnen und Entwickler in .NET SDK, C# 15.0 und mehr. Bis zur Veröffentlichung des Programms sind vergünstigte Blind-Bird-Tickets verfügbar.

Die Klasse System.Diagnostics.Process zur Verwaltung von Betriebssystemprozessen gibt es seit Version 1.0 des klassischen .NET Framework aus dem Jahr 2002. Prozesse startet man seitdem, indem man eine neue Instanz der Klasse erzeugt. Seit .NET Framework 2.0 (Jahr 2005) gibt es alternativ die statische Methode Process.Start(). 21 Jahre später ergänzt Microsoft nun weitere alternative statische Methoden zum Prozessstart: Process.Run() und Process.RunAsync() sowie Process.RunAndCaptureText() und Process.RunAndCaptureTextAsync(). Das letztgenannte Pärchen liefert ein ProcessTextOutput-Objekt, mit dem man direkt auf Standardausgabe (ProcessTextOutput), Standardfehlerausgabe (StandardError) und Rückgabewert (ExitStatus.ExitCode) zugreifen kann, mit deutlich weniger Programmcode als dies bei der alten Start()-Methode notwendig ist, siehe Listing.

Ein Abbruch des Kindprozesses ist über ein Cancellation-Token möglich. Anders als bei der Start()-Methode kehren alle neuen Methoden mit „Run“ im Namen erst zum Aufrufer zurück, wenn der Kindprozess beendet ist. Entwicklerinnen und Entwickler können dabei allerdings keine Ausgaben des Prozesses verarbeiten, während er läuft.


CancellationTokenSource cts = new CancellationTokenSource();
 
 ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
     "robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"], cts.Token);
 
 CUI.Print("Neuer Prozess mit ID #" + result.ProcessId + " ist beendet!");
 
 CUI.Line("StandardOutput");
 CUI.Print(result.StandardOutput);
 CUI.Line("StandardError");
 CUI.PrintError(result.StandardError);
 CUI.Line("ExitStatus");
 CUI.Print("Canceled? " + result.ExitStatus.Canceled);
 if (result.ExitStatus.HasValue && !result.ExitStatus.IsEmpty) PrintStatus(result.ExitStatus.ExitCode);


Listing 1: Einsatz der neuen Methode Process.RunAndCaptureTextAsync()

Weiterlesen nach der Anzeige

Eine weitere hinzugefügte Methode zum Prozessstart ist Process.StartAndForget() zum Start eines Prozesses, ohne auf den erfolgreichen Start zu warten und ohne direkte Interaktionsmöglichkeiten mit dem neuen Prozess. Man kann lediglich über die zurückgelieferte Prozess-ID den neuen Prozess von außen überwachen, hat aber keinen Zugriff auf den Rückgabewert des Prozesses.


int processId = Process.StartAndForget(
    "robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"]);
 
CUI.Print("Neuer Prozess mit ID #" + processId + " ist gestartet!");
 
var p = Process.GetProcessById(processId);
while(!p.HasExited)
{
 CUI.BusyIndicator();
 Thread.Sleep(500);
}
 
CUI.Line("Neuer Prozess mit ID #" + processId + " ist beendet!");
// PrintStatus(p.ExitCode); // System.InvalidOperationException: 'Process was not started by this object, so requested information cannot be determined.'


Listing 2: Einsatz der neuen Methode Process.StartAndForget()

In der Klasse ProcessStartInfo, die bei Process.Start() verwendet wird, gibt es auch zwei neue Boolean-Optionen: Neu sind zum einen ProcessStartInfo.StartDetached zum Start eines unabhängigen Prozesses mit eigener Konsole, der weiterlebt, auch wenn der startende Prozess beendet wird. Mit ProcessStartInfo.KillOnParentExit erreicht man zum anderen, dass der Kindprozess endet, wenn der startende Prozess endet. Wenn man beide Optionen in Kombination einsetzt, erhält man eine separate Konsole, die aber endet, wenn der startende Prozess endet. Während ProcessStartInfo.StartDetached auf allen Plattformen läuft, meldet ProcessStartInfo.KillOnParentExit aktuell, dass es nur auf Windows funktioniert, denn im Quellcode bei Microsoft steht:


[SupportedOSPlatform("windows")]
public bool KillOnParentExit { get; set; }


In einem Blogeintrag findet man schon den Hinweis darauf, dass Implementierungen für Android und Linux in Arbeit sind.

Für mit Process.Start() gestartete Prozesse gibt es auch die neuen Methoden ReadAllText() und ReadAllTextAsync(), mit denen man von einem beendeten Prozess gleichzeitig die Standardausgabe und die Fehlerausgabe erhalten kann:


process.WaitForExit();
(string output, string error) = process.ReadAllText();


Im Gegensatz zu dem bisherigen Ansatz


string output = process.StandardOutput.ReadToEnd();
string error = process.StandardError.ReadToEnd();


besteht bei den neuen Methoden nicht die Gefahr eines Deadlocks.

In .NET 11.0 Preview 1 hatte Microsoft die Zstandard-Komprimierung ergänzt. Die Klassen ZstandardEncoder und ZstandardDecoder bieten dabei genauso wie die bereits in .NET Core 2.1 eingeführten Klassen BrotliEncoder und BrotliDecoder die Möglichkeit, beim Komprimieren und Dekomprimieren mit den Typen Span und ReadOnlySpan zu arbeiten, ohne die aufwendige Speicherallokation bei Streams. Nun liefert Microsoft diese Option auch für die älteren Klassen ZLibEncoder, DeflateEncoder und GZipEncoder sowie die zugehörigen Decoder, siehe Listing.


CUI.H1($"Komprimiere Datei {BIGFILEPATH} via Span");
 
ReadOnlySpan sourceSpan = File.ReadAllBytes(BIGFILEPATH);
Console.WriteLine("Länge=" + sourceSpan.Length);
long maxCompressedLength = ZLibEncoder.GetMaxCompressedLength(sourceSpan.Length);
Span compressedSpan = new byte[maxCompressedLength];
 
// ZLibEncoder, DeflateEncoder, GZipEncoder, ZstandardEncoder oder BrotliEncoder
using ZLibEncoder encoder = new();
OperationStatus status = encoder.Compress(
    sourceSpan, compressedSpan, out int bytesConsumed, out int bytesWritten,
    isFinalBlock: true);
 
PrintStatus(compressedSpan, status);
 
CUI.H1($"Dekomprimieren aus Span");
 
// ZLibDecoder, DeflateDecoder, GZipDecoder, ZstandardDecoder oder BrotliDecoder
using ZLibDecoder decoder = new();
byte[] decompressedSpan = new byte[sourceSpan.Length];
OperationStatus decompressStatus = decoder.Decompress(
  compressedSpan,
  decompressedSpan,
  out int compressedBytesConsumed,
  out int decompressedBytesWritten);
 
PrintStatus(decompressedSpan, decompressStatus);


Listing 3: Komprimierung und Dekomprimierung mit Span

Die Fließkommazahltypklassen Half, Single und Double können in den Methoden Parse() und TryParse() auch Zeichenketten mit Hexadezimalzahlen auswerten. Dazu müssen Entwicklerinnen und Entwickler aber die Option NumberStyles.HexFloat angeben:


static void TestDouble(double d, string doubleAsString )
{
 string hex = d.ToString("X");
 Console.WriteLine(hex); 
 double d1a = double.Parse(hex, NumberStyles.HexFloat);
 Console.WriteLine(d1a); 
 CUI.Success(d1a == d); // True
 double.TryParse(hex, NumberStyles.HexFloat, null, out double d1b);
 Console.WriteLine(d1b); 
 CUI.Success(d1b == d); // True
}


Die Klassen System.Text.Unicode.Utf8 und System.Text.Unicode.Utf16 bieten nun zwei neue Methoden: IsValid() und IndexOfInvalidSubsequence(). Damit lässt sich nun leichter die Gültigkeit einer Unicode-Zeichenkette prüfen und zumindest die erste fehlerhafte Stelle ermitteln:


ReadOnlySpan chars1 = "Gültiger Text: \uD83D\uDC4D";
Console.WriteLine(chars1);
bool check1 = Utf16.IsValid(chars1); // True
Console.WriteLine(check1);
if (check1) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars1));
 
ReadOnlySpan chars2 = "Ungültiger Text: \uD83D";
Console.WriteLine(chars2);
bool check2 = Utf16.IsValid(chars2); // False
if (check2) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars2));


Bei dem im modernen .NET mitgelieferten JSON-Serialisierer, dem NuGet-Paket System.Text.Json, das auch im klassischen .NET Framework funktioniert, bietet die schon vorher bestehende Methode Reset() in der Klasse Utf8JsonWriter nun eine Überladung, in der man via JsonWriterOptions abweichende Einstellungen festlegen kann. Entwicklerinnen und Entwickler können damit Utf8JsonWriter-Instanzen mit abweichenden Einstellungen wiederverwenden:


using var stream1 = new MemoryStream();
using var writer = new Utf8JsonWriter(stream1, new JsonWriterOptions
  {
    Indented = true
  });
…
using var stream2 = new MemoryStream();
writer.Reset(stream2, new JsonWriterOptions
   {
    Indented = false
   });


Im Source Generator innerhalb von System.Text.Json behebt Microsoft einige Schwächen.



Source link

Entwicklung & Code

.NET-Grafiken: SkiaSharp 4 mit Engine-Upgrade erschienen


Zwei Jahre Arbeit sind in das neu erschienene SkiaSharp 4.148.0 geflossen. Dabei handelt es sich um die erste stabile 4.x-Version der Cross-Platform-2D-Grafik-API für .NET-Plattformen, die auf Googles Skia-Graphics-Bibliothek basiert. Sie bringt eine überarbeitete Engine für verbesserte Grafiken sowie erhöhte Performance.

Weiterlesen nach der Anzeige

SkiaSharp wird vom .NET-Team in Partnerschaft mit dem Uno-Platform-Team entwickelt und kommt in .NET MAUI, WebAssembly, WinUI 3 und Frameworks wie Uno Platform zum Einsatz.


betterCode() .NET 11.0

betterCode() .NET 11.0

(Bild: King / stock.adobe.com)

Das ist neu in .NET: Die Online-Konferenz betterCode() .NET 11.0 präsentiert am 17. November 2026 die zentralen Änderungen für Entwicklerinnen und Entwickler. Bis zur Veröffentlichung des Programms sind vergünstigte Blind-Bird-Tickets verfügbar.

Die in SkiaSharp 4 auf den Chrome-Meilenstein m148 aktualisierte native Skia-Engine soll sich positiv auf bestehende Apps auswirken, ohne Codeänderungen zu erfordern. Unter anderem soll sie die Performance verbessern sowie für schärfere herunterskalierte Grafiken, automatische Fotoausrichtung und akkuratere Farben sorgen. Wie Microsoft in der Ankündigung betont, zeigen erste Tests im Vergleich zur vorherigen SkiaSharp-Version 3.119 ein um bis zu 24 Prozent schnelleres Rendering zentraler App-UI-Bestandteile, wie Schlagschatten und mehrschichtige Oberflächen. Dabei treten laut den Tests an anderen Stellen keine Regressionen auf.

SkiaSharp 4 räumt darüber hinaus mit Legacy-APIs auf und behebt unter der Haube die Ursache für eine Klasse von Use-After-Free-Abstürzen durch einen neuen Umgang mit Singleton-Objektlebenszyklen. Daneben hat das Entwicklungsteam die Test-Suite auf xUnit 3 aktualisiert und jede gebundelte native Dependency mit den neuesten Security-Fixes versehen. Als ein neues Feature ist nun vollständige Kontrolle über OpenType-Variablen-Schriftachsen enthalten, ebenso wie animiertes WebP-Encoding mit SKWebpEncoder sowie Farbpaletten für Emoji- und Icon-Schriftarten.

Weiterlesen nach der Anzeige

Die interaktive SkiaSharp-Galerie zeigt die Möglichkeiten mit Blazor WebAssembly und Uno Platform. Beispiele mit .NET MAUI und weiteren Technologien sollen folgen.

SkiaSharp 4.148.0 steht beim .NET-Paketmanager NuGet unter MIT-Lizenz zum Download bereit. Weitere Informationen zur neuen stabilen Version


(mai)



Source link

Weiterlesen

Entwicklung & Code

Hacking-Fähigkeiten von Chinas KI Z.ai angeblich so gut wie die von Claude


Das chinesische KI-Unternehmen Zhipu AI (bekannt als Z.ai) hat mit GLM-5.2 ein Open-Weight-Modell veröffentlicht, das sich bei der Erkennung von Sicherheitslücken offenbar mit Anthropics Opus 4.8 messen kann.

Weiterlesen nach der Anzeige

Das haben IDOR-Benchmark-Tests der Cybersicherheitsfirma Semgrep ergeben. Da es sich um ein Open-Weight-Modell handelt, kann jeder GLM-5.2 herunterladen, lokal betreiben und modifizieren. Das eröffnet für Hacker weitere Möglichkeiten für kriminelle Einsätze.

Die offene Verfügbarkeit von GLM-5.2 ist ein zweischneidiges Schwert. Sicherheitsfirmen, CERTs und interne Red Teams können das Modell in abgeschotteten Umgebungen für Code-Reviews und Penetrationstests nutzen, ohne sensible Daten an US-Clouds zu übermitteln. Für DSGVO-konforme Umgebungen in Europa ist das ein Vorteil.

Gleichzeitig können auch Angreifer GLM-5.2 ohne jede Aufsicht betreiben. Diese Eigenschaft macht das Modell attraktiv für Akteure, die nach Schwachstellen in kritischen Systemen suchen wollen. Lior Div, Chef der Cybersicherheitsfirma 7AI, fasste die Lage gegenüber dem Wall Street Journal zusammen: China sorge dafür, dass der Abstand zu den US-KIs „immer kleiner“ werde.

Zhipu AI selbst räumt in den Release Notes ein, dass GLM-5.2 während des Reinforcement-Learning-Trainings verstärkt sogenanntes Reward Hacking zeigte. Das Unternehmen habe daraufhin spezielle Anti-Hacking-Sicherungen für das Training und die Evalution des Modells integriert.

Die Entwicklung trifft die US-Regierung in einem heiklen Moment. Eines von Anthropics Modellen war kurzzeitig komplett gesperrt, weil die Trump-Administration den Zugriff durch ausländische Nutzer untersagte. Auch OpenAI bekommt von der US-Regierung Auflagen „aus Sicherheitsgründen“.

Weiterlesen nach der Anzeige

Für europäische Unternehmen und Behörden stellt sich mit der wachsenden Leistungsfähigkeit der KI-Modelle die Governance-Frage: Wie lässt sich der Einsatz solcher Werkzeuge in sicherheitskritischen Bereichen mit dem EU AI Act und nationalen Sicherheitsvorgaben vereinbaren – und wie geht man mit einem Modell um, das beim Schwachstellen-Finden brilliert, aber keiner Aufsicht unterliegt?


(rie)



Source link

Weiterlesen

Entwicklung & Code

So würde eine KI als Start-up-Chef abschneiden


Forscher der Princeton University haben mit CEO-Bench einen neuen Langzeit-Benchmark vorgelegt, der KI-Agenten vor eine ungewöhnliche Aufgabe stellt: Sie sollten 500 Tage lang ein fiktives Software-Start-up führen. Das Ergebnis fällt für die aktuellen Modelle ernüchternd aus. Von zehn getesteten KI-Modellen schafften es lediglich drei, am Ende mehr Geld auf dem Konto zu haben als das Startkapital von einer Million US-Dollar. Zum Vergleich: Daten zu menschengeführten Start-ups in den USA legen nahe, dass ein Fünftel aller Start-ups im ersten Jahr und bis zu 65 Prozent der Start-ups innerhalb von zehn Jahren nach ihrer Gründung scheitern.

Weiterlesen nach der Anzeige

Als Vergleich im Benchmark-Test ließen die Forscher auch einen handkodierten, regelbasierten Agenten ganz ohne maschinelles Lernen die gleiche Aufgabe absolvieren. Abgesehen von den drei Gewinnern performte er besser als die KI-Modelle.

Die in der auf arXiv veröffentlichten Studie mit der beschriebenen Simulation dreht sich um ein Start-up namens „NovaMind“. Die KI-Agenten starten ohne Kunden und mit einer Million Dollar. Fällt der Kontostand unter null, ist die Firma insolvent – und das Spiel vorbei. Um ihr Start-up zu führen, stehen den Agenten 34 Werkzeuge zur Verfügung: von Preisfestlegung über Produktgestaltung bis hin zu Marketing. Als Input bekommen sie unter anderem „unternehmensinterne“ Datenbanken, Informationen zu Kundengruppen mit Präferenzen, die erst entschlüsselt werden müssen, und einen Markt, der sich laufend verändert. Konjunkturzyklen, Druck durch Wettbewerber und Änderung der Marktlage inklusive. Die Modelle müssen unübersichtliche, miteinander vernetzte Unternehmensdatenbanken analysieren, Daten und Ereignisse in fundierte Strategien übersetzen und zahlreiche Entscheidungen aufeinander abstimmen. Wie die Autoren der Studie betonen, messen sie damit nicht die Fähigkeit, isolierte Aufgaben abzuarbeiten, sondern das, was sie „Steering Intelligence“ nennen: die Kompetenz, ein komplexes System über längere Zeit trotz Unsicherheiten zu steuern.

In der Hauptauswertung absolvierten alle Modelle jeweils drei Durchläufe. Als Leistungsmaß dient der beste Run pro Modell. Claude Opus 4.8 erzielte dabei ein End-Guthaben von rund 27,8 Millionen US-Dollar nach 500 Tagen, GPT-5.5 kam auf etwa 21,3 Millionen. Beide Modelle landeten damit in ihrer besten Runde deutlich oberhalb des Startkapitals – in den anderen beiden Runden lagen sie darunter und „bestanden“ den Test ebenfalls nicht. Claude Fable 5 schaffte laut der CEO-Bench-Projektseite in einem Lauf rund 47 Millionen Dollar; hier lief der Test jedoch zwischenzeitlich mit Opus, da Fable sich aufgrund seiner starken Sicherheitseinschränkungen immer mal wieder Aufgaben verweigerte.

Die übrigen Modelle blieben entweder unter dem Startkapital oder gingen bankrott. Claude Opus 4.7 überlebte zwar in allen Läufen die kompletten 500 Tage, endete aber mit nur rund 390.000 Dollar. Grok 4.20 hielt es im besten Fall gerade einmal 37 Tage durch, DeepSeek V4 Pro maximal 176 Tage.

Weiterlesen nach der Anzeige

Die erfolgreichen Modelle gingen für ihren Erfolg sehr unterschiedlich vor. Claude Opus 4.8 verfolgte in einem Run eine radikale Harvesting-Strategie: zunächst aggressiver Kundenaufbau, dann drastische Kostenschnitte – am Ende stand eine hohe Cash-Bilanz bei null aktiven Kunden. Ziel erreicht, im echten Leben wäre das jedoch nichts wert gewesen. GPT-5.5 setzte hingegen auf einen dauerhaften Kundenstamm und investierte rund 89 Prozent seines Entwicklungsbudgets in gruppenspezifische Verbesserungen. Beide Modelle schrieben eigenständig Code-Dateien: Opus 4.8 baute eine kohortenbasierte Cash-Prognose, GPT-5.5 analysierte Verhandlungshistorien, um Kundenpräferenzen abzuleiten.

Die Varianz zwischen den Läufen desselben Modells ist ebenfalls groß. GPT-5.5 zum Beispiel schwankte zwischen frühen Bankrotten nach 77 Tagen und einem vollständigen 500-Tage-Lauf. Einzelne Runs liefern daher kein stabiles Leistungsbild. Selbst in einer auf 50 Tage verkürzten Variante scheiterten die meisten Agenten – was nahelegt, dass nicht nur der lange Horizont, sondern die grundsätzliche Entscheidungskoordination unter Unsicherheit ein Problem für sie darstellt.

Das Ergebnis passt ins Bild aktueller Forschung zur Langzeit-Kompetenz von KI-Modellen. Im Projekt „Emergence World“ durften Modelle wie ChatGPT, Grok, Claude und Gemini simulierte Städte regieren – mit teils bizarren Resultaten: Gemini 3 Flash schuf eine Hochkriminalitäts-Welt, Claude Sonnet 4.6 baute einen nahezu konfliktfreien „Ponyhof“. Auch dort zeigte sich, dass die Modelle in offenen Langzeit-Szenarien zu unvorhersehbarem Verhalten neigen. Man muss allerdings bei beiden Simulationen anfügen: Die getesteten KIs waren keine Weltmodelle, sondern überwiegend Reasoning-Modelle, die mutmaßlich nicht ideal für solche Aufgaben sind.


(rie)



Source link

Weiterlesen

Beliebt