Die fünfte Vorschauversion der kommenden .NET-Version 11.0 ist gestern Abend erschienen. Parallel dazu gab es auch die Version 11904.113 der für .NET 11.0 notwendigen Insiders-Variante von Visual Studio 2026. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.

Sortieren und Paging beim bei Blazor Static SSR

Bei dem in .NET 8.0 eingeführten statischen serverseitigen Rendering (Blazor Static SSR), das als eine Ablösung für ASP.NET Core MVC und ASP.NET Core Razor Pages verstanden werden kann, funktioniert das Tabellensteuerelement QuickGrid, das Microsoft im NuGet-Paket Microsoft.AspNetCore.Components.QuickGrid liefert, bisher nur eingeschränkt. Lediglich bei den interaktiven Varianten Blazor Server und Blazor WebAssembly sowie Blazor Hybrid stehen alle Funktionen des QuickGrid-Steuerelements zur Verfügung.

Seit Blazor 11.0 Preview 5 ist es möglich, dass das QuickGrid-Steuerelement auch in statisch serverseitig gerenderten Blazor-Seiten sortieren und blättern kann. Wenn das Grid nicht interaktiv ist, werden die sortierbaren Spaltenüberschriften und die Seitennavigation als erweiterte HTML-Formulare gerendert, die ihren Zustand über URL-Abfrageparameter (Query String) übertragen. Lädt eine Nutzerin oder ein Nutzer die Seite neu oder kopiert die URL und öffnet sie erneut, bleiben Sortierung und aktuelle Seite erhalten. Dadurch lassen sich diese Zustände einfach per URL teilen oder als Lesezeichen speichern.

Im Schnelltest zeigte sich: In Zusammenarbeit mit Entity Framework Core als Datenquelle mit Paging in der Datenbank erzeugt das Blättern einen Laufzeitfehler: „InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.“

Das folgende Beispiel funktioniert aktuell nur korrekt, wenn es immer alle Datensätze lädt und das Paging im RAM ausführt via

private List flightSet => context.Flights.ToList();

@page "/QuickGridSSR"
@using Microsoft.AspNetCore.Components.QuickGrid
@using Microsoft.EntityFrameworkCore
@inject IDbContextFactory DbFactory
@implements IAsyncDisposable
 
QuickGrid SSR
 

 

  p.FlightNo)" Title="FlugNr" Sortable="true" />
  p.Departure)" Title="Abflugort" Sortable="true">
 
  p.Destination)" Title="Zielort" Sortable="true">
  
  p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
  p.FreeSeats)" Title="Freie Plätze" />

 

 
@code {
 private readonly PaginationState pagination = new() { ItemsPerPage = 15 };
 
 private DA.WWWings.WwwingsV1EnContext context;
 private IQueryable flightSet => context.Flights;
  
 protected override void OnInitialized()
 {
  context = DbFactory.CreateDbContext();
 }
 
 // IAsyncDisposable implementieren, um den DbContext korrekt zu verwerfen, wenn die Komponente nicht mehr benötigt wird
 public async ValueTask DisposeAsync()
 {
  if (context != null)
  {
   await context.DisposeAsync();
  }
 }
}

Listing: QuickGrid mit Blazor Static SSR mit Zugriff auf eine Datenbank via Entity Framework Core

Vereinfachte Session-Handhabung

Blazor Static SSR unterstützt seit der Einführung in .NET 8.0 die in ASP.NET Core verfügbaren serverseitigen Sessions (Cookie .AspNetCore.Session mit Session-ID, Speicherung der Daten im RAM oder einem persistenten Speicher) zur Datenübergabe zwischen Seiten. Bisher mussten Entwicklerinnen und Entwickler dafür das Session-Objekt im HttpContext-Objekt verwenden und komplexe Objekte selbst per JSON serialisieren:

@inject IHttpContextAccessor HttpContextAccessor
…
var HttpContext = HttpContextAccessor.HttpContext;
var json = System.Text.Json.JsonSerializer.Serialize(regForm);
HttpContext.Session.SetString("Formulardaten", json);

beziehungsweise

BO.RegistrationData daten = 
    System.Text.Json.JsonSerializer.Deserialize(
        HttpContext.Session.GetString("Formulardaten") ?? string.Empty);

In .NET 11.0 Preview 5 hat Microsoft nun die Annotation [SupplyParameterFromSession] eingeführt, die die Handhabung von Session-Variablen genauso einfach macht wie von Query-String-Parametern [SupplyParameterFromQuery], Form-Daten [SupplyParameterFromForm] und TempData-Werten [SupplyParameterFromTempData], wobei letztere Annotation erst in .NET 11.0 Preview 4 eingeführt wurde.

Entwicklerinnen und Entwickler annotieren in einer Seite eine oder mehrere Properties mit der Annotation [SupplyParameterFromSession]. Dabei sind einfache und komplexe Datentypen möglich, während [SupplyParameterFromTempData] auch in Preview 5 weiterhin nur mit einfachen Datentypen funktioniert:

[SupplyParameterFromSession]
public string Message { get; set; }
[SupplyParameterFromSession] 
public BO.RegistrationData RegData { get; set; }

Session-Werte werden dabei automatisch mit System.Text.Json in JSON serialisiert.

Analoge Properties deklarieren Entwicklerinnen und Entwickler in den Folgeseiten und können dann auf die Werte ohne weiteres Zutun zugreifen. Voraussetzung ist wie bisher, dass in der Startseite die Sessions aktiviert wurden:

builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();
…
app.UseSession();

Google entfernt in Chromium nun auch die letzten internen Schalter, mit denen sich Erweiterungen auf Basis von Manifest V2 (MV2) bislang noch am Leben halten ließen. Wie aus einer Mitteilung des Chrome-Teams an die W3C WebExtensions Community Group hervorgeht, hat Chromium 150 das Flag kExtensionManifestV2Disabled verloren. Mit Chromium 151 sollen die Optionen ExtensionManifestV2Unsupported, ExtensionManifestV2Availability und voraussichtlich AllowLegacyMV2Extensions folgen. Damit verlieren auch die bekannten Umgehungslösungen, mit denen sich die klassische Vollversion des Werbe- und Inhaltsblockers uBlock Origin in Chrome erzwingen ließ, schrittweise ihre technische Grundlage.

Was hinter Manifest V2 und V3 steckt

Manifest V2 und sein Nachfolger Manifest V3 (MV3) beschreiben, welche Schnittstellen Browser-Erweiterungen nutzen dürfen. Die klassische Version von uBlock Origin basiert weiterhin auf MV2. Google startete den Übergang zu MV3 in Chrome ab Oktober 2024 schrittweise und schloss ihn mit Chrome 138 im Juli 2025 endgültig ab, wodurch die Vollversion von uBlock Origin für Chrome-Nutzer offiziell nicht mehr verfügbar ist.

Kern der Umstellung ist der Ersatz der mächtigen webRequest-API durch das eingeschränktere declarativeNetRequest-Modell, was Google mit Sicherheits-, Stabilitäts- und Performancevorteilen begründet. Für MV3 existiert mit uBlock Origin Lite eine eigenständige, bewusst funktionsreduzierte Variante des Blockers; sie stößt jedoch an die Grenzen bei den Filterregeln in declarativeNetRequest und bietet nicht die dynamischen Filterfähigkeiten der Vollversion.

Vom Policy-Ende zur Abschaltung im Code

Die jetzt diskutierten Änderungen markieren das Ende eines mehrstufigen Abschaltprozesses. In einem ersten Schritt hatte Google den klassischen MV2-Erweiterungen bereits den offiziellen Boden entzogen: Laut der Chrome-Dokumentation zur MV2-Abschaltung ist Chrome 138 die letzte Version, die MV2-Erweiterungen in Verbindung mit der Enterprise-Richtlinie ExtensionManifestV2Availability unterstützt. Mit Chrome 139 wurde diese Richtlinie entfernt. Die Policy war primär für verwaltete Unternehmensumgebungen gedacht, wurde aber auch von technisch versierten Anwendern genutzt, um die Nutzung älterer Erweiterungen über den ursprünglich vorgesehenen Zeitraum hinaus zu verlängern.

Genau auf dieser offiziellen Richtlinie beruhte die häufig als „Registry-Hack“ bezeichnete Umgehungslösung. Unter Windows ließ sich ExtensionManifestV2Availability über Gruppenrichtlinien oder Registry-Einträge setzen und die Abschaltung von MV2 so zeitweise aufschieben. Google hatte diese Möglichkeit jedoch von Anfang an als befristete Übergangsmaßnahme beschrieben: Unternehmen, die die Policy nutzten, erhielten laut Chrome-Entwicklerblog ein zusätzliches Jahr bis Juni 2025 zur Migration. Mit dem Wegfall der Richtlinie ab Chrome 139 verlor dieser Weg seine Grundlage.

Die nun an die WebExtensions Community Group gemeldeten Schritte setzen tiefer an: Statt nur die Verfügbarkeit über Policies zu steuern, entfernt das Chrome-Team die zugrunde liegenden Feature-Flags und Codepfade. Begleitend nennen Google-Entwickler in der Diskussion technische Komplexität, technische Schulden und Sicherheitsrisiken – darunter MV2-spezifische Bugs – als Gründe für die Entfernung der MV2-Unterstützung.

Wo die Vollversion noch läuft

An der Plattformfrage selbst ändert sich nichts: Die klassische Version von uBlock Origin wird vom Entwickler weiterhin als MV2-Erweiterung gepflegt, eine vollwertige MV3-Portierung existiert nicht. Für Chromium-basierte Browser verweist das Projekt stattdessen auf uBlock Origin Lite. Wer den vollen Funktionsumfang behalten will, ist laut Projektangaben auf Browser angewiesen, die MV2 weiterhin zulassen.

Die Vollversion läuft weiterhin auf Firefox und auf Brave. Mozilla unterstützt MV2 und MV3 ausdrücklich parallel. Die Erweiterungen für Firefox sind von der Chrome-Abschaltung nicht betroffen, der Browser behält die blockierende webRequest-API, wie auch eine Übersicht zur MV3-Auswirkung festhält. Brave wiederum unterstützt MV2 browser-seitig prinzipiell (force-enabled): Laut Brave-Blog hostet Brave gezielt vier Extensions (AdGuard, NoScript, uBlock Origin, uMatrix) selbst.

Bei den übrigen Chromium-Browsern ist der Stand uneinheitlich. Opera unterstützt nach eigenen Angaben weiterhin bestehende Manifest‑V2‑Erweiterungen und will das so lange wie möglich fortsetzen. Bei Edge ist die Lage weiterhin uneinheitlich: Microsoft dokumentiert die Abschaffung von Manifest V2, hat aber die konkrete Zeitlinie lange offen gelassen; ob und wie lange uBlock Origin in voller Version unterstützt bleibt, ist damit nicht eindeutig festgelegt. Ob und wie lange weitere Browser-Projekte eigene Kompatibilitätslösungen aufrechterhalten, dürfte davon abhängen, in welchem Umfang sie bereit sind, von Googles Chromium-Basis abzuweichen und die entsprechenden Komponenten selbst weiterzupflegen – so wie es Brave mit seinen hartkodierten Ausnahmen vormacht.

Welche Optionen Nutzern bleiben

Für Nutzer markiert die Entfernung der MV2-Flags in Chromium 150 und 151 damit die letzte Phase einer seit Jahren laufenden Umstellung. Während Google die alte Erweiterungsplattform endgültig auslaufen lässt, bleiben im Wesentlichen drei Alternativen: der Wechsel auf MV3-Alternativen wie uBlock Origin Lite, der Umstieg auf Brave mit seiner weiterhin aktiven MV2-Unterstützung oder der Wechsel zu Firefox mit eigenem Plattformmodell und voller webRequest-Unterstützung.

(fo)

Datadog hat auf seiner jährlichen Hauskonferenz DASH zahlreiche neue Funktionen für seine Observability- und Sicherheitsplattform angekündigt. Im Zentrum stehen der KI-Agent Bits AI SRE, das Tool AI Guard zum Schutz von KI-Anwendungen sowie ein neues Bereitstellungsmodell namens Bring Your Own Cloud Logs (BYOC Logs), bei dem Kunden ihre Log-Daten in eigenen Speichersystemen belassen können.

Wie Datadog in seiner DASH-2026-Ankündigung erklärt, sollen die Neuerungen Unternehmen helfen, die immer schneller verlaufende Softwareentwicklung sowie die wachsende Komplexität KI-geprägter IT-Landschaften besser zu beherrschen. Chief Product Officer Yanbing Li zufolge sei es das erklärte Ziel, dass Unternehmen nicht nur bessere Modelle bauen, sondern „operative Kontrolle rund um diese Systeme“ schaffen.

Bits AI SRE: Agentischer Ansatz statt klassischer AIOps

Datadogs bereits im vergangenen Jahr angekündigter KI-Agent Bits AI SRE soll weit über die Möglichkeiten klassischer AIOps-Ansätze hinauswirken. Er soll sich damit von konkurrierenden Angeboten etwa von Dynatrace, Splunk oder Elastic abheben, die noch vorwiegend auf regelbasierte Korrelations-Engines und Mustererkennungen über Alerts bauen. Bits AI arbeite wie ein „agentischer Teamkollege“, der sich kontinuierlich den Kontext der gesamten Datadog-Telemetrie zunutze mache. Das System bildet eigenständig mehrere Root-Cause-Hypothesen, testet diese über gezielte Abfragen und klassifiziert sie als validiert, invalidiert oder unklar. Dabei greift der Agent auf Metriken, Logs, Traces, Topologiedaten und verknüpfte Runbooks zurück – etwa aus Confluence – und führt explorative Queries über die gesamte Umgebung aus. Laut Datadog beschleunige Bits AI SRE die Root-Cause-Identifikation nicht nur signifikant, sondern ermögliche tatsächlich autonome Betriebsabläufe.

Den KI-Agenten positioniert Datadog als modellagnostische Orchestrierungsschicht über große Sprachmodelle. Welche Foundation-Modelle konkret zum Einsatz kommen, verrät der Hersteller jedoch nicht. Da in anderen Produktbereichen allerdings Integrationen mit OpenAI sowie Anbindungen an Entwicklertools wie Claude Code von Anthropic existieren, liegen Kooperationen mit OpenAI und Anthropic nahe.

Automatisierte Remediation mit konfigurierbaren Leitplanken

Vollständig automatisierte Behebungsmaßnahmen ohne menschliche Freigabe sind mit dem neuen Bits Agent Builder möglich: Teams können eigene KI-Agenten erstellen, die Remediation-Workflows wie Rollbacks, Neustarts oder Feature-Flag-Rollouts automatisieren. Datadog betont dabei, dass sämtliche Aktionen nur innerhalb kundenseitig definierter Leitplanken erfolgen – etwa per RBAC, Policy-Engines, Audit-Logging und verpflichtender Genehmigung durch On-Call-Personal. In sicherheitskritischen Umgebungen, etwa im Finanzsektor, empfiehlt Datadog einen Assistenzmodus, in dem Bits AI SRE zwar vorschlägt und dokumentiert, die finale Entscheidung aber beim Menschen verbleibt.

Für die Integration in bestehende ITIL- oder ISO-27001-konforme Prozesse, wie sie in größeren Unternehmen in der DACH-Region üblich sind, bietet Datadog Anbindungen an ServiceNow und Jira. Bits AI SRE fungiert dabei als erste Ermittlungsinstanz: Er nimmt Alerts auf, legt Cases an und erstellt strukturierte Incident-Reports mit Root Cause, Impact und Timeline. Formale Change-Management-Prozesse und Dokumentationspflichten bleiben allerdings beim Kunden – der KI-Agent versteht sich als Ergänzung, nicht als Ersatz für bestehende Governance-Strukturen.

AI Guard schützt KI-Agenten vor Prompt-Injection

Mit AI Guard reagiert Datadog auf die wachsenden Risiken rund um KI-Agenten, darunter versteckte, bösartige Prompt-Attacken, die Agenten zur Preisgabe sensibler Informationen veranlassen können. AI Guard kombiniert Telemetry Tracing mit zustandsbehafteter Verhaltensanalyse, um mehrstufige Angriffe und Prompt-Injection-Versuche über mehrere Interaktionen hinweg zu erkennen und zu blockieren – Angriffsmuster also, die bei zustandslosen Prompt-Response-Prüfungen unentdeckt blieben.

Die Policies lassen sich sprachunabhängig formulieren, etwa über Regex-Muster oder Klassifikatoren, die IBANs, E-Mail-Adressen oder Kundennummern unabhängig von der Sprache des Prompts erkennen. Insbesondere in mehrsprachigen Unternehmensumgebungen, in denen etwa deutschsprachige Benutzertexte und englische Systemlogs in gemischten Prompts aufeinandertreffen, hängt die Erkennungsqualität Datadog zufolge letztlich vom eingesetzten Sprachmodell ab. AI Guard gilt laut Ankündigung als LLM-agnostisch, die Integration erfolgt über SDKs für Python, JavaScript und Java.

BYOC und EU-Rechenzentren für mehr Datensouveränität

Mit Bring Your Own Cloud Logs (BYOC) widmet sich Datadog dem Problem der exponentiell wachsenden Log-Datenmengen durch KI-Workloads. In diesem Modell wird die Plattform in der Cloud-Umgebung des Kunden betrieben, Daten werden direkt im unternehmenseigenen Objektspeicher verarbeitet und indexiert, ohne sie in eine Datadog-zentrische Umgebung verschieben zu müssen. Sofern der gewählte Cloud-Provider es unterstützt, können DACH-Unternehmen ihre Observability-Daten damit potenziell ausschließlich in EU-Rechenzentren oder der seit 2018 bestehenden EU-Region in Deutschland halten. DSGVO-relevante Aspekte wie Auftragsverarbeitung und der Zugriff durch US-Anbieter bleiben zwar grundsätzlich bestehen, die Datenlokalisierung und BYOC weisen aber technisch den Weg zu mehr Souveränität.

Unter den weiteren Ankündigungen im Rahmen der DASH-Konferenz finden sich eine Agent Console, die zentrales Monitoring für KI-Agenten bietet und Entwicklertools wie Claude Code, Cursor und GitHub Copilot unterstützt. Das Modul Bits Detection erkennt eigenständig Anomalien und löst automatisch Untersuchungen aus, während Agent Evals dem Debuggen von KI-Agenten dient – einschließlich der von Kunden selbst erstellten.

(map)