.NET 11.0 Preview 7 gibt es kostenfrei zum Download bei Microsoft. Dabei handelt es sich um die letzte Preview-Version vor dem ersten Release Candidate. Parallel dazu ist ein Update für Visual Studio 2026 Insiders auf die Version 12106.202 erschienen.

Mehr Schleifenkontrolle: break und continue mit Bezeichnern

Die Sprachkonstrukte break zum Abbrechen und continue zum vorzeitigen Fortsetzen von Schleifen gibt es in den meisten Programmiersprachen, so auch in C# seit der ersten Version. Nun ergänzt Microsoft aber eine bislang in C# fehlende Option: Entwicklerinnen und Entwickler können hinter break und continue jeweils Namen angeben, die sich auf äußere Schleifen beziehen. Damit kann der Compiler nicht nur die jeweils direkt umgebende Schleife, sondern auch übergeordnete Schleifen abbrechen oder vorzeitig fortsetzen. Ein solches Label kann man bei den Schleifenkonstrukten for, foreach, while und do sowie bei der Verzweigung mit switch einsetzen.

Das folgende Listing zeigt dazu ein Beispiel, in dem vermieden wird, dass die drei Schleifenebenen jeweils einzeln abgebrochen werden müssen, wenn ein passender Regalplatz gefunden wurde.

public void Run()
 {
  List Gaenge = ["A", "B", "C", "D", "E"];
 
  // bool sackgasse = false; // --> nicht notwendig dank continue mit Label
  // bool gefunden = false; --> nicht notwendig dank break mit Label
 
 regalgangSchleife:
  foreach (var regalgang in Gaenge)
  {
   for (int regal = 1; regal <= 20; regal++)
   {
    for (int platz = 1; platz <= 50; platz++)
    {
     // Sackgasse: In einigen Regalen gibt es Sackgassen
     if (regal % 2 == 1 && platz % 13 == 0)
     {
      CUI.Warning($"Sackgasse: Gang={regalgang}/Regal={regal}/Platz={platz}");
      // sackgasse = true; --> nicht notwendig dank continue mit Label
      continue regalgangSchleife;
 
     }
     CUI.Print($"Prüfe Gang={regalgang}/Regal={regal}/Platz={platz}");
 
     bool istFrei = IstFrei(regalgang, regal, platz);
     bool istGrossGenug = IstGrossGenug(regalgang, regal, platz);
 
     if (istFrei && istGrossGenug)
     {
      CUI.Success($"Gefunden: Gang={regalgang}/Regal={regal}/Platz={platz}");
 
      // gefunden = true; --> nicht notwendig dank break mit Label
      break regalgangSchleife;
     }
    }
    // if (sackgasse) continue; --> nicht notwendig dank continue mit Label
    // if (gefunden) break; --> nicht notwendig dank break mit Label
   }
   // if (sackgasse) continue; --> nicht notwendig dank continue mit Label
   // if (gefunden) break; --> nicht notwendig dank break mit Label
  }
 }

Listing 1: Einsatz von Labels bei break und continue

Automatisches Pausieren für Blazor-Server-Anwendungen

Blazor Server ist eine Variante von Blazor, bei der C#-Programmcode auf dem Webserver läuft und den Webbrowser über eine Circuit genannte Websocket-Verbindung aktualisiert, sodass für Benutzer das Erlebnis einer Single-Page-Webanwendung entsteht. Eine Herausforderung ist bei Blazor Server stets der Ressourcenverbrauch auf dem Webserver, denn alle angeschlossenen Webbrowser teilen sich Prozessorleistung und RAM des Webservers.

Seit .NET 10.0 kann man jeden einzelnen Circuit per JavaScript-Code pausieren via Blazor.pauseCircuit() sowie den Zustand im RAM oder einer Datenbank persistieren und später wiedererwecken via Blazor.resumeCircuit(), um Ressourcen auf dem Webserver zu sparen, wenn ein Benutzer die Browserregisterkarte mit der Blazor-Anwendung verlässt. Seit .NET 11.0 Preview 4 ist das Pausieren von Circuits auch per C#-Code via RequestCircuitPauseAsync() möglich.

Die Einführung von RequestCircuitPauseAsync() war die Vorbereitung für das automatische Pausieren, das es nun in Preview 7 gibt. Entwicklerinnen und Entwickler können nun im Startcode einer Blazor-Server-Anwendung einstellen, dass die Anwendung pausiert, solange die Browserregisterkarte verdeckt ist. Dafür ist ein eigenes NuGet-Paket mit Namen Microsoft.AspNetCore.Components.Server.AutoPause zu ergänzen:

und der Startcode ist um den Aufruf AddAutoPause() zu erweitern:

app.MapRazorComponents()
    .AddInteractiveServerRenderMode()
    .WithBrowserOptions(options =>
    {
        options.AddAutoPause(pause =>
        {
            pause.HiddenDelay = TimeSpan.FromSeconds(60); // Standard: 2 Minuten
        });
    });

Im Standard geschieht das Pausieren nach zwei Minuten. Diese Zeit können Entwicklerinnen und Entwickler mit HiddenDelay ändern. Blazor Server hält sich aber nicht akribisch an die definierte Zeitspanne. So wird die Zeit verlängert, wenn ein Eingabesteuerelement neue Werte enthält, wenn die Seite Audio- oder Videoinhalte mit Ton abspielt oder wenn ein JavaScript-Aufruf läuft.

Zu beachten ist, dass sich eine Komponente beim Schlafenlegen nur die Werte der mit [PersistentState] annotierten Eigenschaften oder manuell im Persistent Component State gespeicherten Objekte merkt.

CacheView für Blazor Static SSR

Bei dem in .NET 8.0 eingeführten statischen serverseitigen Rendering (Static SSR), das man als Ablösung für ASP.NET Core MVC und ASP.NET Core Razor Pages verstehen kann, schließt Microsoft in .NET 11.0 Preview 7 eine weitere Lücke: Analog zu dem Tag Helper in den älteren Webframeworks gibt es jetzt in Blazor eine neue eingebaute Komponente . Diese Komponente merkt sich den gerenderten Inhalt für eine bestimmte Zeit und rendert den Inhalt erst nach dem Ablauf erneut. Die Zeitspanne können Entwicklerinnen und Entwickler flexibel durch

• ExpiresAfter: Zeitspanne seit dem ersten Zugriff
• ExpiresOn: fester Zeitpunkt oder
• ExpiresSliding: Zeitspanne seit dem letzten Zugriff

angeben.

Mit VaryByRoute und VaryByQuery sowie VaryByUser und VaryByCulture lässt sich festlegen, dass es abweichende Zwischenspeicher für verschiedene Parameter in URL und QueryString beziehungsweise Benutzer und Sprachen geben soll.

In zwei Fällen funktioniert die -Komponente nicht:

1. wenn die HTTP-Anfrage ein anderes Verb als GET verwendet oder
2. wenn Stream Rendering aktiv ist, mit @attribute [StreamRendering].

Zudem lässt sich das Zwischenspeichern mit der Eigenschaft enabled="false" manuell deaktivieren.

Die von Microsoft gelieferte Razor-Komponente funktioniert nicht innerhalb eines -Elements:

"InvalidOperationException: Component 'Microsoft.AspNetCore.Components.Web.Virtualization.Virtualize`1[[System.DateTime' cannot be used inside a CacheView because its output depends on per-request state ([CacheBehavior(CacheBehavior.Throw)]) that cannot be safely cached and replayed. To fix this, move the component outside the CacheView."

Die Komponente funktioniert nur mit VaryByUser="true" und das -Tabellensteuerelement nur mit VaryByQuery.

Selbsterstellte Komponenten können mit @attribute [CacheBehavior(CacheBehavior.Throw)] angeben, dass sie nicht im funktionieren wollen. Mit @attribute [CacheBehavior(CacheBehavior.Rerender)] werden Komponenten trotz immer neu gerendert. Das geschieht auch mit den eingebauten Komponenten und .

Zwischenspeicher ist im Standard der RAM des Webservers. Durch Einsatz des NuGet-Pakets Microsoft.Extensions.Caching.Hybrid sind auch andere Speicher (etwa Redis, Datenbankmanagementsystem) als Zwischenspeicher möglich.

@page "/Cache"
@page "/Cache/{URLID:int}"
 
@code
{
 [Parameter]
 [SupplyParameterFromQuery]
 public int URLID { get; set; }
 
 [Parameter]
 [SupplyParameterFromQuery]
 public int QueryID { get; set; }
}

 URLID: @URLID
QueryID: @QueryID
zuletzt aktualisiert am @DateTime.Now

 

/1
/2
/3
/4
/5

QueryID=1
QueryID=2
QueryID=3
QueryID=4
QueryID=5

Listing 2: Beispiel für den Einsatz von

Neue Analyzer schützen vor Fehlern

Fünf neue in Blazor eingebaute Analyzer warnen Entwicklerinnen und Entwickler vor falschem Programmcode:

• BL0012 warnt, wenn ein Aufruf von StateHasChanged() nicht notwendig ist, zum Beispiel in OnInitialized(), OnInitializedAsync() und Ereignisbehandlungen.
• Wenn GetAuthenticationStateAsync() aufgerufen wird, ohne das Ereignis AuthenticationStateChanged() zu abonnieren, warnt BL0013, weil dadurch eine Komponente mit einem veralteten Authentifizierungsstatus arbeiten kann.
• BL0014 warnt, wenn eine Zählvariable einer for-Schleife von einer Closure oder einem Render-Fragment erfasst wird. Dadurch können alle Callbacks oder Fragmente auf den Wert der letzten Iteration verweisen.
• Eine mit [JSInvokable] markierte Methode ist nicht öffentlich. Sie lässt sich zwar kompilieren, kann aber nicht aus JavaScript aufgerufen werden. Der Analyzer BL0015 bietet einen Code-Fix an, der die Methode public macht.
• Wenn InvokeAsync() oder InvokeVoidAsync() außerhalb eines try-catch-Blocks aufgerufen wird, warnt BL0016. Bei einer unterbrochenen Blazor-Verbindung oder einer JavaScript-Ausnahme kann dadurch die Komponente beziehungsweise der Circuit beendet werden.

Union Types als Parameter

Blazor-Komponenten sollen laut Release Notes nun auch mit Union Types, die in Preview 3 eingeführt wurden, als Parameter reibungslos funktionieren. Im Schnelltest mit dieser Komponente

@code {
 
 public union ContentUnion(string, RenderFragment);
 
 [Parameter]
 public ContentUnion? Header { get; set; }
 
 [Parameter]
 public ContentUnion? Content { get; set; }
}
 

 
@Header.Value
 @Content.Value

Listing 3: Message.razor

und diesem Aufruf

 
@DateTime.Now.ToShortDateString()
 Dies ist fett und das ist kursiv!

gab es jedoch stets den Laufzeitfehler

InvalidOperationException: Object of type 'Message' does not have a property matching the name 'ChildContent'.

Die Komponente Message.razor funktioniert hingegen reibungslos, wenn man die Parameter auf RenderFragment statt auf ContentUnion typisiert.

Zahlreiche Breaking Changes gegenüber den vorherigen Preview-Versionen

Wer schon Blazor-Anwendungen mit in vorherigen Preview-Versionen eingeführten Validierungs-Features nutzt – wie der clientseitigen Validierung, vereinfachten Lokalisierung von Validierungs-Fehlermeldungen und der asynchronen Validierung –, muss in Preview 7 vieles am Programmcode ändern, denn Microsoft hat die APIs noch einmal überarbeitet.

Ob beim statischen serverseitigen Rendern die clientseitige Validierung aktiv ist, steuert man nun nicht mehr über EnableClientValidation="true", sondern über DisableClientValidation="false".

Bei der Lokalisierung ist AddValidationLocalization() entfallen; stattdessen gibt man die Ressource (.resx-Datei) mit den lokalisierten Fehlermeldungen nun bei AddValidation() an:

builder.Services.AddValidation(options =>
{
    options.LocalizerProvider = (_, factory) => factory.Create(typeof(ValidationMessages));
});

Zum Glück radikal vereinfacht hat Microsoft die asynchrone Validierung, die in Preview 5 eingeführt wurde und sehr komplex war.

Nun in Preview 7 lassen sich asynchrone Validierungsannotationen schreiben, indem man von der Basisklasse AsyncValidationAttribute erbt. Diese asynchronen Validierungsannotationen verwendet man in einem Objektmodell, das man als EditContext für ein Formular verwendet. Dann kann man in der Instanz von EditContext via IsValidationPending() und IsValidationFaulted() den Status der Validierung abfragen.

Die Annotationen [ValidatableType] und [SkipValidation], die es seit .NET 10.0 gibt und seitdem als experimentell galten, erzeugen nun keine solche Warnung mehr.

In .NET 11.0 Preview 6 hatte Microsoft in der Komponente das programmgesteuerte Scrolling zu einer bestimmten Position eingeführt. Dafür gab es die neue Eigenschaft InitialIndex für die Startposition und die neue Methode ScrollToIndexAsync() für eine Bewegung zur Laufzeit. Nun wurde die Eigenschaft in InitialItemIndex und die Methode in ScrollToItemAsync() umbenannt. Das -Steuerelement bietet ab Preview 7 auch InitialItemIndex und ScrollToItemAsync an.

Zahlreiche weitere Breaking Changes in ASP.NET Core 11.0 Preview 7 findet man in den Release Notes.

Bei einem Lieferkettenangriff auf die populäre LiteLLM-Bibliothek im März dieses Jahres haben Angreifer im Python Packages Index (PyPI) kompromittierte Pakete eingeschleust. Diese wurden offenbar von automatisierten Build-Systemen zigtausendfach heruntergeladen und verwendet, bei mehr als 2500 auch namhaften Unternehmen – obwohl die kompromittierten Pakete lediglich 40 Minuten online waren.

Die Angreifer haben potenziell rund 434.000 automatisierte Entwickler-Build-Pipelines unterwandert, die bei mehr als 2500 Firmen zum Einsatz kommen, führen die IT-Sicherheitsforscher von CloudSEK in einem Blogbeitrag aus. Die Daten deuten darauf hin, dass Angreifer darauf hätten zugreifen können, belegen jedoch nicht, dass sie das auch getan haben und dass alle Zugangsdaten entwendet wurden. Laut den Analysten ist die Bedrohung noch immer aktuell, da auch das FBI im Juli davor gewarnt hat, dass mit der Cybergang TeamPCP verbundene Akteure die gestohlenen Zugangsdaten wahrscheinlich noch lange nach dem eigentlichen Angriff missbrauchen. Daher sollten potenziell Betroffene Sicherheitsmaßnahmen wie Ändern der Zugangsdaten, Schließen der möglichen Schwachstelle und Härtung der Systeme ergreifen, empfehlen die IT-Forscher.

Die Auflistung betroffener Unternehmen führt einige große und namhafte Firmen auf. Airbus, Amazon Web Services, Cisco, Hoffmann-La Roche AG, Salesforce, Samsung, ServiceNow, Siemens, aber auch Epic Games, FedEx, der Rückversicherungsriese Munich Re, die Robert Bosch GmbH, Thales Group, Volkswagen AG oder X Corp tauchen dort auf. Von denen und vielen weiteren haben die Angreifer teils Geheimnisse wie Zugangsdaten ergattert, in allen Fällen liefen jedoch in den automatisierten KI-Build-Systemen die kompromittierten Versionen – zum Teil tausende Male.

Entwendete Objekte

Zu den geklauten Daten zählen laut CloudSEK Cloud-Keys, Repository-Token, SSH-Keys, Kubernetes-Secrets, Zugangsdaten für Paket-Publishing, Umgebungsvariablen und KI-Anbieter-Keys. Das Entfernen der bösartigen Pakete allein reicht daher nicht, da derartige Zugangsdaten noch Wochen oder Monate nutzbar bleiben, sofern sie nicht geändert und Hinweise auf unbefugte Aktivitäten untersucht werden.

Die Infostealer-Malware, die Google „Sandclock“ nennt, lief auf kompromittierten Build-Systemen, weitete ihre Rechte zu root aus und suchte dann nach den Daten. Insbesondere auf KI-Build-Systemen sucht sie nach LLM-API-Keys und Gateway-Konfigurationen. Die Daten haben die Angreifer mit AES-256 und einem fest einprogrammierten RSA-4096-Key verschlüsselt und an Server gesendet, die eine Typosquatting-Domain nutzten. Wenn das Ausschleusen fehlschlägt, legt die Malware ein öffentliches Repository innerhalb des GitHub-Kontos der Opfer an und verfrachtet die Daten dorthin.

CloudSEK gibt in der Analyse noch weitere Tipps und Hinweise für Admins, wie sie eine Kompromittierung aufspüren, eindämmen und wie sie sich vor den Attacken schützen können.

(dmk)

Docker hat eine neue, selbst entwickelte Virtualisierungsschicht, Docker Virtual Machine Manager (VMM) 4.86, angekündigt. Sie soll effizienter, schneller und besser zu managen sein als die bisherigen Komponenten.

Docker VMM 4.86 ersetzt die bisherigen Virtualisierungen libkrun unter macOS und WSL 2 unter Windows. Als Vorteile hebt Docker hervor, dass VMM dem Host beim Speichermanagement ungenutzten Speicher automatisch zurückgibt, wenn Container nicht aktiv sind. So belegt Docker Desktop Arbeitsspeicher nur während deren Aktivität. Außerdem verbessert der VMM den Datenaustausch zwischen Host und Container, indem sich Latenzzeiten reduzieren. Schließlich soll die neue Technik die Startzeit der Engine und der Container verkürzen.

Speziell unter Windows soll die neue Engine die Stabilität verbessern und die volle Isolation von Hyper-V mit der Geschwindigkeit von WSL2 kombinieren.

VMM in Version 4.86 verlangt mindestens 4 GB Arbeitsspeicher auf der Linux-Maschine. Nach dem Wechsel ist unter Umständen ein Neustart nötig. Ein Problem gibt es noch mit Bind Mounts bei Auto-Shares: Tritt der Fehler „file is not shared from the host“ auf, ist eine händische Freigabe erforderlich.

Die neue Virtualisierung liegt auch den Docker Sandboxes (SBX) zugrunde und soll auf Dauer als Basis für eine plattformübergreifende, einheitliche Runtime dienen. Die allgemeine Verfügbarkeit ist für Ende Oktober 2026 geplant und VMM soll dann standardmäßig bei Docker Desktop aktiv sein.

(who)