Um beispielsweise eine priorisierte Liste von Aufgaben zu ermitteln, bei der die Aufgaben einer Reihe von Projekten zugeordnet sind, lässt sich die in Listing 1 gezeigte Abfrage verwenden: Eine Query nach den unerledigten To-dos aller aktiven Projekte (nicht „on hold“), sortiert nach Priorität und Deadline (falls gesetzt), lässt sich wohl kaum prägnanter ausdrücken.

from p in Projects
where !p.IsOnHold
from t in p.Todos
where !t.IsDone
orderby t.Priority descending, t.Deadline ?? EndOfTime
select t

Von Anfang an war es ein wichtiges Ziel, diese Abfragen analysieren zu können, um daraus beispielsweise SQL-Statements zu generieren – ein Ansatz, der mit dem Entity Framework Core im Grunde seither unverändert eine sehr hohe Verbreitung gefunden hat. Doch während die Querysyntax aus Datenbankabfragen kaum mehr wegzudenken ist, hat sie bei der Implementierung von Nutzerschnittstellen kaum Einzug gehalten.

Das ist schade, denn solche Abfragen wären auch bei der Entwicklung grafischer Benutzeroberflächen nützlich. In einer Anwendung zur Aufgabenverwaltung wäre es beispielsweise dienlich, eine priorisierte Liste von Aufgaben angezeigt zu bekommen, die sich sofort aktualisiert, wenn der Nutzer Änderungen vornimmt, die sich auf die Reihenfolge der Aufgaben auswirken.

Auch abseits von Nutzerschnittstellen möchte man manchmal wissen, wann und wie sich das Ergebnis einer Query ändert, um automatisiert Maßnahmen anstoßen zu können. Beispielsweise könnte man durch eine Query ermittelte Defekte automatisch korrigieren oder eine KPI in einem definierten Zielkorridor halten wollen.

Ein Beispiel für eine Bibliothek, die genau diese Funktionalität ermöglicht und sowohl .NET 8, 9 und 10 als auch .NET Standard 2.0 und somit auch das .NET-Framework unterstützt, ist die unter New-BSD lizenzierte Open-Source-Bibliothek NMF Expressions[1], [2]. In diesem Artikel wird beschrieben, wie diese Bibliothek funktioniert und wie sie dabei helfen kann, Data Binding gegen Querys zu ermöglichen.

INotifyPropertyChanged und INotifyCollectionChanged

Der Grund, warum Queries trotz ihrer guten Les- und Wartbarkeit nicht bei Nutzeroberflächen eingesetzt werden, ist meist, dass die XAML-basierten UI-Frameworks in .NET (WPF, MAUI, Avalonia, Uno) auf die Schnittstellen INotifyPropertyChanged und INotifyCollectionChanged angewiesen sind, um zu erkennen, welche Teile der UI wann aktualisiert werden müssen. Die Schnittstelle INotifyPropertyChanged erlaubt es hierbei, sich per Event benachrichtigen zu lassen, wenn sich das Ergebnis einer Eigenschaft ändert, wohingegen INotifyCollectionChanged über Änderungen an Auflistungen informiert. Beide Schnittstellen sind bereits seit dem .NET-Framework 3.0 Teil der Basisklassenbibliothek; es gibt sie sogar schon länger als die Querysyntax. Um die Implementierung von INotifyPropertyChanged für eigene Klassen zu unterstützen, gibt es seit einiger Zeit auch das MVVM Community Toolkit, das den notwendigen Boilerplate-Code zur Unterstützung von INotifyPropertyChanged generieren kann. Doch was ist mit INotifyCollectionChanged?

Für diese Schnittstelle gibt es im Framework nur genau eine einzige Implementierung: die ObservableCollection. Das Problem aber ist, dass LINQ-to-Objects-Querys diese nicht verwenden und Querys daher nicht für Data Binding genutzt werden können.

Data Binding an eine Query erfordert manuelle Synchronisation

Um das Ergebnis einer Query also in einer Nutzerschnittstelle anzeigen zu können, müssen die Ergebnisse manuell in einer ObservableCollection gepuffert werden. Bei jeder Änderung von Daten müssen Entwickler:innen also dafür sorgen, dass dieser Puffer aktualisiert wird. Dabei zählt Cache Invalidation nach Phil Karlton zu den schwierigsten Dingen der Informatik, da es kaum möglich ist, sicherzustellen, dass dies richtig erfolgt. Wenn der Puffer zu häufig aktualisiert wird, ist das eine Verschwendung von Ressourcen. Wenn er zu selten aktualisiert wird, können die Daten darin unter Umständen falsch sein. Hinzu kommt, dass sich in der Regel eine Vielzahl von Änderungen auf die Ergebnisse einer Query auswirken können. Wann immer ein Projekt oder To-do hinzugefügt oder gelöscht wird, ein Projekt auf „on hold“ gesetzt oder reaktiviert wird oder sich die Prioritäten oder Deadlines der einzelnen To-dos ändern, muss der Puffer entsprechend aktualisiert werden. All diese Szenarien müssen gut getestet werden. Die größte Gefahr besteht jedoch darin, irgendeine Art von Änderungen, die sich auf das Ergebnis der Query auswirken, zu vergessen.

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Inkrementalisierung

Wie lässt sich nun dieses Problem lösen, wie lassen sich Querys auch für Data Binding einsetzen, ohne dass Änderungen an der Query selbst vorgenommen werden müssen? Wenn sich eine Änderung im Modell ergibt, was genau soll dann neu berechnet werden? Neben der Frage nach dem Wann stellt sich auch die, wie die Puffer aktualisiert werden müssen – auch im Hinblick auf die algorithmische Komplexität. In manchen Fällen kann es zeitkritisch sein, nach der Änderung der eigentlichen Daten auch die aktualisierten Queryergebnisse zur Verfügung zu haben. Es kann schlicht zu lange dauern, dann immer die gesamte Query neu zu berechnen, gerade wenn sich nur ein sehr kleiner Teil der Daten geändert hat und die Teilergebnisse der Query eigentlich noch aktuell wären.

Wenn aber immer nur Teilergebnisse neu berechnet werden, bezeichnet man das als inkrementelle Ausführung, weil sich die Datenstruktur an inkrementell auftretende Änderungen anpassen muss. In der Algorithmik spricht man in diesem Zusammenhang auch von dynamischen Algorithmen, weil die Änderungen auch bedeuten können, dass Elemente gelöscht werden. Wenn sich ein solcher inkrementeller bzw. dynamischer Algorithmus ohne Zutun des Entwicklers von einer Spezifikation, beispielsweise einer Query, ableiten lässt, handelt es sich um eine implizite Inkrementalisierung; das Ergebnis ist eine implizit inkrementelle Query.

Damit das Ergebnis einer inkrementellen Query wohldefiniert ist, dürfen die eingesetzten Prädikate keine Seiteneffekte haben, die die Berechnung anderer Teilergebnisse beeinflussen, denn andernfalls wäre unklar, welche Seiteneffekte nach einer Änderung der zugrundeliegenden Daten ausgeführt wurden. Prädikate wie Filterbedingungen dürfen daher keine von außen sichtbaren Variablen oder andere Zustände verändern. Das ist bei Querys ohnehin eine übliche Annahme. Auch wenn man mittels PLINQ eine Query parallel ausführen möchte, sind seiteneffektbehaftete Prädikate keine gute Idee, da man sich sonst mit Thread-Synchronisation auseinandersetzen muss.

Als Nächstes müssen wir überlegen, welche API wir haben wollen. Das Ergebnis einer Query kann entweder ein einzelner Wert oder eine Auflistung sein. Während Auflistungen gewöhnlich ohnehin schon von Schnittstellen repräsentiert werden, kann ein einzelner Wert kaum für sich selbst die Schnittstelle INotifyPropertyChanged implementieren und muss daher in einer separaten Schnittstelle gekapselt werden.

Eine solche Schnittstelle ist in etwa in Listing 2 skizziert. Die einfachste denkbare Implementierung hierfür ist natürlich eine Konstante, bei der also Value immer genau den Wert der Konstante zurückliefert und das Event ValueChanged nie ausgelöst wird.

public interface INotifyValue<out T>
{
  T Value { get; }
  event EventHandler ValueChanged;
}

Generische Schnittstellen sind dabei ein Weg, mathematische Funktoren zu implementieren. Collections sind ein Beispiel für Funktoren, die in vielen Programmiersprachen auftreten. Da Schnittstellen andere Schnittstellen erben können, lässt sich der Funktor IEnumerable beispielsweise mit der Schnittstelle INotifyCollectionChanged kombinieren. In NMF heißt das Ergebnis INotifyEnumerable.

Ein Funktor besteht jedoch nicht nur aus einer Abbildung von Typen (wie string auf INotifyValue<string>), sondern auch aus einer Abbildung von Funktionen/Methoden. So muss es beispielsweise aus einer Funktion Func<string, int> eine Abbildung nach Func<INotifyValue<string>,INotifyValue<int>> geben. Für den Funktor IEnumerable übernimmt diese Abbildung der Queryoperator Select. Den ganzen Funktor für INotifyValue und INotifyEnumerable, also die Typabbildung und die Abbildung von Methoden, sowie die Abbildung Value zurück auf den derzeitigen Wert (in der Mathematik ist das eine natürliche Transformation), nennt man Inkrementalisierungssystem.

Um von einer Collection, die InotifyCollectionChanged, aber nicht INotifyEnumerable implementiert, auf letztere zu kommen, braucht man einen Adapter. In NMF Expressions nennt sich die Methode, die einen solchen Adapter erzeugen kann, WithUpdates.

Doch wie erreicht man eine solche Methodenabbildung für INotifyValue und INotifyEnumerable?

Dynamische Abhängigkeitsgraphen

Um immer nur die von einer Änderung tatsächlich betroffenen Teilergebnisse aktualisieren zu müssen, liegt es nahe, einen Abhängigkeitsgraphen zu halten, um entscheiden zu können, wann welche Teilergebnisse neu berechnet werden müssen. Um eine einheitliche Schnittstelle zu schaffen, verwenden die Teilergebnisse dieselben Schnittstellen wie die Endergebnisse, also INotifyValue und INotifyEnumerable. Da sich die Teilergebnisse normalerweise auf Teile der Daten beziehen (z. B., ob ein To-do noch unerledigt ist), variiert ihre Menge mit den Daten, ist also dynamisch; daher der Name „dynamischer Abhängigkeitsgraph“ [3].

Die einfachste Methode, um einen solchen dynamischen Abhängigkeitsgraphen zu erzeugen, besteht darin, eine Teilfunktion in ihre einzelnen Bestandteile, also die einzelnen syntaktischen Elemente, zu zerlegen. Auf dieser Ebene lässt sich leicht entscheiden, wann sich das Ergebnis ändert. Ändert sich beispielsweise das Bezugsobjekt für den Zugriff auf eine Property oder löst das aktuelle Bezugsobjekt ein Event über die INotifyPropertyChanged-Schnittstelle aus, dann könnte sich auch der Wert für den Zugriff auf die Property geändert haben. Doch wie kann man zur Laufzeit eine Funktion in ihre Bestandteile aufteilen?

Expression Trees als Grundlage für implizite Inkrementalisierung

In .NET lässt sich eine solche Dekomposition mit denselben Technologien bewerkstelligen, die ursprünglich für LINQ entwickelt wurden: Expression Trees erlauben es, zur Laufzeit auf den abstrakten Syntaxbaum einer Funktion zuzugreifen anstatt auf deren Kompilat. Dazu können Lambda-Ausdrücke vom Compiler nicht nur in Delegattypen wie Func<string> gecastet werden, sondern auch in Expression-Typen davon, wie Expression<Func<string>>. Im Entity Framework (Core) wird dieses Syntaxfeature, das nicht nur in C#, sondern auch in vielen anderen .NET-Sprachen existiert, dazu verwendet, aus einer Query SQL-Statements zu generieren. Mit Expression Trees lassen sich jedoch auch dynamische Abhängigkeitsgraphen erstellen.

NMF Expressions macht genau das: Es verwendet den Aufbau von Lambdaausdrücken, um daraus einen dynamischen Abhängigkeitsgraphen zu erzeugen und so die Schnittstellen INotifyValue und INotifyCollectionChanged zu implementieren.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Explizite Inkrementalisierung von Queryoperatoren

Dynamische Abhängigkeitsgraphen auf Basis einzelner Instruktionen haben zwei Nachteile: Zum einen werden sie sehr schnell sehr groß, zum anderen ist es nicht immer sinnvoll, auf Ebene der einzelnen Instruktionen zu überlegen, welche Instruktionen von einer Änderung genau betroffen sind. Stattdessen gibt es für einige Probleme dedizierte dynamische Algorithmen, die häufig deutlich effizienter sind, als es ein instruktionsbasierter Ansatz sein kann. Um beispielsweise die Summe oder den Mittelwert einer Menge von Zahlen dynamisch zu berechnen, ist es ausreichend, sich die aktuelle Summe (und im Fall des Mittelwerts zusätzlich die aktuelle Anzahl) zu merken und sie beim Hinzufügen oder Löschen einer Zahl entsprechend zu aktualisieren. Auf diese Weise lassen sich für viele Query-Operatoren sehr effiziente dynamische Algorithmen finden, insbesondere wenn die Reihenfolge der Ergebnisse keine Rolle spielt.

Die Bibliothek NMF Expressions bietet für viele der Standardqueryoperatoren (SQO) eine explizite Inkrementierung. Die SQO sind diejenigen Queryoperatoren, die von einigen Programmiersprachen mit einer eigenen Syntax versehen sind. Ob eine Programmiersprache für einen SQO eine spezielle Syntax anbietet, ist je nach Sprache verschieden. So bildet VB.NET den Operator Aggregate in einer eigenen Syntax ab, C# aber nicht.

Die Faustregel besagt, dass es für alle Queryoperatoren, die nicht indexbasiert sind, eine inkrementelle Variante gibt. Der Grund dafür ist, dass sich Indizes zu häufig ändern. Wenn ein neues Element eingefügt wird, ändert sich nämlich der Index für alle nachfolgenden Elemente. Eine so inkrementalisierte Query hätte daher wahrscheinlich eine schlechte Performance. Um das zu vermeiden, wird diese Funktionalität erst gar nicht angeboten.

Doch wie implementiert man eine explizite Inkrementalisierung einer Methode in NMF Expressions?

Eigene Funktionen explizit inkrementalisieren

Im Unterschied zu Lambdaausdrücken kann die Implementierung einer Methode nicht ohne Weiteres eingesehen werden, da sie per Reflection nur als Bytecode abrufbar ist. Daher benötigt ein Inkrementalisierungssystem eine Heuristik, wann sich das Ergebnis eines Methodenaufrufs potenziell ändert. Eine gute erste Heuristik ist, dass sich die Rückgabe einer Methode dann ändern könnte, wenn sich die Parameter ändern.

Wenn nun Teile einer Query in separate Methoden ausgelagert werden, ist das für Technologien, die auf Expression Trees beruhen, daher grundsätzlich problematisch. So könnte das Entity Framework (Core) ein so ausgelagertes Prädikat beispielsweise nicht mehr nach SQL übersetzen, sondern wäre gezwungen, das Prädikat und alles, was danach kommt, auf dem Client auszuwerten. Im Fall der Inkrementalisierung kann das aber nützlich sein, um den Abhängigkeitsgraphen zu verkleinern. Denn für die Ausführung einer Methode gibt es im Abhängigkeitsgraphen zunächst nur genau einen Knoten. Wenn die Heuristik zutrifft, beispielsweise weil die Argumente der Methode alle unveränderlich sind, führt das zu einer effizienteren und speicherschonenderen Abarbeitung. Das ist der Fall, wenn die Methode ausschließlich mit Zahlen, Zeichenketten oder Record Structs arbeitet. Was aber, wenn nicht alle Parameter unveränderlich sind?

Die Idee der expliziten Inkrementalisierung besteht nun darin, in diese Heuristik einzugreifen und sie zu überschreiben. NMF Expressions verwendet hierfür Attribute, genauso wie das Entity Framework, das seit jeher Attribute nutzt, um Methodenaufrufe in den Aufruf von Stored Procedures in der Datenbank umzuwandeln. Das verwendete Attribut in NMF Expressions nennt sich ObservableProxy. Da man in ein Attribut keine Methode eintragen kann, muss man in das Attribut den Namen einer öffentlichen Proxymethode eintragen, sowie (falls abweichend) die Klasse, in der die Methode deklariert ist. Wenn die Proxymethode nicht öffentlich sichtbar sein soll, empfiehlt es sich, eine interne oder private Hilfsklasse dafür anzulegen.

Eine solche Proxymethode wird von NMF Expressions anstelle der eigentlichen Methode aufgerufen. Dazu muss sie dieselben Typparameter haben; außerdem muss es für jeden Parameter einen Parameter geben, bei dem der Typ in INotifyValue geschachtelt ist, ebenso für den Rückgabetyp. Da die Datenstrukturen häufig auch komplett neu aufgebaut werden müssen, wenn sich Parameter ändern, dürfen die Parametertypen der Proxymethode auch die originalen Parametertypen sein. In diesem Fall kümmert sich NMF Expressions darum, die Methode erneut aufzurufen, wenn sich die übergebenen Argumente ändern.

Ein Beispiel, das zeigt, wie das Prädikat, ob ein To-do weiterhin relevant ist, in eine Methode ausgelagert werden kann, ist in Listing 3 dargestellt. Zu Demonstrationszwecken wird hier als Implementierung der Schnittstelle INotifyValue wiederum NMF Expressions verwendet, aber natürlich sind auch eigene Implementierungen möglich, wodurch sich beliebige dynamische Algorithmen umsetzen lassen.

[ObservableProxy(nameof(IsRelevantInc1))] // alternativ nameof(IsRelevantInc2)
public bool IsRelevant(Todo todo) => !todo.IsDone;

public INotifyValue<bool> IsRelevantInc1(INotifyValue<Todo> todo)
   => Observable.Expression(() => !todo.Value.IsDone);

public INotifyValue<bool> IsRelevantInc2(Todo todo)
   => Observable.Expression(() => !todo.IsDone);

Integration in UI-Technologien

Obwohl es laut den Architekturrichtlinien von .NET für Schnittstellen immer mindestens zwei denkbare Implementierungen geben muss, existiert für INotifyCollectionChanged in der Basisklassenbibliothek, wie schon erwähnt, nur eine Implementierung, nämlich ObservableCollection. Das hat anscheinend zur Folge, dass die meisten XAML-basierten UI-Bibliotheken davon ausgehen, dass es sich bei einer Implementierung von INotifyCollection um die ObservableCollection handeln muss, obwohl die Schnittstelle eigentlich allgemeiner entworfen wurde. So kann man bei einem CollectionChanged-Ereignis den Index eines geänderten, hinzugefügten oder gelöschten Elements angeben oder eine -1 eintragen, falls der Typ der Collection keine Indizes unterstützt, wie beispielsweise bei Mengentypen wie HashSet, die keine Ordnung der Elemente garantieren.

Leider wird bei UI-Bibliotheken weder die Möglichkeit berücksichtigt, dass eine Implementierung von INotifyCollectionChanged von einem Index -1 Gebrauch machen könnte, noch die Möglichkeit, dass in einer Collection mehrere Elemente auf einmal verändert werden oder nach einem Reset Elemente übrigbleiben könnten. Auch wenn sich die Fehlermeldungen je nach UI-Technologie durchaus unterscheiden, implementieren alle großen UI-Bibliotheken immer nur genau das, was für die ObservableCollection benötigt wird.

Wie macht man also eine inkrementelle Query kompatibel für Data Binding in UI-Bibliotheken? In NMF Expressions existiert hierfür die spezielle Methode RestoreIndices, die die inkrementelle Query puffert, Änderungen vereinzelt und Indizes wiederherstellt. Damit lässt sich die Query aus Listing 1 wie in Listing 4 in die Oberfläche einbinden.

TodosInOrder = (from p in Projects.WithUpdates()
                where !p.IsOnHold
                from t in p.Todos
                where !t.IsDone
                orderby t.Priority descending, t.Deadline ?? EndOfTime
                select t).RestoreIndices();

In [4] habe ich ein Repository erstellt, das die Verwendung von NMF Expressions in Verbindung mit dem MVVM Community Toolkit für das Eingangsbeispiel der To-do-Liste für WPF, MAUI und Avalonia demonstriert.

GraphQL

Die meisten XAML-basierten Technologien wie WPF, MAUI oder Avalonia arbeiten innerhalb desselben Prozesses, weshalb sich das UI bequem an die über INotifyPropertyChanged und INotifyCollectionChanged zur Verfügung gestellten Ereignisse auf Änderungen des Modells registrieren kann, um Data Binding zu ermöglichen. Das funktioniert natürlich nicht mehr, wenn das UI in einem anderen Prozess liegt, wie es beispielsweise bei Webanwendungen der Fall ist. Um sich hier auch über Änderungen benachrichtigen zu lassen, müssen Events explizit als Subscriptions hinterlegt werden. In [4] habe ich das exemplarisch auch für eine GraphQL-Version derselben To-do-Liste verwendet.

Performancegewinne hängen von der Anwendung ab

Eine Frage, die sich förmlich aufdrängt, ist die nach der Performance. Natürlich verbraucht der dynamische Abhängigkeitsgraph Speicher. Mehr Speicher ist allerdings häufig einfacher zu bekommen als mehr CPU-Zeit. Hinzu kommt, dass manche Queryoperatoren wie Orderby bei jeder Ausführung Speicher benötigen, während eine inkrementelle Query einen balancierten Suchbaum im Speicher hält und diesen permanent beibehält. Daher wird bei einer Abfrage der Ergebnisse kein neuer Speicher allokiert. Die Performance der Änderungsausbreitung kann jedoch auch von der Beschaffenheit konkreter Änderungen abhängen. So ist es im Beispiel natürlich aufwendiger zu propagieren, wenn in einem Projekt viele To-dos von „on hold“ wieder auf aktiv gesetzt werden, als wenn diesem Projekt gar keine To-dos zugeordnet gewesen wären. Diese Beispiele illustrieren, dass eine allgemeine Aussage kaum möglich ist.

In guten Fällen kann es allerdings auch zu sehr hohen Beschleunigungen kommen, solange der dynamische Abhängigkeitsgraph in den Speicher passt. So konnten in einigen Benchmarks auch schon Beschleunigungen von mehreren Größenordnungen gemessen werden [5]. Insbesondere wenn die Änderungen nur kleine Teile der Query betreffen, ist der Aufwand für die Propagation in einer viel günstigeren Komplexitätsklasse, als wenn komplett alles neu berechnet und anschließend noch verglichen werden müsste, was genau sich denn geändert hat.

Zusammenfassung

Mit Hilfe von dynamischen Abhängigkeitsgraphen lassen sich Querys in .NET nicht nur automatisch in Datenbankabfragen konvertieren. Die angebotenen Abstraktionen eignen sich auch dazu, automatisiert zu erfassen, wann sich das Ergebnis einer Query ändert. Auf diese Weise können deklarative Querys mit NMF Expressions beispielsweise für das Data Binding von XAML-basierten UI-Technologien eingesetzt werden.

Links & Literatur

[1] https://nmfcode.github.io/expressions/index.html

[2] Hinkel, G.; Heinrich, R.; Reussner, R.: „An extensible approach to implicit incremental model analyses“; in: Software & Systems Modeling 18, 2019

[3] Acar, U.: „Self-adjusting computation:(an overview)“: in: „Proceedings of the 2009 ACM SIGPLAN workshop on Partial evaluation and program manipulation“, 2009

[4] https://github.com/georghinkel/expressions-demo

[5] Szárnyas, G.; Semeráth, O.; Ráth, I.: „The TTC 2015 Train Benchmark Case for Incremental Model Validation“; in: „Proceedings of the 8th Transformation Tool Contest“, 2015

The post Implizit inkrementelle LINQ-Queries in C# für XAML Data Binding appeared first on BASTA!.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

.NET 10.0 ist eine Long-Term-Support-Version, die ab November 2025 36 Monate unterstützt wird. .NET 8.0 und .NET 9.0 haben noch Support bis November 2026, nachdem Microsoft den Support für die Standard-Term-Support-Versionen auf 24 Monate erhöht hat. Die nächste Version, .NET 11.0, wird im November 2026 erscheinen – dann zusammen mit Visual Studio 2027.

Abb. 1: Scott Hanselman dankt in der Keynote der .NET Conf 2025 allen Community-Mitgliedern, die Beiträge zu .NET 10.0 geleistet haben – darunter auch einigen BASTA!-Sprechern

Entity Framework Core: JSON-Spalten

Seit Entity Framework Core 10.0 Release Candidate 1 wird der Spaltentyp JSON unterstützt. Dieser steht in Microsoft SQL Server 2025 (erschienen am 18.11.2025 [1]) sowie in Azure SQL zur Verfügung.

JSON-Spalten kamen in EF Core zwar schon früher zum Einsatz, etwa um einfache Wertlisten wie List<int> in einer einzelnen Spalte abzulegen (eine Ausnahme bildet PostgreSQL, das solche Datentypen von Haus aus unterstützt) oder um sogenannte Owned Types zu speichern. Bislang wurde dafür jedoch eine nvarchar(max)-Spalte genutzt, kombiniert mit der SQL-Funktion OPENJSON().

Mit den neuen SQL-Server-Versionen greift EF Core nun auf den nativen JSON-Datentyp zurück – vorausgesetzt, die verwendete SQL-Server-Instanz beherrscht diesen auch. Zusätzlich muss EF Core darüber informiert werden, dass JSON-Spalten verfügbar sind. Bei Azure SQL geschieht das, indem statt UseSqlServer() nun UseSqlAzure() verwendet wird.

Beim lokalen Microsoft SQL Server muss man den Kompatibilitätslevel auf 170 (Standard ist 150) setzen (Abb. 2 und 3):

builder.UseSqlServer(connstring, x => x.UseCompatibilityLevel (170));

Abb. 2: Datentypmapping mit SQL Server 2025 bei EF Core im Kompatibilitätslevel 150

Abb. 3: Datentypmapping mit SQL Server 2025 bei EF Core im Kompatibilitätslevel 170

Entity Framework Core: Erweiterungen bei komplexen Typen

Mit Entity Framework Core 8.0 hat Microsoft die Complex Types als modernere und flexiblere Alternative zu den Owned Types eingeführt und in Version 9.0 weiter ausgebaut. Allerdings standen für Complex Types bislang keine JSON-Abbildungen zur Verfügung. Stattdessen wurde jede Property eines Complex Types stets in eine eigene Spalte der Tabelle des übergeordneten Entitätstyps projiziert.

Seit Entity Framework Core 10.0 (ab Release Candidate 1) unterstützen Complex Types nun auch ein JSON-Mapping und können zudem optional sein. Für optionale Complex Types gibt es jedoch eine Einschränkung: Sie müssen mindestens eine verpflichtende Property enthalten. EF Core benötigt dieses Pflichtfeld, um erkennen zu können, ob der Complex Type tatsächlich null ist oder lediglich leere Werte besitzt (Listing 1).

Fehlt das Pflicht-Property, führt das zu folgender Fehlermeldung: „’ShippingAddress’ is mapped to columns by flattening the contained properties into its container’s table; this mapping requires at least one required property – to allow distinguishing between ‘null’ and empty values – but the complex type contains only optional properties. Configure the property with a shadow discriminator by adding a call to ‘HasDiscriminator()’ on the complex property configuration, or map this complex property to a JSON column instead.“

public abstract class Company
{
  [Key]
  public int CompanyID { get; set; } // Primary Key
  [StringLength(50)]
  public string Name { get; set; }
  
  public DateTime Created { get; set; } = DateTime.Now;
  public Address BillingAddress { get; set; } // 1:1
  public Address? ShippingAddress { get; set; } 
  
  [Required]
  public CompanyDescription Description { get; set; } = new(); // 1:1
  public List<Management> ManagementSet { get; set; } = new(); // 1:N
}

public record struct Address // record struct für Complex Type
{
  public Address()
  {
  }
  
  //public int AddressID { get; set; } //--> PK bei Complex Types nicht notwendig
 
  public bool AdressExists { get; set; } = true; // bei Optional Complex Type ohne weitere Pflichtfelder (neu in v10.0)
  [StringLength(50)]
  public string City { get; set; }
  [StringLength(50)]
  public string Street { get; set; }
  [StringLength(10)]
  public string Postcode { get; set; }
  [StringLength(50)]
  public string Country { get; set; }
}

Ein Beispiel für einen Complex Type mit JSON-Mapping könnte so aussehen:

modelBuilder.Entity<Company>(x =>
{
  x.ComplexProperty(p => p.Address, p=>p.ToJson()); // 1:1-Mapping. NEU: p=>p.ToJson()
}

Geplant war auch, ein 1:N-Mapping in Complex Types zu ermöglichen. Zwar beschwert sich Entity Framework Core nicht mehr über eine Zeile wie x.ComplexProperty(p => p.ManagementSet, p => p.ToJson()); und es wird auch eine JSON-Spalte ManagementSet in der Tabelle angelegt. Die enthält dann aber nicht die Daten, sondern nur die Eigenschaft Capacity (Abb. 4). Daher funktionieren auch Abfragen über diese Spalte nicht.

Abb. 4: Falsche Persistierung der Menge im komplexen Typ

Entity Framework Core: Vektoren

Microsoft SQL Server 2025 führt einen neuen Spaltentyp vector ein, der speziell für die Speicherung von Vektordaten im Kontext von Ähnlichkeitssuchen und KI-Szenarien entwickelt wurde. In Azure SQL steht dieser Datentyp bereits seit 2024 als Vorschau zur Verfügung und gilt seit Juni 2025 offiziell als produktionsbereit.

Ein Vektor besitzt eine feste Dimension, also eine Anzahl an Elementen. Jedes dieser Elemente wird entweder als 2-Byte- oder 4-Byte-Gleitkommazahl abgelegt. Die Nutzung des kompakten 2-Byte-Formats muss zuvor separat aktiviert werden. Innerhalb des SQL Servers werden Vektoren in einem speziell optimierten Binärformat gespeichert und über entsprechende Datenbanktreiber – etwa Microsoft.Data.SqlClient ab Version 6.1 – effizient übertragen.

In T-SQL und im SQL Server Management Studio (ab Version 21) werden die Vektordaten als JSON-Array visualisiert, z. B.:

DECLARE @v VECTOR(10) = '[0.1, 2, 3.5, 4, 5, 6, 7, 8, 9.9, 10]';
SELECT @v;

Ältere Versionen der Datenbanktreiber übertragen Vektordaten noch im nvarchar(max)-Format und somit als JSON-Struktur. Für Vektoren stehen keinerlei Vergleichsoperatoren oder arithmetische Operationen zur Verfügung – also weder Gleichheits- noch Größenvergleiche noch Rechenoperationen wie Addition, Subtraktion, Multiplikation oder Division. Auch Verkettungen oder zusammengesetzte Zuweisungsoperatoren werden nicht unterstützt. Zudem lassen sich Vektorspalten nicht in speicheroptimierten Tabellen einsetzen.

Mit SQL Server 2025 steht für Vektordaten die Funktion VECTOR_DISTANCE() bereit, über die sich der Abstand zwischen zwei Vektoren berechnen lässt. Dabei können drei verschiedene Distanzverfahren verwendet werden (Abb. 5):

1. “cosine”: 0 bis 2 (0 = identisch, 1 = orthogonal, 2 = entgegengesetzt)
2. “euclidean”: 0 bis unendlich (0 = identisch)
3. “dot”: -1 bis +1 bei normierten Vektoren, -unendlich bis +unendlich bei nicht normierten Vektoren

Abb. 5: Vektordistanzberechnung

Die Funktion VECTOR_SEARCH(), mit der sich der jeweils nächste Nachbar finden lässt, befindet sich weiterhin im Preview-Status.

Seit Entity Framework Core 10.0 Release Candidate 1 können Entwickler:innen Vektorspalten direkt nutzen. Beim Reverse- wie auch beim Forward-Engineering werden diese SQL-Server-Spalten dem .NET-Typ Microsoft.Data.SqlTypes.SqlVector<float> zugeordnet. Dieser stammt aus dem NuGet-Paket Microsoft.Data.SqlClient (ab Version 6.1).

Zusätzlich stellt EF Core eine neue Methode EF.Functions.VectorDistance() bereit, welche die SQL-Server-Funktion VECTOR_DISTANCE() in LINQ-Ausdrücken repräsentiert (Listing 2). Vor EF Core 10.0 war hierfür ein separates NuGet-Paket namens EFCore.SqlServer.VectorSearch erforderlich. Die SQL-Funktion VECTOR_SEARCH() kann jedoch weiterhin nicht direkt in LINQ-Abfragen verwendet werden.

using System.ComponentModel.DataAnnotations.Schema;
using Microsoft.Data.SqlTypes;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;

namespace EFC_MappingScenarios.Vectors;

public class Texte
{
  public int ID { get; set; }
  public string Text { get; set; }
  [Column(TypeName = "vector(384)")] 
  public Microsoft.Data.SqlTypes.SqlVector<float> Embedding { get; set; }
}

class Context : DbContext
{
  public DbSet<Texte> TexteSet { get; set; }
  bool logActive = false;

  void Log(string message)
  {
    if (logActive) CUI.PrintAlternatingColor(message);
  }

  protected override void OnConfiguring(DbContextOptionsBuilder builder)
  {
    builder.EnableSensitiveDataLogging(true).EnableDetailedErrors();
    string connstring = Settings.ConnectionStringSQL2025 + @$";Database=EFC_MappingScenarios_" + nameof(EFC_MappingScenarios.Vectors);
    builder.UseSqlServer(connstring, x => x.UseNetTopologySuite().UseCompatibilityLevel(170)).LogTo(Log, new[] { RelationalEventId.CommandExecuted }); // WICHTIG für JSON-Spalten: 170
  }

}

class Client
{
  // https://www.bundesregierung.de/breg-de/bundesregierung/bundeskabinett?utm_source=chatgpt.com 
  static OrderedDictionary<string, string> Bundesregierung2025 = new() {
    { "Friedrich Merz", "Bundeskanzler" }, { "Lars Klingbeil", "Bundesminister der Finanzen" }, { "Alexander Dobrindt", "Bundesminister des Innern" }, { "Dr. Johann Wadephul", "Bundesminister des Auswärtigen" }, { "Boris Pistorius", "Bundesminister der Verteidigung" }, { "Katherina Reiche", "Bundesministerin für Wirtschaft und Energie" }, { "Dorothee Bär", "Bundesministerin für Forschung, Technologie und Raumfahrt" }, { "Dr. Stefanie Hubig", "Bundesministerin der Justiz und für Verbraucherschutz" }, { "Karin Prien", "Bundesministerin für Bildung, Familie, Senioren, Frauen und Jugend" }, { "Bärbel Bas", "Bundesministerin für Arbeit und Soziales" }, { "Dr. Karsten Wildberger", "Bundesminister für Digitales und Staatsmodernisierung" }, { "Patrick Schnieder", "Bundesminister für Verkehr" }, { "Carsten Schneider", "Bundesminister für Umwelt, Klimaschutz, Naturschutz und nukleare Sicherheit" }, { "Nina Warken", "Bundesministerin für Gesundheit" }, { "Alois Rainer", "Bundesminister für Landwirtschaft, Ernährung und Heimat" }, { "Reem Alabali-Radovan", "Bundesministerin für wirtschaftliche Zusammenarbeit und Entwicklung" }, { "Verena Hubertz", "Bundesministerin für Wohnen, Stadtentwicklung und Bauwesen" }, { "Thorsten Frei", "Bundesminister für besondere Aufgaben / Chef des Bundeskanzleramtes" }
  };

  public static void Run()
  {
    CUI.Demo(nameof(EFC_MappingScenarios.Vectors));

    using (var ctx = new Context())
    {
      CUI.Yellow("Model: " + ctx.Model.GetType().FullName);
      Util.RecreateDB(ctx);

      #region ---------------------- Vektor-Daten anlegen
      CUI.Head(ctx.Database.ProviderName + ": Erstelle Datensätze mit Vektor-Spalte (Lokale Vektorisierung dauert etwas...)");
      foreach (var person in Bundesregierung2025)
      {
        CUI.BusyIndicator();
        var dt = new Texte();
        ctx.TexteSet.Add(dt);

        dt.Text = person.Key + " ist " + person.Value;
        var values = EmbeddingsUtil.Get("passage:" + dt.Text);
        dt.Embedding = new SqlVector<float>(values);

        Console.WriteLine(dt.Text + " -> " + dt.Embedding.Length);
      }
      var c2 = ctx.SaveChanges();
      Console.WriteLine($"{c2} Datensätze gespeichert");
      #endregion

      #region ---------------------- Vektor-Daten abfragen 

      CUI.Head(ctx.Database.ProviderName + ": Vektorsuche");

      Suche("Dr. Karsten Wildberger");// exakte Suche
      Suche("Karsten");// nur Vorname
      Suche("Carsten Wilberger");// absichtlich falsch geschrieben, damit es nicht exakt passt
      Suche("Kriegsminister");
      Suche("Kassenwart");
      Suche("Unfug");
      Suche("Der beliebteste Politiker im Kabinett");
      Suche("Der unbeliebteste Politiker im Kabinett");
      #endregion

      CUI.PanelGreen("=== DONE");
    }
  }

  // https://learn.microsoft.com/en-us/sql/t-sql/functions/vector-distance-transact-sql?view=sql-server-ver17
  //   cosine - Cosine distance 0 bis 2 (0 = identisch, 1 = orthogonal, 2 = entgegengesetzt)
  //   euclidean - Euclidean distance 0 bis unendlich (0 = identisch)
  //   dot - (Negative)Dot product (-1 bis +1 bei normierten Vektoren, -unendlich bis +unendlich bei nicht normierten Vektoren)
  private static void Suche(string suchBegriff, string distanzVerfahren = "cosine")
  {
    using var ctx = new Context();

    CUI.Yellow("Suche ähnlichste Einträge zu: " + suchBegriff);
    var sqlVector = new SqlVector<float>(EmbeddingsUtil.Get(suchBegriff));
    var result = ctx.TexteSet
      .OrderBy(b => EF.Functions.VectorDistance(distanzVerfahren, b.Embedding, sqlVector))
      .Take(5)
      .Select(b => new { Object = b, Distance = EF.Functions.VectorDistance(distanzVerfahren, b.Embedding, sqlVector) })
      .ToList();

    foreach (var b in result)
    {
      CUI.Green(b.Object.ID + ": " + b.Object.Text + " -> Distanz: " + Math.Round(b.Distance, 2));
    }
  }
}

Im Beispiel sind die Mitglieder des Bundeskabinetts (Stand November 2025) in einer Tabelle gespeichert, wobei Name und Zuständigkeit in einer Textspalte erfasst sind. Darauf basierend werden verschiedene Ähnlichkeitssuchen über EF.Functions.VectorDistance() ausgeführt.

Die in Abbildung 6 gezeigten Ergebnisse wurden mit dem Embedding-Modell Multilingual-E5-small erzeugt, das 384 Dimensionen besitzt. Das von Microsoft-Mitarbeitenden entwickelte Modell ist Open Source, lokal einsetzbar und benötigt keine Cloud. Da E5 Texte vieler Sprachen in einen gemeinsamen semantischen Vektorraum überführt, funktionieren Ähnlichkeitsvergleiche auch über Sprachgrenzen hinweg. Zu Begriffen wie „Kassenwart“ oder „Kriegsminister“ liefert das Modell korrekt die Finanz- bzw. Verteidigungsminister. Welche Mitglieder der Regierung besonders beliebt oder unbeliebt sind, kann das Embedding-Modell hingegen naturgemäß nicht beurteilen.

Abb. 6: Ausgabe des obigen Listings

Entity Framework Core: Optionen für Parametermengen

Ein Performancethema in Entity Framework Core, bei dem Microsoft seit Jahren verschiedene Strategien ausprobiert, ist die Übergabe von Parametermengen von .NET an das Datenbankmanagementsystem, z. B. eine Liste von Orten, zu denen passende Datensätze gesucht werden:

List<string> destinations = new List<string> { "Berlin", "New York", "Paris" };
var flights = ctx.Flights
.Where(f => destinations.Contains(f.Destination))
.Take(5).ToList();

In den Entity-Framework-Core-Versionen 1.0 bis 7.0 wurden die Werte aus der Menge destinations einzeln als statische Werte übergeben:

SELECT TOP(@p) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (N'Berlin', N'New York', N'Paris')

Das sorgte aber im Datenbankmanagementsystem für viele verschiedene Ausführungspläne. Seit Version 8.0 übergibt Entity Framework Core die Liste als ein JSON-Array, das im SQL-Befehl mit OPENJSON() gespalten wird (Listing 3). Das erschwerte dem Datenbankmanagementsystem die Optimierung der Ausführungspläne, weil die Anzahl der Parameter nicht mehr bekannt war.

SELECT TOP(@p) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (
  SELECT [d].[value]
  FROM OPENJSON(@destinations) WITH ([value] nvarchar(30) '$') AS [d]
)

Seit Entity Framework Core 9.0 besteht die Möglichkeit, über EF.Constant() oder den globalen Aufruf TranslateParameterizedCollectionsToConstants() in der OnConfiguring()-Methode der Kontextklasse wieder auf das frühere Übersetzungsverhalten zurückzuschalten:

var flights1 = ctx.Flights
.Where(f => EF.Constant(destinations).Contains(f.Destination))
.Take(5).ToList();

Beim geänderten Standard konnten Entwickler:innen dann im Einzelfall mit EF.Parameter() das JSON-Array übergeben. In der aktuellen Version 10.0 des OR-Mappers hat Microsoft abermals einen neuen Standard implementiert, nämlich die Einzelübergabe der Werte jeweils als eigene Parameter. Diesen SQL-Befehl erzeugt Entity Framework Core im vorangegangenen Beispiel mit drei Städten:

SELECT TOP(@p) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (@destinations1, @destinations2, @destinations3)

Im ausführlichen Test stellt man fest, dass EF Core nicht immer genau die gleiche Anzahl Parameter erzeugt, wie es Werte gibt. Stattdessen rundet Entity Framework Core zur Vermeidung des Anlegens von zu vielen Ausführungsplänen ab sechs Parametern auf 10er-Blöcke auf, d. h. für sechs Werte werden zehn Parameter erzeugt, wobei die letzten Parameter immer den gleichen Wert erhalten (Listing 4).

[Parameters=[@p='5', @destinations1='Berlin' (Size = 30), @destinations2='New York' (Size = 30), @destinations3='Paris' (Size = 30), @destinations4='Rome' (Size = 30), @destinations5='Munich' (Size = 30), @destinations6='London' (Size = 30), @destinations7='London' (Size = 30), @destinations8='London' (Size = 30), @destinations9='London' (Size = 30), @destinations10='London' (Size = 30)], CommandType='Text', CommandTimeout='300']
  SELECT TOP(@p) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
  FROM [Operation].[Flight] AS [f]
  WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] >= CAST(20 AS smallint) AND [f].[FreeSeats] <= CAST(200 AS smallint) AND [f].[Destination] IN (@destinations1, @destinations2, @destinations3, @destinations4, @destinations5, @destinations6, @destinations7, @destinations8, @destinations9, @destinations10)

Entwickler:innen können bei Bedarf weiterhin das bisherige Verhalten über EF.Constant() bzw. EF.Parameter() erzwingen. Welche Variante sinnvoll ist, hängt auch davon ab, wie stark sich die Anzahl der Werte zur Laufzeit verändert.

Auf globaler Ebene lässt sich das Standardverhalten über UseParameterizedCollectionMode(ParameterTranslationMode.Constant) in OnModelCreating() in der Kontextklasse anpassen. Als zulässige Einstellwerte stehen Constant, Parameter und MultipleParameters zur Verfügung. Die erst mit EF Core 9.0 eingeführte Methode TranslateParameterizedCollectionsToConstants() existiert zwar weiterhin, ist jedoch inzwischen mit [Obsolete] gekennzeichnet.

Entity Framework Core: Analyzer warnt vor möglicher SQL Injection

Der OR-Mapper liefert seit Release Candidate 2 einen Code-Analyzer mit, der Entwickler:innen warnt, wenn man beim Aufruf von FromSqlRaw(), SqlQueryRaw<T>() oder ExecuteSqlRaw() eine Zeichenkette mit Pluszeichen oder String-Interpolation zusammensetzt. Die Warnung lautet: „Method inserts concatenated strings directly into the SQL, without any protection against SQL injection. Consider using ‘FromSql’ instead, which protects against SQL injection, or make sure that the value is sanitized and suppress the warning.“

Der Analyzer erkennt die Zeichenkettenzusammensetzung, wenn sie direkt im Parameter des Methodenaufrufs stattfindet, nicht aber, wenn eine zuvor zusammengesetzte Zeichenkette übergeben wird (Abb. 7).

Abb. 7: Der Analyzer erkennt einige (siehe grüne Schlangenlinien), aber leider nicht alle diese gefährlichen SQL-Injektionen

Verbesserungen bei ASP.NET Core

ASP.NET Core führte in .NET 10.0 Release Candidate 1 neue Metriken für ASP.NET Core Identity zur Überwachung der Benutzerverwaltung ein, z. B. aspnetcore.identity.user.create.duration, aspnetcore.identity.sign_in.sign_ins und aspnetcore.identity.sign_in.two_factor_clients_forgotten.

Zur Validierung von Instanzen von Klassen und Records in Blazor, die Microsoft schon in der Preview-Phase von .NET 10.0 verbessert hatte, gibt es seit Release Candidate 1 drei weitere Neuerungen:

1. Validierungsannotationen können auch für Typen und nicht nur wie bisher für Properties definiert werden.
2. Mit der neuen Annotation [SkipValidation] können Entwickler:innen Typen und Properties von der Validierung ausschließen.
3. Ebenso werden alle mit [JsonIgnore] annotierten Properties nicht mehr validiert.

Der Persistent Component State in Blazor, den es seit .NET 10.0 Preview 6 gibt, funktioniert nun auch beim Einsatz der Enhanced Navigation beim statischen Server-side Rendering.

Verbesserungen bei MAUI

Mit der Einstellung SafeAreaEdges=”None” können .NET-MAUI-Fenster nun auch auf Android und iOS in den ansonsten geschützten Navigationsbereichen oben und unten rendern. Alternative Werte sind “Container” (schützt vor Systembars und Notch), “SoftInput” (schützt nur vor der Tastatur) und “All” (kombiniert “Container” und “SoftInput”) (Abb. 8).

Abb. 8: Safe Area Edges auf iOS. Quelle: Microsoft .NET Conf 2025

Auch bei .NET MAUI gibt es neue Metriken für die Überwachung der Layoutperformance:

• maui.layout.measure_count
• maui.layout.measure_duration
• maui.layout.arrange_count
• maui.layout.arrange_duration

Das Steuerelement <HybridWebView> bietet nun die Ereignisse WebViewInitializing() und WebViewInitialized() zur Anpassung der Initialisierung. Vergleichbare Ereignisse gab es zuvor im Steuerelement <BlazorWebView> (BlazorWebViewInitializing() und BlazorWebViewInitialized()). Das Steuerelement <RefreshView> besitzt nun auch die Eigenschaft IsRefreshEnabled zusätzlich zu IsEnabled.

Seit Preview 7 gibt es den Source Generator für XAML in .NET MAUI. Um diesen Source Generator zu aktivieren, schreibt man seit Release Candidate 2 in die Projektdatei:

<PropertyGroup>
<MauiXamlInflator>SourceGen</MauiXamlInflator>
</PropertyGroup>

Auch unter Windows kann man nun die Mikrofonberechtigungen abfragen: Permissions.RequestAsync<Permissions.Microphone>()

Verbesserungen bei Windows Forms

Das Windows-Forms-Teams schreibt in seinen Release Notes, dass der in .NET 9.0 eingeführte Dark Mode (Abb. 9) nun nicht mehr den Status „experimentell“ besitzt [2].

Abb. 9: Einige Windows-Forms-Steuerelemente im Dark Mode

Fazit

Es ist Zeit, ein Fazit über die Neuerungen aus allen vier Beiträgen zu .NET 10.0 zu ziehen. Das soll in Form von Listen der High- und Lowlights geschehen. Meine zehn persönlichen Highlights in .NET 10.0 sind:

1. Extensions in C#: Damit können Entwickler:innen bestehende, kompilierte Klassen um Instanzmethoden, statische Methoden, Instanz-Properties, statische Properties und Operatoren erweitern
2. Semi-Auto Properties in C# mit dem Schlüsselwort field (sind nun offiziell unterstützt)
3. C#-Scripting mit File-based Apps im .NET SDK
4. Neue LINQ-Operatoren LeftJoin()und RightJoin()in LINQ und EF Core
5. Nutzung der SQL-Server-Spaltentypen JSON und VECTOR in EF Core
6. JSON-Patch nach RFC 6902 mit NuGet-Paket Microsoft.AspNetCore.JsonPatch.SystemTextJson
7. Persistierung von Circuits in Blazor Server und einfachere Festlegung des Persistent Component State via Annotation
8. Anpassbarkeit des Verbindungsproblemdialogs bei Blazor Server
9. Das NuGet-Paket Microsoft.AspNetCore.OpenApi berücksichtigt XML-Codekommentare bei der Erstellung von OAS-Dokumenten; diese verwenden nun OAS-Version 3.1 und optional YAML statt JSON
10. In Windows Forms können Entwickler:innen nun Screenshots von einzelnen Windows-Forms-Fenstern mit einem Screenshotwerkzeug verhindern

Ich sehe auch Enttäuschungen in .NET 10.0:

1. Auch wenn Microsoft in .NET 10.0 Verbesserungen gemacht haben will: Das Hot Reloading in Blazor-Anwendungen ist immer noch eine große Enttäuschung, weil es oft abstürzt und man sich fragen muss, ob man mit oder ohne Hot Reloading produktiver coden kann.
2. Auch der Blazor-Editor hat in der aktuellen Entwicklungsumgebung Visual Studio 2026 noch viele Macken: Immer wieder sieht man die berüchtigten gelben Balken in der Entwicklungsumgebung, die anzeigen, dass ein Editorfeature gerade abgestürzt ist.
3. Die in EF Core 9.0 eingeführte, aber nicht für die Praxis brauchbare Unterstützung des NativeAOT-Compilers, wurde in Version 10.0 nicht einen Deut verbessert.
4. Der NativeAOT-Compiler funktioniert auch immer noch nicht für Windows Forms und WPF sowie ASP.NET Core MVC, Razor Pages sowie Blazor auf dem Server (weder für static noch interactive Server-side Rendering).
5. Blazor WebAssembly kann immer noch kein vollständiges Multi-Threading, siehe [3] und [4].
6. Es gibt weiterhin keinen WYSIWYG-Designer für Blazor. Das sei als Schwäche erwähnt, auch wenn Microsoft schon klargestellt hat, dass es einen solchen Designer nicht liefern wird und viele Entwickler:innen einen solchen Designer nicht vermissen. Es gibt aber genug Menschen, die sich einen Designer wünschen.
7. Microsoft unterstützt .NET MAUI immer noch nicht auf dem Linux-Desktop. Aber es gibt eine neue Perspektive: Das an WPF angelehnte, XAML-basierte Open-Source-GUI-Framework Avalonia hat am 11.11.2025 angekündigt, dass man an einer Brücke zwischen .NET MAUI und dem Avalonia-Kern arbeitet, der auf Skia-Rendering basiert [5]. Damit kann .NET MAUI in Zukunft auch auf dem Linux-Desktop und auch im Webbrowser laufen.

Links & Literatur

[1] https://learn.microsoft.com/de-de/sql/sql-server/what-s-new-in-sql-server-2025?view=sql-server-ver17

[2] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/rc1/winforms.md

[3] https://github.com/dotnet/runtime/issues/68162

[4] https://github.com/dotnet/aspnetcore/issues/54365

[5] https://avaloniaui.net/blog/net-maui-is-coming-to-linux-and-the-browser-powered-by-avalonia

The post .NET 10.0 RTM: Alle Neuerungen seit dem Release Candidate im Überblick appeared first on BASTA!.

Rainer Stropek ist seit über zwanzig Jahren als Unternehmer in der IT-Branche tätig. Er gründete und leitete in dieser Zeit mehrere IT-Dienstleistungsunternehmen und entwickelt derzeit mit seinem Team in seinem Unternehmen software architects die preisgekrönte Software time cockpit. Rainer hat Abschlüsse von der Höheren Technischen Lehranstalt für MIS, Leonding (AT) und der University of Derby (UK). Er ist Autor von mehreren Fachbüchern und Zeitschriftenartikeln im Bereich Microsoft .NET und C#. Er tritt regelmäßig als Redner und Trainer auf renommierten Konferenzen in Europa und den USA auf. Im Jahr 2010 wurde er von Microsoft zu einem der ersten MVPs für die Windows Azure-Plattform ernannt. Seit 2015 ist er zudem Microsoft Regional Director.

Die Experten zeigten, wie KI nicht nur Werkzeuge verändert, sondern ganze Denkweisen und Arbeitsweisen prägt, insbesondere durch die Integration intelligenter Assistenten in Entwicklungsprozesse und die Entstehung einer neuen Generation von ‘AI Natives’. MCP wird als Standard vorgestellt, der die Interaktion zwischen Benutzer, KI und Anwendungen erleichtert und viele Routineaufgaben automatisiert, ohne die Bedeutung sorgfältig gestalteter Benutzeroberflächen zu verdrängen.

Die wichtigsten Take-aways der Keynote:

1. Wendepunkt in der Softwareentwicklung durch KI
   KI verändert nicht nur die Werkzeuge, sondern auch Denkweisen und die Art der Zusammenarbeit in der Softwareentwicklung grundlegend. Es entsteht eine neue Generation von „AI Natives“, die von Anfang an mit intelligenten Assistenten programmieren und dadurch einen neuen Blick auf Softwareentwicklung haben.
2. Integration von KI tief in Entwicklungsprozesse
   GitHub demonstriert, wie KI tief in den Entwicklungsprozess eingebunden werden kann, um die Produktivität und Qualität zu steigern. Dabei geht es nicht nur um das reine Schreiben von Code, sondern um eine umfassende Unterstützung über den gesamten Entwicklungszyklus.
3. Model Context Protocol (MCP) als Schlüsseltechnologie
   MCP bildet die Brücke zwischen Benutzer, KI und bestehenden Anwendungen. Es ermöglicht eine nahtlose Interaktion und Automatisierung vieler Routineaufgaben, die bisher manuell über APIs oder Benutzeroberflächen erledigt wurden.
4. Zukunft der Benutzeroberflächen
   Trotz der zunehmenden Bedeutung von KI und MCP wird es weiterhin sorgfältig gestaltete Benutzeroberflächen geben. UI-Entwicklung bleibt ein spannendes und wichtiges Feld, da KI-gestützte Interfaces nicht automatisch gute User Experiences garantieren.

Jetzt die gesamte Keynote ansehen und mehr erfahren!

The post Future Coding: Wie KI und MCP den Entwickleralltag revolutionieren appeared first on BASTA!.

In diesem Artikel beschäftigen wir uns mit einer völlig anderen Variante: Avalonia, ein Open-Source-UI-Framework. Es basiert auf .NET und steht für alle genannten Plattformen zur Verfügung. Darüber hinaus unterstützt es auch mobile Geräte (Android, iOS) und sogar den Browser. Avalonia ist nicht von Microsoft, sondern ein communitygetriebenes, unabhängiges Projekt, das bereits vor über einem Jahrzehnt entstand. Im Jahr 2023 hat das Team hinter Avalonia UI bereits das 10-jährige Jubiläum gefeiert.

Um Avalonia zu verstehen und einschätzen zu können, muss man sich damit beschäftigen, wo das Framework seine Wurzeln hat. Es ist als Cross-Platform-UI-Framework für den Desktop mit Unterstützung für Windows, macOS und Linux gestartet. Es hat viele Ideen und Konzepte von WPF übernommen – WPF war zu dieser Zeit noch der De-facto-Standard für UI-Entwicklung in .NET für den Desktop. Avalonia hat WPF allerdings nicht blind nachgebaut, sondern an vielen Stellen weiterentwickelt und verbessert. Man könnte es auch das bessere WPF nennen.

Die hohe Ähnlichkeit zu WPF sehen wir beispielhaft am XAML-Code eines Fensters in Listing 1. Dieser Code könnte genauso fast eins zu eins in WPF genutzt werden. Die XAML-Syntax ist gleich, die Namespaces sind überwiegend gleich und auch die hier verwendeten Controls sind gleich. Der einzige Unterschied ist der Namespace https://github.com/avaloniaui in der ersten Zeile.

<Window xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
        x:Class="Testing.AvaloniaArticle.MainWindow"
        Title="Greeting">
  <TextBlock HorizontalAlignment="Center"
             VerticalAlignment="Center"
             FontSize="36"
             Text="Hello, Avalonia!" />
</Window>

Eine IDE auswählen

Bei der Auswahl der IDE steht für die meisten C#-Entwickler:innen Visual Studio von Microsoft ganz oben auf der Liste. Das Avalonia-Team bietet hierfür ein Plug-in an, das alle notwendigen Features wie XAML-IntelliSense oder Live-Preview mitbringt. Speziell für die Entwicklung mit Avalonia steht mit der IDE Rider von JetBrains eine weitere Möglichkeit zur Verfügung. Das Besondere daran ist, dass damit auch unter Linux und macOS entwickelt werden kann und es eine hervorragende Unterstützung für Avalonia mitbringt, ohne ein Plug-in installieren zu müssen. Die Firma JetBrains nutzt Avalonia selbst und hat eigene Applikationen wie dotTrace und dotMemory mit Hilfe von Avalonia für macOS und Linux fit gemacht. Aus diesem Grund haben sie die notwendige Unterstützung in der IDE selbst in die Hand genommen.

SIE LIEBEN UI?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Als dritte Alternative ist es auch möglich, Avalonia-Applikationen mit Visual Studio Code von Microsoft zu entwickeln. Auch hier stellt das Avalonia-Team ein Plug-in bereit, weist aber darauf hin, dass man hier im Vergleich zu den anderen IDEs die schlechteste Unterstützung für Avalonia vorfinden wird [1].

Mit Avalonia starten

Avalonia stellt mehrere Templates bereit, mit denen wir starten können. Diese werden vom Avalonia-Team in einem separatem GitHub-Repository gepflegt [2]. Mit dem Kommandozeilenbefehl dotnet new install Avalonia.Templates werden sie installiert. Zum Zeitpunkt der Veröffentlichung dieses Artikels erhalten wir damit folgende Templates:

• Avalonia .NET App
• Avalonia .NET MVVM App
• Avalonia Cross Platform Application

Falls wir für Linux und/oder macOS entwickeln wollen, blicken wir womöglich zuerst auf die letzte Variante, Avalonia Cross Platform Application. Tatsächlich wäre aber die erste oder die zweite Variante sinnvoller. Hintergrund ist, dass es sich dabei um die Templates für reine Desktopapplikationen handelt. Solche sind bei Avalonia von vornherein Cross-Platform, also unter Windows, Linux und macOS lauffähig. Der Begriff „Cross-Platform“ im letztgenannten Template geht noch weiter, es zielt zusätzlich auf Android, iOS und den Browser. Für den Einstieg eignet sich das Template Avalonia .NET App sehr gut.

Es gibt noch eine weitere Frage, die es an dieser Stelle zu klären gilt. Wir können CompiledBindings für unsere Applikation nutzen. Standardmäßig ist das Häkchen dafür beim Template aktiv. Es handelt sich um keine endgültige Entscheidung, es empfiehlt sich aber, es immer aktiv zu lassen. CompiledBindings sorgen dafür, dass die Bindings im XAML-Code kompiliert werden – anders als etwa bei WPF. Bei WPF werden Bindings mittels Reflection zur Laufzeit aufgelöst. CompiledBindings bringen uns eine bessere Performance. Zusätzlich bekommen wir beim Kompilieren bereits Feedback in Form von Compilerfehlern, falls es etwa Tippfehler gibt.

Das CompiledBinding erklärt

Technisch basiert das CompiledBinding auf Codegenerierung. Diese beginnt allerdings nicht beim Binding, sondern bereits bei den XAML-Dateien. Anders als bei WPF werden XAML-Dateien nicht in das Zwischenformat BAML übersetzt, sondern direkt in C#-Code – eine der vielen Performanceverbesserungen gegenüber WPF.

Zur Veranschaulichung modifizieren wir das Beispielfenster aus Listing 1 so, dass die Begrüßung nicht fest in XAML hinterlegt ist, sondern aus einem ViewModel kommt. Das ViewModel dazu ist denkbar einfach, da wir keinerlei Änderungsbenachrichtigung (INotifyPropertyChanged) für diesen Zwecke implementieren müssen. Die Klasse MainWindowViewModel in Listing 2 ist völlig ausreichend.

public class MainWindowViewModel
{
  public string Greeting => "Hello, Avalonia!";
}

In Listing 3 sehen wir, welche Änderungen in XAML notwendig sind, um das CompiledBinding zur Anbindung des MainWindowViewModel zu nutzen. Der wesentliche Unterschied ist das Setzen der Eigenschaft x:DataType. Damit sagen wir dem Compiler, welchen Typ wir bei dem gebundenen DataContext erwarten.

<Window ...
        xmlns:local="clr-namespace:Testing.AvaloniaArticle"
        x:DataType="local:MainWindowViewModel">
  <TextBlock ...
             Text="{Binding Greeting}" />
</Window>

Damit das Beispiel funktioniert, darf nicht vergessen werden, eine Instanz des MainWindowViewModel zu erstellen und der Eigenschaft DataContext des Hauptfensters zuzuweisen. An dieser Stelle reagiert Avalonia exakt so wie WPF.

Ein MVVM-Framework auswählen

MVVM (Model View ViewModel) ist bei XAML-Frameworks nach wie vor das beliebteste Pattern, das gilt auch für Avalonia. Bei der Auswahl des MVVM-Frameworks sind folgende zwei Varianten für Avalonia-Projekte am häufigsten anzutreffen:

• CommunityToolkit Mvvm
• ReactiveUI

Aus Sicht des Autors ist es meist das Einfachste, mit CommunityToolkit.Mvvm zu starten. ReativeUI bietet zwar mehr Features und hat mit dem NuGet-Paket Avalonia.ReactiveUI eine sehr gute Integration in Avalonia, aber die Einstiegshürde ist höher, da ReactiveUI auf den Reactive Extensions for .NET aufbaut. In diesem Artikel wird aus Gründen des Umfangs nicht tiefer darauf eingegangen. Es wäre aber ratsam, ReactiveUI nur dann zu nutzen, wenn ein Verständnis der Reactive Extensions for .NET vorliegt.

CommunityToolkit.Mvvm kommt dagegen leichtgewichtig daher und kümmert sich im Wesentlichen um die für das MVVM-Pattern notwendige Implementierung von INotifyPropertyChanged und INotifyDataErrorInfo. Zusätzlich bringt es Klassen für synchrone und asynchrone Commands und weitere eher kleine Hilfsmittel mit. Eine Besonderheit des CommunityToolkit.Mvvm ist die Nutzung von Roslyn Source Generators, um typischen Boilerplate-Code rund um INotifyPropertyChanged-Implementierungen zu generieren.

In Listing 4 sehen wir das CommunityToolkit.Mvvm zusammen mit Avalonia in Aktion. Das MainWindowViewModel erweitern wir um das Property Name, das direkt Einfluss auf das Property Greeting hat. Wir definieren dafür lediglich den Member _name, um das Property kümmert sich das CommunitityToolkit per Source Generator selbst. Das Ereignis PropertyChanged müssen wir ebenfalls nicht selbst auslösen – die Attribute ObservableProperty und NotifyPropertyChangedFor sagen dem CommunityToolkit, wie es PropertyChanged auslösen soll. Im Hintergrund wird das Property Name durch das CommunityToolkit generiert, darin wird PropertyChanged für Name und Greeting aufgerufen. Anschließend brauchen wir im XAML-Code nur noch dagegen zu binden.

// MainWindowViewModel.cs
public partial class MainWindowViewModel : ObservableObject
{
  [ObservableProperty]
  [NotifyPropertyChangedFor(nameof(Greeting))]
  private string _name = string.Empty;

  public string Greeting => string.IsNullOrEmpty(this.Name)
    ? string.Empty
    : $"Hello, {this.Name}";
}

// MainWindow.axaml
<Window ...>
  <Border VerticalAlignment="Center" HorizontalAlignment="Center"
          Classes="InputArea">
    <StackPanel Orientation="Vertical">
      <StackPanel Orientation="Horizontal">
        <TextBlock Classes="Label" 
                   Text="Name: " />
        <TextBox Text="{Binding Name}" />
      </StackPanel>
      <StackPanel Orientation="Horizontal">
        <TextBlock Classes="Label" 
                   Text="Greeting: " />
        <TextBox Text="{Binding Greeting}" />
      </StackPanel>
    </StackPanel>
  </Border>
</Window>

Styling mit Inspiration vom Web

Einer der größten Unterschiede im XAML-Code zwischen WPF und Avalonia ist das Styling-System. Anders als bei anderen XAML-Frameworks wie WPF wurde bei Avalonia das Verhalten von CSS nachgebaut. Ein Style ersetzt also das Styling eines Controls nicht komplett, sondern ergänzt es. Dabei können beliebig viele Styles auf ein und dasselbe Control wirken.

Listing 5 soll hierzu einen ersten Eindruck geben, es definiert einen Style für das vorangegangene Beispiel aus Listing 4. Jeder Style definiert über einen Selector, auf welche Controls er wirkt. Der einfachste Fall ist die Angabe des Typnamens, hier im Beispiel gehen wir bei Border.InputArea bereits etwas weiter. Border ist der Typ des Controls, InputArea ist der Klassenname (siehe Eigenschaft Classes bei dem Border-Control in Listing 4). Innerhalb des Styles definieren wir weitere sogenannte Nested Styles, die auf Child Controls wirken. Das Ergebnis sehen wir in Abbildung 1.

<Style Selector="Border.InputArea">
  <Setter Property="Background" Value="#88888888" />
  <Setter Property="Padding" Value="10" />
  <Setter Property="CornerRadius" Value="10" />
  
  <Style Selector="^ TextBox">
    <Setter Property="Width" Value="250" />
  </Style>
  <Style Selector="^ StackPanel">
    <Setter Property="Spacing" Value="5" />
  </Style>
  <Style Selector="^ TextBlock.Label">
    <Setter Property="Width" Value="100" />
    <Setter Property="VerticalAlignment" Value="Center" />
  </Style>
</Style>

Abb. 1: Begrüßungsdialog mit angewendetem Styling

Hier am Beispiel sehen wir nur einen kleinen Bruchteil der Möglichkeiten des Styling-Systems von Avalonia. Das Avalonia-Team beschreibt in der Dokumentation eine lange Liste von möglichen Selektoren [3] – ein Blick lohnt sich. Das System wird ebenso regelmäßig erweitert, etwa durch die mit Version 11.3 eingeführten und an CSS Media Queries angelehnten Container Queries.

Avalonia DevTools

Features wie Hot Reload oder als Alternative einen visuellen Designer, wie wir ihn etwa noch aus den guten alten WinForms-Zeiten kennen, fehlen in Avalonia. Mit Avalonia Accelerate arbeitet das Avalonia-Team zurzeit genau an diesen Punkten. Avalonia Accelerate ist ein kostenpflichtiges Produkt, das Zusatzfeatures für Entwickler:innen von Avalonia-Applikationen enthält.

Im Open-Source-Paket von Avalonia werden schon länger integrierte DevTools angeboten, die über das NuGet-Paket Avalonia.Diagnostics bereitgestellt werden. Die beschriebenen Templates binden das NuGet-Paket direkt mit ein. Ein Tastendruck auf F12 reicht, um das DevTools-Fenster zu öffnen. Die DevTools helfen bei mehreren Aufgaben, so lassen sich Logical Tree und Visual Tree prüfen, ob sie die erwarteten Inhalte aufweisen. Der Logical Tree bildet dabei die Baumstruktur aus den XAML-Dateien ab. Der Visual Tree zeigt, was tatsächlich am Bildschirm gerendert wird – aufgrund von Templating i. d. R. deutlich mehr. Abbildung 2 zeigt, wie die DevTools von Avalonia aussehen.

Abb. 2: Avalonia DevTools

Noch ein Hinweis an alle Leser:innen, die Hot Reload oder einen Designer vermissen. In den DevTools können Werte von Eigenschaften direkt live geändert werden. Damit sieht man sofort, welche Änderungen zu welchen Effekten auf der Benutzeroberfläche führen.

Neben der Anzeige der Baumstrukturen bieten die DevTools weitere Features wie ein Tracking der von den Controls ausgelösten Events. Ebenfalls können performancerelevante Kennzahlen wie Rendering- und Layoutzeit eingeblendet werden. Unterm Strich sind die DevTools auf jeden Fall mehr als einen Blick wert.

Architektur von Avalonia

Nachdem wir uns in diesem Artikel mit einigen Eigenschaften von Avalonia beschäftigt haben, möchten wir unseren Blick noch einmal von der Vogelperspektive auf das UI-Framework werfen. Das hilft uns dabei, das UI-Framework noch besser zu verstehen und die Vor- und Nachteile gegenüber anderen UI-Frameworks abschätzen zu können.

Abbildung 3 gibt uns dafür einen groben Überblick. Ganz oben steht dabei Avalonia zusammen mit allen in Avalonia zur Verfügung gestellten Controls. Darunter liegt Skia. Skia ist ein Open-Source-2D-Rendering-Framework von Google, das unter anderem auch in modernen Browsern wie Google Chrome eingesetzt wird. Ähnlich wie auch Flutter nutzt Avalonia Skia zum Rendering aller Controls. Unterhalb von Skia liegt entweder die Core CLR oder die Mono Runtime – je nachdem, auf welcher Plattform oder auf welchem Gerät wir eine Avalonia-Applikation ausführen.

Abb. 3: Architektur von Avalonia (eigene Darstellung nach [4])

Als logische Konsequenz aus dieser Architektur verhalten sich Avalonia-Applikationen auf allen unterstützten Plattformen weitgehend gleich und sehen gleich aus. Im Vergleich zu Avalonia gibt es auch andere UI-Frameworks, die einen ähnlichen Ansatz verfolgen. WPF etwa rendert auch alle Controls selbst, baut allerdings auf das plattformabhängige Direct3D auf. Auch bei anderen Programmiersprachen finden wir Beispiele, etwa beim bereits angesprochenen Flutter von Google oder dem für C++-Entwickler:innen gedachten Qt.

Im Vergleich zu anderen UI-Frameworks in .NET ist der Ansatz von Avalonia nicht häufig anzutreffen. .NET MAUI beispielsweise geht einen anderen Weg. Dort werden Controls nicht selbst gerendert, sondern die jeweiligen nativen Controls der Plattformen genutzt. Ein Vorteil davon ist das native Look and Feel, ein Nachteil ist der deutlich größere Testaufwand. Aus Sicht des Autors ist es wichtig, solche Unterschiede zu kennen, sobald es um die Entscheidung für oder gegen ein UI-Framework geht.

Stärke am Desktop, Potenzial auf anderen Plattformen

Historisch hat Avalonia seine größte Stärke am Desktop. Die Unterstützung für die mobilen Plattformen Android und iOS ist zusammen mit der Unterstützung für den Browser erst in Version 11 am 7. Juli 2023 veröffentlicht worden. Entscheidet man sich auf diesen Plattformen für Avalonia, muss man damit rechnen, auf die eine oder andere Lücke zu stoßen. So bietet Avalonia von Haus aus kein Navigations-Control mit Behandlung des Zurück-Knopfs – andere UI-Frameworks mit Fokus auf mobile Plattformen wie .NET MAUI haben hier mehr zu bieten.

Das Potenzial, das Avalonia auf mobilen Plattformen hat, kann man mit einem Blick auf Flutter erkennen. Flutter ist von seiner Architektur her sehr ähnlich zu Avalonia und ist insbesondere für Cross-Platform-Applikationen für mobile Geräte ein sehr beliebtes UI-Framework außerhalb der .NET-Welt.

Die Community rund um Avalonia

Avalonia ist nicht nur aus der Community entstanden, die Community ist auch eine der größten Stärken des UI-Frameworks. Das Avalonia-Team pflegt eine Liste von Anlaufstellen, um sich mit der Community auszutauschen [5]. Dazu gehören ein Forum innerhalb des GitHub-Projekts auf Basis von GitHub Discussions und diverse Chats via Telegram und Discord.

Daneben existiert eine große Zahl von Open-Source-Projekten rund um Avalonia. Das GitHub-Projekt awesome-avalonia [6] ist ein guter Startpunkt, um Projekte zu finden, die für das eigene Projekt relevant sind.

Die Zukunft von Avalonia

Avalonia ist ein Open-Source-Projekt – mit dieser Tatsache steht für viele Interessierte die Frage im Raum, inwieweit das Team hinter Avalonia langfristig das Framework pflegt. Erfreulicherweise veröffentlicht Mike James, der CEO von Avalonia, regelmäßig Informationen darüber, wo die Prioritäten des Teams liegen und wie das Team aus Businesssicht aufgestellt ist. So beschreibt er in einem Blogpost vom 2. Dezember 2024, wie sich das Team zu diesem Zeitpunkt finanziert [7]. Der größte Einnahmeblock ist Avalonia XPF – ein kommerzielles Schwesterframework, das die Migration von WPF-Anwendungen auf andere Betriebssysteme erleichtert und zugleich einen Migrationspfad hin zu Avalonia bietet. Dieser Anteil dürfte sich im Juni 2025 geändert haben, denn zu diesem Zeitpunkt hat das Avalonia-Team eine 3 Millionen US-Dollar große Spende von der kanadischen Firma Devolutions erhalten [8].

Fazit

Avalonia gibt uns alle notwendigen Werkzeuge an die Hand, um Benutzeroberflächen für die verschiedensten Plattformen zu entwickeln. Insbesondere finden sich Entwickler:innen mit Erfahrung in XAML-basierten Frameworks wie WPF schnell zurecht. Aber auch der Umstieg von anderen Frameworks wie dem nach wie vor verbreiteten Windows Forms, ist kein Ding der Unmöglichkeit – hier muss allerdings Zeit zum Lernen der XAML-Syntax und des MVVM-Patterns hinzugerechnet werden.

Gerade der Support für Linux dürfte für viele Lesende spannend sein, da Microsoft selbst hier eine Lücke hinterlässt. Linux spielt in verschiedenen Bereichen der Industrie und insbesondere in der Embedded-Welt eine sehr große Rolle. Avalonia kann hier als mächtiges UI-Framework mit ebenso mächtigem .NET-Unterbau punkten.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Das Avalonia-Team stellt sich aus Sicht des Autors sinnvoll für die Zukunft auf. Sie erweitern das Open-Source-Paket mit Avalonia Accelerate um kommerzielle Zusatzkomponenten, die für professionelle Entwickler:innen zusätzliche Produktivität und Features liefern. Auch Avalonia XPF kann gerade bei einer größeren Migration eines WPF-Projekts spannend sein. Ganz nebenbei finanzieren diese Produkte die Weiterentwicklung am Open-Source-Paket Avalonia selbst, das auch für kommerzielle Projekte kostenlos zur Verfügung steht.

Frequently Asked Questions (FAQ)

1. Was ist Avalonia und wie unterscheidet es sich von WPF?

Avalonia ist ein Open-Source, Cross-Platform UI-Framework auf .NET-Basis, das von WPF inspiriert ist. Syntax und Controls sind nahezu identisch zu WPF, allerdings wurde die Architektur modernisiert und die Plattformunterstützung erheblich erweitert.

2. Welche Plattformen unterstützt Avalonia?

Ursprünglich unterstützte Avalonia nur Windows, macOS und Linux. Seit Version 11 (Juli 2023) sind zusätzlich Android, iOS sowie Browser-basierte Anwendungen (über WebAssembly) möglich.

3. Welche IDEs eignen sich für die Entwicklung mit Avalonia?

Visual Studio bietet mit einem offiziellen Plugin XAML-IntelliSense und Live Preview. JetBrains Rider hat die beste Integration out-of-the-box. Visual Studio Code kann ebenfalls genutzt werden, ist aber im Funktionsumfang am wenigsten komplett.

4. Wie startet man ein neues Avalonia-Projekt?

Über dotnet new install Avalonia.Templates lassen sich offizielle Templates installieren. Für Desktop empfiehlt sich „Avalonia .NET App“ oder „Avalonia .NET MVVM App“. Wer zusätzlich Android, iOS und Browser ansprechen möchte, nutzt „Avalonia Cross Platform Application“.

5. Was sind CompiledBindings und welche Vorteile bieten sie?

CompiledBindings generieren aus XAML bereits zur Compile-Zeit C#-Code. Dadurch wird Reflexion zur Laufzeit vermieden, die Performance steigt und Bindungsfehler werden bereits beim Kompilieren erkannt.

6. Welche MVVM-Frameworks werden mit Avalonia häufig eingesetzt?

Am verbreitetsten sind CommunityToolkit.Mvvm und ReactiveUI. Ersteres ist leichtgewichtig und nutzt Source Generators, während ReactiveUI sehr mächtig ist, aber auf Reactive Extensions basiert und eine höhere Lernkurve hat.

7. Wie funktioniert das Styling in Avalonia?

Avalonia orientiert sich am CSS-Modell. Styles können per Typ- oder Klassenselektoren gesetzt werden, mehrere Styles pro Control sind möglich, ebenso wie verschachtelte Styles. Mit Version 11.3 kamen moderne Features wie CSS-ähnliche Container Queries hinzu.

8. Welche Entwickler-Tools bietet Avalonia und was ist Avalonia Accelerate?

Mit Avalonia.Diagnostics stehen Open-Source DevTools bereit, die u. a. den Logical Tree, Visual Tree, Events und Performance-Daten live inspizieren lassen. Avalonia Accelerate ist ein kostenpflichtiges Zusatzpaket mit erweiterten Features wie Visual Designers und verbessertem Hot Reload.

Links & Literatur

[1] https://docs.avaloniaui.net/docs/get-started/set-up-an-editor

[2] https://github.com/AvaloniaUI/avalonia-dotnet-templates

[3] https://docs.avaloniaui.net/docs/reference/styles/style-selector-syntax

[4] https://docs.avaloniaui.net/docs/overview/what-is-avalonia

[5] https://docs.avaloniaui.net/docs/community

[6] https://github.com/AvaloniaCommunity/awesome-avalonia

[7] https://avaloniaui.net/blog/avalonia-ui-in-2024-growth-challenges-and-the-road-ahead

[8] https://github.com/AvaloniaUI/Avalonia/discussions/19108

The post Avalonia: Das bessere WPF für moderne Cross-Platform-Apps appeared first on BASTA!.

Samstag, 19.07.2025

Exploit bereits aktiv: Microsoft warnt öffentlich

Microsofts Sicherheitsteam (MSRC – Microsoft Security Response Center) hat am Samstagabend (in Deutschland war es da schon Sonntagfrüh) unter anderem auf der Plattform X gemeldet, dass eine Lücke in SharePoint aktiv ausgenutzt wird [1]. Wie üblich wurde auch gleich eine CVE-Nummer vergeben – diese Liste der „Common Vulnerabilities and Exposures“ dient der vereinfachten Nachverfolgung von öffentlich gewordenen Sicherheitslücken. Die zugewiesene Nummer war CVE-2025-53770, also die 53 770. CVE im Jahr 2025 (global, also natürlich nicht nur auf Microsoft oder gar SharePoint bezogen). Der Score-Wert hatte unfassbare 9,8 (auf einer Skala bis 10). Es war also höchste Gefahr in Verzug. Ein Blogeintrag des MSRC verriet weitere Details und wurde in den Folgetagen mehrmals aktualisiert (Abb. 1) [2].

Abb. 1: Microsofts Handreichung für betroffene Kunden

ToolShell-Analyse legt weitere Details offen

Das allein ist ja schon schlimm genug, aber von anderer Seite wurden Informationen nachgelegt. Die Sicherheitsforscher von Eye Security waren ebenfalls auf die Sicherheitslücke aufmerksam geworden [3]. Sie haben die Lücke selbst gar nicht gefunden, aber bereits am 18.07.2025, also am Vortag der Warnung des MSRC, die mehrfache Ausnutzung festgestellt. Ein griffiger Name war schnell gefunden: „ToolShell“. Zudem haben sie Informationen zusammengetragen und somit einige zusätzliche Details veröffentlicht, die im MSRC-Post noch gefehlt haben – wichtig für potenziell betroffene Firmen, weil nun sehr konkret zu sehen war, dass Handlungsbedarf besteht. Der Blogpost war sehr detailliert, sodass mit entsprechender Detektivarbeit der Exploit nachgebaut werden konnte.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

So funktioniert der Angriff: MachineKey im Visier

Kern des Problems war eine unsichere Deserialisierung einer der in ASP.NET Web Forms(!) entwickelten Seiten von SharePoint. In der Payload eines HTTP Requests konnten serialisierte Informationen an den Server geschickt werden und im Rahmen der Deserialisierung kam es dann zur Codeausführung. Bei den massenhaft erfolgten Angriffen wurde eine besonders perfide Variante der Codeeinschleusung gewählt: Der Exploit legte ein weiteres Web Form an, das dann per HTTP GET Request mehrere interne Serverinformationen inklusive dem MachineKey des Systems auslieferte. Gerade der MachineKey ist bei den meisten ASP.NET-Installationen zentral, dient er doch unter anderem als kryptografischer Schlüssel für den Zustandsverwaltungsmechanismus Viewstate. Ist dieser einem Angreifer bekannt, hat dieser bei SharePoint im Wesentlichen freie Hand, solange der MachineKey gültig ist – das kann selbst nach einem Patch so sein!

Frühere Lücken bieten Angriffsfläche

Es stellte sich schließlich heraus, dass die neue Verwundbarkeit eine Weiterentwicklung zweier erst jüngst bekannt gewordener Sicherheitslücken in SharePoint, CVE-2025-49704 [4] und CVE-2025-49706 [5] ist. Sie sehen es an der Nummer hinter der Jahreszahl: kleiner als 53770, aber in Schlagdistanz. Es zeigte sich: Diese CVEs wurden am 8.7.2025 veröffentlicht, der zweite Dienstag im Juli, und damit der turnusmäßige „Patch Tuesday“ von Microsoft. Es erschienen also zeitgleich Patches. Diese halfen aber gegen die neue Lücke offenbar nicht.

Sonntag, 20.07.2025

Erste Updates, aber keine Entwarnung

Rosig war die Situation am Morgen des 20.07.2025 also noch nicht. Kein Patch da, und der Blogpost von Microsoft war noch keine große Hilfe. In dessen ersten Fassung wurden als Gegenmaßnahmen unter anderem die Verwendung von Antivirensoftware genannt, dem Antimalware Scan Interface (AMSI) oder Microsoft Defender for Endpoint. Von einem Softwareupdate war da noch nicht die Rede. Dieses wurde am Sonntag, dem 20.07.2025, nachgereicht für SharePoint Subscription Edition [6] und 2019 [7]. Am Folgetag wurde auch für SharePoint Enterprise Server 2016 wird ein Patch veröffentlicht [8]. Außerdem hat Microsoft noch einen weiteren CVE veröffentlicht, CVE-2025-53771. Dieser hat einen niedrigeren Score als CVE-2025-53770, steht aber mit dem Vorgänger in Zusammenhang, und die verlinkten Updates beheben beide Lücken.

Wenn man weiß, wie lange es teilweise zwischen Bekanntwerdung einer Sicherheitslücke und Verfügbarkeit eines Patches dauert, ist das eine beeindruckende Leistung. Offenkundig tat diese auch Not, denn laut Eye Security wurden Dutzende SharePoint-Installationen gefunden, die bereits betroffen waren. Wer auch immer ein öffentlich verfügbares SharePoint betreibt, muss den Server auf Einbruchsspuren untersuchen und den Patch einspielen.

Was Admins jetzt prüfen und anpassen müssen

Mit dem Update von SharePoint allein ist es nicht getan. Gut möglich, dass der MachineKey bereits geklaut wurde. Deswegen ist eine Rotation des Schlüssels Pflicht. In der Regel ist das mit einem Neustart des IIS getan.

Montag, 21.07.2025

Fazit: Sicherheitsprozesse auf den Prüfstand stellen

Gleichwohl gilt es, diese Episode als Anlass zu nehmen, die Sicherheitsprozesse im Unternehmen zu prüfen und gegebenenfalls zu hinterfragen. Wenn Sie potenziell betroffen sind, fragen Sie sich selbst: Wo haben Sie erstmals von diesem Problem gehört – durch das MSRC, eine entsprechende Überwachungssoftware, oder gar diesen Artikel? Eine hundertprozentige Sicherheit kann und wird es nicht geben, aber ein zeitnahes Einspielen von Sicherheitspatches ist in aller Regel zwingend. In einem Fall wie diesem, bei dem der Exploit noch vor der Verfügbarkeit eines Softwareupdates existiert, sind öffentlich erreichbare Systeme ein einfaches Ziel. Und auch interne Systeme könnten betroffen sein, dann eben nur mit kleinerem Angreiferkreis. Der Exploit ist direkt einsetzbar im Internet zu finden und benötigt keine besonderen technischen Fähigkeiten. Es herrscht also weiterhin Alarmstufe Rot – zumindest bis Ihre SharePoint-Installationen aktualisiert wurden.

Frequently Asked Questions (FAQ)

1. Was ist CVE-2025-53770 und wann wurde sie öffentlich bekannt?

CVE‑2025‑53770 ist eine kritische Zero‑Day‑Sicherheitslücke in Microsoft SharePoint, mit einem CVSS‑Score von 9,8, die aktiv ausgenutzt wurde. Sie wurde am 19. Juli 2025 öffentlich bekanntgegeben, als Microsofts MSRC via X (ehemals Twitter) warnte.

2. Wie funktioniert der “ToolShell”-Exploit technisch?

Der “ToolShell”-Exploit nutzt unsichere Deserialisierung in ASP.NET Web Forms von SharePoint aus. Code wird ausgeführt, und ein Web‑Form wird genutzt, um interne Informationen wie den MachineKey zu extrahieren – dieser Schlüssel erlaubt Angreifern persistente Kontrolle auch nach Patches.

3. In welchem Kontext wurde CVE-2025-53770 gefunden?

CVE‑2025‑53770 stellt eine Weiterentwicklung (Patch‑Bypass) vorheriger Lücken CVE‑2025‑49704 und CVE‑2025‑49706 dar, die bereits am Patch‑Tuesday im Juli veröffentlicht wurden, aber gegen die neue Variante nicht wirksam waren.

4. Wann wurden erste Patches veröffentlicht, und für welche Versionen?

Ein Patch für SharePoint Subscription Edition und 2019 wurde am 20. Juli 2025 veröffentlicht. Am 21. Juli 2025 folgte ein Update für SharePoint Enterprise Server 2016. Zusätzlich wurde mit CVE‑2025‑53771 eine zweite, verwandte Lücke benannt – und beide Patches beheben beide Schwachstellen.

5. Sind Patches allein ausreichend zur Sicherung?

Nein. Das bloße Einspielen des Updates reicht nicht aus, da der MachineKey bereits gestohlen sein kann. Administrator:innen sollten diesen unbedingt rotieren – meist durch einen IIS‑Neustart –, um sicherzustellen, dass ein Angreifer keine andauernde Kontrolle behält.

6. Was sollte als Lehre aus diesem Vorfall gezogen werden?

Unternehmen sollten ihre Sicherheitsprozesse überdenken: Wie schnell haben Sie erfahren — durch Microsoft, Monitoring oder externe Quellen — von dieser Lücke? Zeitnahes Patching ist entscheidend, insbesondere bei öffentlich erreichbaren Systemen, deren Exploits leicht nutzbar sind.

7. Wann fanden die ersten aktiven Ausnutzungen statt?

Sicherheitsforscher von Eye Security beobachteten die Ausnutzung bereits am 18. Juli 2025, einen Tag bevor Microsoft öffentlich warnte. Der Name “ToolShell” wurde von ihnen geprägt.

Links & Literatur

[1] https://x.com/msftsecresponse/status/1946737930849939793

[2] https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/

[3] https://research.eye.security/sharepoint-under-siege/

[4] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49704

[5] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49706

[6] https://www.microsoft.com/en-us/download/details.aspx?id=108285

[7] https://www.microsoft.com/en-us/download/details.aspx?id=108286

[8] https://www.microsoft.com/en-us/download/details.aspx?id=108288

The post Kritische SharePoint-Sicherheitslücke CVE-2025-53770: Exploit aktiv im Umlauf appeared first on BASTA!.

Cursor: maximale Kontrolle und Kontexttiefe

Cursor (Abb. 1) richtet sich an Entwickler:innen, die umfassende Kontrolle und eine tiefgehende Kontextverarbeitung suchen [1]. Hervorzuheben ist insbesondere der Agent-Modus, bei dem Cursor in einem isolierten Shadow Workspace arbeitet und Änderungen zunächst vorbereitet, bevor sie in den eigentlichen Code übernommen werden. Dadurch können Entwickler:innen ganze Features autonom erstellen oder komplexe Refactorings durchführen.

Cursor zeichnet sich zudem durch einzigartige Erweiterungen aus: Mit @Web können Webinhalte als Kontext integriert werden, @Docs bindet Dokumentationen ein und Screenshots lassen sich direkt in Code umwandeln. Zusätzlich können Entwickler:innen zwischen KI-Modellen wie GPT, Gemini oder Claude wechseln und sogar eigene Modelle einbinden.

Abb. 1: Cursor – Chatansicht

Windsurf: ein Flow-orientierter Ansatz

Windsurf (Abb. 2) setzt mit seinem Cascade-Ansatz auf eine intuitive und flüssige Workflowerfahrung [2]. Der klar strukturierte Chat- und Schreibmodus führt Entwickler:innen systematisch durch komplexe Aufgaben. Im Bereich der Webentwicklung überzeugt Windsurf insbesondere durch eine visuelle Vorschau und direkte Deployment-Optionen aus der IDE heraus. Ein lokaler semantischer Index gewährleistet schnellen Zugriff auf relevante Codestellen, während sensible Daten sicher vor Ort bleiben und nicht in die Cloud übertragen werden.

Abb. 2: Windsurf – Welcome Screen

GitHub Copilot in VS Code: autonome Agenten und externe Inhalte

GitHub Copilot [3] (Abb. 3) hat sich im Jahr 2025 maßgeblich weiterentwickelt und integriert nun eine umfassende Agent-Funktionalität direkt in VS Code [4]. Der neue Agent-Modus ermöglicht die autonome Planung und Umsetzung komplexer Aufgaben. Copilot analysiert den gesamten Workspace selbstständig, schlägt Codeänderungen vor, führt Terminalbefehle aus und optimiert den Code iterativ bei auftretenden Problemen.

Zusätzlich bietet Copilot eine regelbasierte Generierung von Tests und Dokumentation, die Entwickler:innen direkt in VS Code konfigurieren können. Darüber hinaus ermöglicht Copilot automatisierte Codereviews innerhalb der IDE. Microsoft positioniert Copilot als unterstützenden Partner für die täglichen Aufgaben in der Softwareentwicklung.

Abb. 3: Copilot – Welcome Screen

Insgesamt bieten alle drei Tools verlässliche Unterstützung bei alltäglichen Programmieraufgaben, setzen jedoch unterschiedliche Schwerpunkte: Cursor bietet maximale Kontrolle und Tiefe, Windsurf ein fokussiertes, assistiertes Flow-Erlebnis (insbesondere im Frontend-Bereich) und Copilot unkomplizierte KI-Unterstützung in etablierten Entwicklungsumgebungen.

Gemeinsame Features

Im Jahr 2025 gehören zahlreiche KI-Funktionen zum Standard in AI-Codeeditoren. Die wichtigsten Features, die Cursor, Windsurf und Copilot gleichermaßen bieten, sind mehrzeilige Codevervollständigung mit Kontextverständnis, Chat-Assistenten zur Erklärung von Code und zur Behebung von Fehlern, automatische Generierung von Unit-Tests sowie die Integration verschiedener Large Language Models für unterschiedliche Anwendungsfälle.

Obwohl es viele Gemeinsamkeiten gibt, besitzt jede Lösung Alleinstellungsmerkmale, die sie für bestimmte Zielgruppen besonders attraktiv machen.

SIE LIEBEN UI?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Cursor: umfangreiche KI-Integration für Power-User

Cursor bezeichnet sich selbstbewusst als „The AI Code Editor“, was die tiefgreifende Integration zahlreicher KI-Funktionen widerspiegelt. Die IDE basiert auf einem Fork von VS Code und bietet somit umfassende Kompatibilität zu existierenden Erweiterungen und Workflows. Cursor entfaltet seine Stärken insbesondere bei komplexen Programmieraufgaben wie tiefgehenden Refactorings oder umfassenden Änderungen mehrerer Dateien.

Eine besondere Stärke ist der Shadow Workspace, in dem umfangreiche Codeänderungen in einer isolierten Umgebung ausprobiert werden können, bevor sie übernommen werden. Zudem bietet Cursor spezielle KI-Integrationen. Entwickler:innen können mit Hilfe der @Web-Funktion externe Webseiten indexieren und deren Inhalte als zusätzlichen Kontext direkt in den KI-Chat einfließen lassen. So lassen sich beispielsweise aktuelle API-Dokumentationen, Changelogs oder Tutorials integrieren (Abb. 4). Vordefinierte Dokumentationen bekannter Frameworks und Bibliotheken sind bereits im Tool enthalten und sofort einsatzbereit.

Abb. 4: Cursor – Docs-Index

Mit dem Multi-Chat-Support kann man mehrere KI-Chats parallel betreiben und dabei je nach Aufgabe verschiedene Modelle effizient einsetzen.

Cursor unterstützt darüber hinaus eine flexible Auswahl an KI-Modellen, darunter OpenAI GPT-4 und Anthropic Claude. Sogar eigene Modelle können angebunden werden, wodurch die IDE auch in stark spezialisierten und individuellen Szenarien äußerst leistungsfähig ist.

Windsurf: Flow-basierter Ansatz für intuitives Arbeiten

Anlässlich der Übernahme durch OpenAI hat Windsurf kürzlich viel Aufmerksamkeit auf sich gezogen. Wie Cursor basiert es auf einem Fork von VS Code und bietet eine tiefgehende Integration von KI-Funktionen in eine vertraute Arbeitsumgebung.

Ein Alleinstellungsmerkmal von Windsurf ist die intuitive „Cascade“-Oberfläche (Abb. 5), die den klassischen Editor- und Chatmodus vereint. Entwickler:innen können hier einfach zwischen Schreiben und Chatten wechseln, wodurch die Interaktion mit der KI besonders flüssig und natürlich wirkt. Windsurf glänzt vor allem bei der Webentwicklung durch die visuelle Livevorschau direkt in der IDE. Hierbei können Entwickler:innen UI-Elemente anklicken und Windsurf generiert automatisch passende Codeänderungen. Das Feedback ist somit sofort sichtbar und intuitiv nachvollziehbar.

Abb. 5: Windsurf – Cascade-Oberfläche

Windsurf speichert Konversationen und Programmierentscheidungen in sogenannten „Memories“ und ermöglicht den Betrieb eigener KI-Modelle auf lokaler Hardware.

Zusätzlich hebt sich Windsurf durch seine integrierten Deployment-Funktionen hervor. Damit können Anwendungen direkt aus der IDE heraus bereitgestellt werden. Das reduziert die Notwendigkeit externer CI/CD-Pipelines und vereinfacht den Entwicklungsprozess, insbesondere für kleinere Teams und Projekte.

VS Code mit GitHub Copilot: nahtlose Integration ins GitHub-Ökosystem

Die Kombination aus GitHub Copilot und VS Code überzeugt weniger durch exotische Einzelfeatures als vielmehr durch ihre tiefgehende und nahtlose Integration in bestehende Ökosysteme und Arbeitsprozesse. Copilot fühlt sich wie eine natürliche Erweiterung der beliebten IDE VS Code an und fügt sich nahtlos in die bewährten Arbeitsabläufe vieler Entwickler:innen ein.

Die wohl größte Stärke von GitHub Copilot ist die direkte und tiefe Integration mit den Funktionen der GitHub-Plattform. Copilot bietet zum Beispiel automatische Codereviews und generiert Pull-Request-Beschreibungen, was besonders in Team- und Enterprise-Umgebungen eine erhebliche Zeitersparnis mit sich bringt.

Darüber hinaus überzeugt Copilot durch die nahtlose Einbindung in das GitHub-Ökosystem, zu dem unter anderem GitHub.com, GitHub Desktop und GitHub Actions gehören.

Qualität der AI-Codevorschläge

Für die Entwicklung lautet die zentrale Frage: Wie gut sind die KI-Vorschläge tatsächlich? Mit anderen Worten: Wie gut unterstützen die Tools beim Coding, also wie korrekt, nützlich und effizient sind sie? Hier zeigt sich je nach Anwendungsfall ein differenziertes Bild. Zunächst ist wichtig zu erwähnen, dass in allen Tools die gleichen LLMs zur Auswahl stehen. Allerdings werden unterschiedliche System-Prompts und Tool-Calls eingesetzt, die die Ergebnisse entsprechend beeinflussen.

Alltags-Coding (einzelne Funktionen, Boilerplate)

Bei einfachen Szenarien, etwa beim Schreiben von Routinefunktionen, bei der Syntaxhilfe oder bei bekannten Algorithmen liefern alle drei Tools vergleichbar gute Ergebnisse. Cursor und Windsurf verwenden oft ähnliche oder sogar identische Modelle im Hintergrund. Für komplexere Aufgaben nutzen sie häufig Claude, während Copilot auf OpenAI-Modellen basiert. Bei Standardcode gibt es daher oft keinen drastischen Qualitätsunterschied. Entwicklerberichte bestätigen, dass die typische Codevervollständigung in allen drei Fällen zuverlässig funktioniert. Copilot profitiert dabei von seinen speziellen Trainingsdaten aus GitHub-Code: Er erkennt gängige Patterns und Framework-Konventionen präzise. Cursor und Windsurf generieren tendenziell längere und ausführlichere Codeblöcke (etwa detailliertere Kommentare oder mehrere zusammenhängende Zeilen), während Copilot minimalistisch Zeile für Zeile vorgeht.

Komplexe Aufgaben (projektweite Änderungen, unbekannte Probleme

Bei komplexeren Aufgaben kommen die Vorzüge von Cursor und Windsurf deutlich zum Tragen. Dank ihres erweiterten Kontextverständnisses und ihrer Agent-Fähigkeiten können beide Tools konsistente Änderungen über mehrere Dateien hinweg vorschlagen. Die praktische Erfahrung zeigt, dass beispielsweise beim Erstellen einer React-Komponente mit Modulinteraktionen in allen betroffenen Dateien korrekter Code generiert wird – inklusive passender Imports und Typdefinitionen. Copilot generiert in solchen Fällen eher einzelne Snippets, die manuell zusammengeführt und ergänzt werden müssen.

Ein besonders effektiver Ausführungsmodus ist der sogenannte Max Mode von Cursor, bei dem der verfügbare Kontextumfang und die Anzahl der internen KI-Operationen deutlich erweitert werden. Dadurch kann Cursor mehr Projektinformationen gleichzeitig berücksichtigen, umfangreiche Änderungspläne ableiten und selbst komplexe, modulübergreifende Aufgaben effizient bearbeiten. Diese Fähigkeit erweist sich als besonders wertvoll bei strukturellen Refactorings oder bei der Einführung neuer Features, die tief in bestehende Architekturen eingreifen.

Windsurf unterstützt solche komplexen Vorhaben durch seinen Flow-basierten Cascade-Ansatz. Dabei behält die KI den Projektzustand fortlaufend im Blick und gliedert umfangreiche Aufgaben in nachvollziehbare, aufeinander abgestimmte Schritte. So entstehen adaptive Vorschläge, die über mehrere Dateien hinweg konsistent bleiben. In der praktischen Anwendung zeigt sich: Beim Umbenennen einer zentralen Klasse erkennen sowohl Cursor als auch Windsurf alle Referenzen projektweit und schlagen entsprechende Anpassungen vor. Copilot hingegen erkennt solche Änderungen meist nur dateiweise.

Die „Projektweitsicht“ von Cursor und Windsurf erweist sich als besonders nützlich. Allerdings gibt es auch hier Einschränkungen. Die automatisch generierten Multi-File-Änderungen treffen nicht immer ins Schwarze. Cursors ambitionierte Vorschläge können – trotz aller Tiefe – auch neue Probleme einführen, während sie alte beheben. Tests mit Windsurf zeigen, dass nach größeren Codegenerierungsaufträgen mehrere Fehler auftreten können, die erst nach mehreren Iterationen ausgebessert werden. Copilot ist bei größeren Anforderungen gelegentlich überfordert oder missversteht die Intention, insbesondere bei reduziertem Kontextfenster oder kleinerem Modell.

Insgesamt gilt: Bei umfangreichen KI-Aktionen bleibt eine sorgfältige Codereview unerlässlich, da kein Assistent ganz fehlerfrei arbeitet.

Sprach- und Frameworkabdeckung

Alle drei Tools decken die populären Programmiersprachen (JavaScript/TypeScript, Python, Java, C#, C/C++, Go und PHP) hervorragend ab. GitHub Copilot hat durch seinen Trainingscorpus einen leichten Vorteil bei exotischeren Sprachen oder Frameworks, da es auf dem gesamten öffentlichen GitHub-Code basiert. Windsurf unterstützt eigenen Angaben zufolge über 70 Sprachen, darunter SQL, Bash, JSON und Markdown. Bei Cursor hängt die Sprachunterstützung vom gewählten Modell ab (GPT-4.1 und Claude bieten eine vergleichbare Sprachvielfalt). Durch ihre flexible Modellintegration können Cursor und Windsurf bei sehr neuen oder speziellen Frameworks oft schnellere Updates anbieten. Copilot profitiert hingegen vom kontinuierlichen Training durch Microsoft sowie vom Feedback einer großen Nutzergemeinde. Das führt zu verbesserten Prompt-Techniken und Fehlerfiltern.

Fazit zur Qualität der AI-Codevorschläge

Bei einfacheren Programmieraufgaben erweisen sich alle drei Tools als produktive Entwicklungswerkzeuge; die Unterschiede zeigen sich eher in Spezialfällen. Copilot überzeugt bei gängigen Patterns und stabilen Kurzvorschlägen, während Cursor und Windsurf bei holistischen, projektweiten Tasks dank ihres größeren Kontextverständnisses punkten. Die praktische Erfahrung zeigt: Copilot erweist sich im Alltag als besonders verlässlich, während Cursor gelegentlich mit zu vielen Informationen überfordert. Andererseits bewältigen Cursor und Windsurf komplexe Arbeitsschritte effizienter, die Copilot in dieser Form nicht abdeckt. Die Qualität der KI entwickelt sich laufend weiter. Mit neuen Modellversionen ist zu erwarten, dass alle drei Assistenten noch besser und kontextbewusster werden.

Architektur und technische Ansätze

Trotz des ähnlichen äußeren Erscheinungsbilds unterscheiden sich die Architekturen unter der Haube. Wie integrieren die Tools KI-Modelle, wo laufen diese und wie viel Kontext können sie verarbeiten?

Cursor

Die Macher von Cursor (Anysphere) setzen eine eigene Backend-Infrastruktur ein, die verschiedene KI-Modelle orchestriert. Cursor nutzt eine Mischung aus lokalen Komponenten und Cloud-Modellen: Beispielsweise läuft das Projekt-Indexing lokal: Ein eigener Dienst erstellt im Hintergrund Vektor-Embeddings aller Dateien, um schnellen semantischen Zugriff zu haben. Wenn ein Nutzer eine Frage in den Chat eingibt, werden per Embedding-Suche relevante Codeausschnitte gefunden und an das KI-Modell geschickt. Dieses Modell selbst läuft auf Servern. In der Pro-Version sind das Premium-Modelle wie Google Gemini oder Anthropic Claude. Interessant ist, dass Cursor mehrere Modellgrößen parallel einsetzt: kleine, schnelle Modelle (z. B. das eigene Codemodell cursor-fast) für Autocomplete-Vorschläge und große Modelle für komplexe Chatantworten. Für anspruchsvolle Aufgaben gibt es sogar einen Max Mode, der ein größeres Kontextfenster nutzt und dafür ggf. etwas mehr Wartezeit in Kauf nimmt.

Ein zentrales Konzept bei Cursor (und auch bei Windsurf) ist das Model Context Protocol (MCP). Es ermöglicht fortgeschrittene Automatisierungen. Man könnte beispielsweise einen MCP-Server einbinden, der Bugtickets aus Jira holt und sie dem Cursor-Agenten (Abb. 6) bereitstellt. Der Agent führt dann Codeänderungen im Kontext eines bestimmten Tickets durch. VS Code hat seit Kurzem ebenfalls eine MCP-Integration für den Copilote veröffentlicht.

Abb. 6: Cursor – Agent Demo

Die Agent-Architektur in Cursor funktioniert – vereinfacht dargestellt – so: Das System verfügt über einen Supervisor Prompt, der den KI-Modellen vorgibt, wie sie vorgehen sollen (z. B. iterative Planung, Validierung von Zwischenschritten). Cursor führt Agent-Aktionen in einem isolierten Bereich (Shadow Workspace) aus. Der eigentliche Code wird erst geändert, wenn man auf „Apply“ geklickt hat. Dadurch wird das Risiko reduziert, dass die KI ungeprüfte Änderungen verbreitet.

Windsurf

Im Unterschied zu Cursor bietet Windsurf KI-Funktionalität auch als Plug-in für verschiedene Editoren an. Im Weiteren konzentrieren wir uns jedoch auf Windsurf selbst. Architektonisch setzt Windsurf ebenfalls auf Projektindexierung, sogar sehr intensiv: Die Software indexiert die gesamte Codebasis lokal (mit Embeddings) und hält diese ständig aktuell, um jederzeit Kontext liefern zu können. Der Vorteil ist, dass der Codekontext lokal und privat bleibt – d. h., die konkreten Codezeilen müssen nicht vollständig in die Cloud geladen werden, sondern nur abstrakte Vektorrepräsentationen. Auf diese Weise kann Cascade nicht nur schneller als reine Cloud-Lösungen relevante Stellen finden, sondern auch bei begrenzter Internetverbindung performen.

Die KI-Modelle hinter Windsurf sind vielfältig: Windsurf verfügt über eigene Modelle (trainiert auf Open-Source-Code) für Basisszenarien und Autocompletion. Für anspruchsvollere Aufgaben setzt Windsurf stark auf Claude 4 von Anthropic (wie auch Cursor). Mit der Übernahme durch OpenAI werden in Zukunft wahrscheinlich vermehrt OpenAI-Modelle zum Einsatz kommen. Windsurfs Architektur betont zwei Dinge: geringe Latenz und agentische Intelligenz. Ersteres wird unter anderem durch einen eigenen optimierten Model-Server und ggf. kleiner dimensionierte Modelle für schnellen Inline-Support erreicht. Letzteres – die Agent-Fähigkeit – wird durch Flows realisiert: Cascade gliedert komplexe Aufgaben in Schritte und nutzt Toolintegration (z. B. Terminal, Linter, Dateimanagement) in einem steuernden Loop. Die KI sieht in Windsurf immer den gesamten Zustand des Projekts (inklusive ihrer letzten Aktionen), wodurch eine Art „Gedächtnis“ entsteht. So kann Cascade z. B. nachvollziehen, was zuletzt manuell geändert wurde und darauf aufbauend den nächsten Vorschlag kontextuell anpassen.

Ein Aspekt, den sowohl Windsurf als auch Cursor abdecken, ist die Fehlerbehandlung: Beide erkennen, wenn generierter Code Linter- oder Kompilierungsfehler produziert, und iterieren automatisch nach. Windsurf fixt sogar autonom mit Cascade Linter Fails, bevor sie dem Entwickler auffallen. Diese Automatisierungsschleifen sind Teil des jeweiligen Agent-Designs.

VS Code mit Copilot

Copilot unterscheidet sich architektonisch von Windsurf und Cursor dadurch, dass es kein eigenständiger Editor ist, sondern ein an bestehende IDEs angebundener Cloud-Service (Abb. 7). In VS Code läuft Copilot als Extension, die mit GitHubs Cloud kommuniziert. Die Integration geschieht über einen spezifischen, dem Language Server Protocol ähnlichen Kanal: Microsoft hat für Copilot damit einen universellen KI-Server erstellt, den VS Code, JetBrains IDEs und sogar Vim, Neovim, Xcode usw. nutzen können. Das bedeutet: Wenn Sie in VS Code tippen, sendet die Copilot-Extension den Inhalt Ihres Editors (Fensterinhalt und die umgebenden 100 bis 150 Zeilen) an das Cloud-API und bekommt die Vervollständigungen zurück. Nichts davon läuft lokal, außer dem UI-Element, das den Vorschlag einblendet.

Abb. 7: Copilot-Demo

Für den Chat- und Agenten-Modus greift die Copilot-Chat-Extension auf einen neuen Mechanismus zurück, der auf semantischer Codeindexierung basiert. Das System erstellt automatisch Embeddings aller Projektdateien und ermöglicht so schnelle, kontextbezogene Antworten. Dabei werden auch weitere offene Dateien oder vom Nutzer explizit angehängte Abschnitte berücksichtigt. Seit Copilot ChatGPT-4 nutzt und die neue Indexierung implementiert wurde, kann der Chat deutlich effizienter auf größeren Codebasen operieren. Die Repo-Integration nutzt dabei GitHubs eigenes Indexing-System: Wenn das Projekt ein Git-Repo ist und mit GitHub verbunden ist, werden alle Projektdateien und Commits automatisch semantisch indiziert. Das ermöglicht eine schnelle und präzise Kontextbereitstellung für das Copilot-Modell, sowohl in der IDE als auch in GitHub Codespaces.

Während Cursor und Windsurf mit ihren Agenten lange Zeit ein Alleinstellungsmerkmal besaßen, veröffentlichte GitHub im Jahr 2025 seinen eigenen Agenten für VS Code sowie in einer ersten Betaversion für Visual Studio und die JetBrains IDEs. Alle in den vorherigen Abschnitten beschriebenen Agenten-Features wie das automatische Editieren über mehrere Dateien hinweg, MCP-Tools und Linting werden ebenfalls unterstützt. Lediglich die Auswahl an LLMs und das damit verbundene Kontextfenster sind im Vergleich weiterhin stark limitiert.

Kontextfenster und System-Prompts

Alle drei Lösungen nutzen Großmodelle mit sogenanntem Prompt-Engineering. Das bedeutet, dass vor der eigentlichen Nutzereingabe ein unsichtbarer System- oder Instruktions-Prompt gesendet wird, der das Verhalten steuert (z. B. „Du bist ein hilfreicher Kodierungsassistent …“). Diese Prompts sind in Cursor/Windsurf tendenziell komplexer, da die Agenten verschiedene Tools steuern müssen. Es gibt dort Kaskaden von Aufforderungen (z. B. ein Prompt, der dem Modell beibringt, wie es Shellbefehle vorschlägt und auf Bestätigung wartet). In Copilot ist das Prompting dagegen einfach gehalten und auf Inline-Suggestions optimiert. Für die Endnutzer:innen sind diese Systemdetails jedoch weitgehend unsichtbar. Wichtig ist eher die Kontextgröße: Copilot (GPT-4.1) kann bis zu 128 k Tokens Kontext verarbeiten, Cursor und Windsurf (Claude 4) bis zu 200 k Tokens. Beide nutzen jedoch Retrieval, das heißt, sie „füttern“ das Modell nur mit relevanten Ausschnitten statt mit allen Dateien.

Insgesamt folgen Cursor und Windsurf dem Prinzip „KI komplett in den Editor integrieren“, während Copilot das Prinzip „Editor mit Cloud-KI erweitern“ verkörpert. Das spiegelt sich in der Architektur deutlich wider.

Integration in bestehende Toolchains

Neben der reinen KI-Leistung ist für viele Entwickler:innen entscheidend, wie gut sich ein Tool in ihren vorhandenen Workflow einfügt. Hier gibt es markante Unterschiede zwischen den Ansätzen.

IDE- und Editorunterstützung

GitHub Copilot bietet die breiteste Integration. Er funktioniert nahtlos in VS Code, Visual Studio, allen gängigen JetBrains IDEs (via offizielles Plug-in) sowie in Neovim/Vim und sogar Xcode. Microsoft stellt sicher, dass Copilot dort wie eine native Autocomplete-Funktion wirkt (z. B. erscheinen Copilot-Vorschläge in IntelliJ wie normale Codevervollständigungen). Ähnlich breit ist die Unterstützung von Windsurf: Als Windsurf-Plug-in gibt es Unterstützung für über 40 Editoren, darunter JetBrains, VS Code, Vim/Emacs, Jupyter Notebooks usw. Allerdings bietet das Plug-in nicht den vollen Funktionsumfang der Windsurf-Editor-App: Cascade-Agent und Flows sind in der Stand-alone-IDE beispielsweise mächtiger als im VS-Code-Plug-in, wo oft nur eine dateibezogene Vervollständigung möglich ist.

Cursor geht einen anderen Weg: Hier ist die IDE selbst Teil des Produkts. Es gibt keine Plug-ins für IntelliJ oder Ähnliches – man lädt die Cursor IDE herunter (verfügbar für Mac, Windows und Linux). Erfahrenen VS-Code-Nutzern fällt der Umstieg leicht, da Cursor den Import von VS-Code-Themes, -Einstellungen und -Extensions erlaubt. So kann man seine gewohnte Entwicklungsumgebung größtenteils in Cursor nachbilden. Dennoch bleibt es eine eigene IDE, d. h., wer z. B. tief im Visual-Studio-/JetBrains-Ökosystem verwurzelt ist, muss für Cursor die Umgebung wechseln. Zusammengefasst: Copilot integriert sich am flexibelsten in existierende IDEs, Windsurf bietet sowohl ein Plug-in für viele IDEs als auch eine eigene Editoroption und Cursor setzt auf seine All-in-one-IDE.

Versionsverwaltung (Git) und Collaboration

Alle drei Tools lassen sich mit Git verwenden, der Mehrwert variiert jedoch: In Cursor steht ein gewohntes Git-Panel zur Verfügung (dank der VS-Code-Basis) und es können Commits und Pushs ausgeführt werden. Zusätzlich kann Cursor KI-Features auf Git anwenden, beispielsweise kann per Quick Actions ein Diff erklärt werden oder ein Quick Fix-Button bei Fehlern in der Git-Diff-Ansicht angezeigt werden. Windsurf integriert Git ähnlich (als Editorfunktion) und alle drei Tools unterstützen die automatische Generierung von Commit Messages – das spart viel Zeit und sorgt für saubere Commits. Copilot selbst ist unabhängig von Git, aber GitHub als Plattform nutzt Copilot-Technik. Beim Erstellen eines Pull Requests auf GitHub.com können z. B. automatisch Beschreibungstexte generiert werden. Ein besonderes Feature von GitHub Copilot ist die Möglichkeit, Codereviews direkt in VS Code oder auf GitHub durchzuführen. Das zeigt die Richtung: Copilot soll ein KI-Coreviewer im Team werden.

Dokumentation und Knowledge Base

So kann ein Team beispielsweise interne API-Dokumente als Kontextquelle einbinden. Windsurf verfügt über ein Rules & Memories Panel, in dem Guidelines und wichtige Informationen abgelegt werden können – eine Art teaminterne Wissensbasis für die KI. Copilot bietet ebenfalls die Möglichkeit, benutzerdefinierte Regeln zu hinterlegen, und kann über die #fetch-Direktive Webdokumentationen als zusätzlichen Kontext einbinden. Die Integration und Verwaltung von Dokumentationen und Webinhalten ist jedoch in Cursor am ausgereiftesten umgesetzt.

Einbindung anderer Tools

Alle drei Tools bieten MCP-Server-Unterstützung mit gleichwertiger Integration für Drittsysteme. GitHub Copilot lässt sich über die Open-Source-VS-Code-Extensions-Plattform erweitern. Durch die kürzlich erfolgte Öffnung des Plug-in-Systems durch Microsoft ergeben sich noch mehr Möglichkeiten für Plug-ins von Drittanbietern. Zusätzlich ist Copilot nahtlos in Codespaces (Cloud-Dev-Umgebungen von GitHub) integrierbar: In einem Codespace steht Copilot ohne zusätzliche Konfiguration zur Verfügung, was die Cloud-Entwicklung vereinfacht.

Sicherheit und Datenschutz

In professionellen Umgebungen ist dieser Aspekt besonders wichtig: Copilot für Business garantiert, dass keine Kundencodefragmente zur Modellverbesserung verwendet werden. Außerdem gibt es Regler zur Blockierung von vertraulichem Code in den Vorschlägen. Cursor ist SOC-2-zertifiziert und verfügt über einen Privacy Mode, bei dem kein Code auf den Servern gespeichert bleibt. Windsurf betont, dass das Training ausschließlich auf Open-Source-Daten erfolgt und keine Nutzerdaten gespeichert oder geteilt werden. Außerdem bleiben durch das lokale Indexing viele Informationen auf dem Rechner. Für Enterprise-Kunden bietet Windsurf auch On-Premises-Optionen (eigene Server mit dem KI-Modell) an. Je nach Unternehmensrichtlinien muss geprüft werden, welcher Anbieter konform ist. Stand 2025 bieten alle drei Wege die Möglichkeit, die Nutzung datenschutzkonform zu gestalten (sei es via Vertragszusatz oder Self-Hosting bei Windsurf Enterprise).

Insgesamt gilt: Copilot punktet bei der Integration, wenn man bereits stark im GitHub-/MS-Ökosystem unterwegs ist und verschiedene IDEs nutzt. Windsurf ist attraktiv, wenn man KI in bestehenden Editoren einsetzen will (überall gleiche KI-Unterstützung via Plug-in) oder wenn man speziell im Webbereich eine Alles-in-einem-IDE sucht. Cursor richtet sich an Entwickler:innen, die bereit sind, ihre Haupt-IDE zu wechseln, um die volle KI-Power zu nutzen. Dafür belohnt Cursor mit tiefer KI-Verschmelzung, aber es ist eben ein separates Programm.

Integration in bestehende Toolchains

In der Praxis hat jede Lösung ihre Vor- und Nachteile, die von den Vorlieben und Bedürfnissen der Entwickler:innen abhängen. Im Folgenden finden Sie eine Übersicht der wichtigsten Eindrücke aus der Entwicklercommunity.

Cursor: Power-Tool mit moderner Oberfläche

Cursor überzeugt durch seine leistungsstarken Funktionen und die schnelle Umsetzung komplexer Änderungen. Besonders in der professionellen Entwicklung bietet die IDE auf Knopfdruck „jedes erdenkliche AI-Feature“. Die KI-Unterstützung ist allgegenwärtig – vom Einfügen fehlender Imports bis zum Komplett-Refactoring mit Agenten. Die mehrfach überarbeitete Benutzeroberfläche präsentiert sich nun aufgeräumt und intuitiv. Das moderne UI ermöglicht einen effizienten Workflow, ohne dass dabei Funktionsvielfalt eingebüßt wird. Die Steuerung setzt auf manuelle Kontrolle: Im Standardmodus erfordern KI-Änderungen einzelne Bestätigungen. Das bietet zwar Sicherheit, unterbricht aber den Arbeitsfluss. Die Lernkurve ist steil – die Einarbeitung in Chat, Agenten, Shortcuts und @-Tags benötigt Zeit. Das Ergebnis ist jedoch ein äußerst anpassbares Entwicklungswerkzeug. Performancetechnisch läuft Cursor auf modernen Systemen flüssig, wobei umfangreiche Agent-Aktionen einige Sekunden Verarbeitungszeit benötigen.

Windsurf: intuitiv und flüssig, aber noch jung

Windsurf überzeugt durch seine moderne, aufgeräumte Benutzeroberfläche. Die KI fügt sich harmonisch in den Workflow ein, und die Bedienung ist intuitiv gestaltet. Der Cascade-Agent führt durch die Entwicklung, während die automatische Kontexterkennung selbstständig die relevanten Dateien auswählt. Mit Hilfe des Write/Chat-Umschalters lässt sich eine klare Trennung zwischen Codegenerierung und Erklärungen erreichen. Die größte Stärke von Windsurf ist das „Flow“-Gefühl: Die KI arbeitet kontinuierlich im Hintergrund, ohne den Entwicklungsprozess zu unterbrechen.

Verbesserungsbedarf besteht jedoch in puncto Zuverlässigkeit: Der Cascade-Agent erkennt Kontexte nicht immer korrekt und die Vorschaufunktion zeigt gelegentlich Schwächen. Positiv fallen die regelmäßigen Updates (monatliche „Waves“) auf. Die Performance wurde priorisiert. Windsurf reagiert sehr schnell bei Inline Suggestions, allerdings benötigt der erste Indexing-Durchlauf bei großen Projekten mehrere Minuten.

VS Code mit Copilot: etabliert und vielseitig

Copilot in VS Code hat sich für viele Entwickler:innen zu einem stillen Helfer entwickelt. Er funktioniert meist, ohne dass man es bewusst bemerkt. Die Vorschläge wirken natürlich (sie erscheinen als grauer Text und werden mit der TAB-Taste akzeptiert) – wer IntelliSense gewohnt ist, empfindet Copilot als dessen Erweiterung. Die Stärken von Copilot sind die hohe Treffsicherheit bei Routineaufgaben – dank des Trainings mit massenhaft Code schreibt Copilot beispielsweise Schleifen, API-Calls und bekannte Algorithmen oft fehlerfrei aus dem Stand – und die breite IDE-Unterstützung über VS Code, Visual Studio, IntelliJ IDEs und XCode, wobei VS Code als Hauptplattform priorisiert wird. Copilot ist mit etwa zwei Jahren auf dem Markt ausgereift: Die Ausfallzeiten sind gering, die Latenz minimal und die Integration bereitet keine Probleme. Viele schätzen auch die geringen Kosten – Copilot kostet 10 $ pro Monat, Cursor 20 $ und Windsurf 15 $.

Mit der Einführung des Agent-Modus, des MCP-Supports und der Möglichkeit, externe Webinhalte einzubinden, hat Copilot zu seinen Konkurrenten aufgeschlossen. Der Agent-Modus ermöglicht automatisierte Aufgaben und Multi-File-Refactoring, während der MCP-Support die Integration von Drittsystemen erleichtert.

In Team- und Enterprise-Umgebungen hat Copilot einen Trumpf: die Reputation und den Support von GitHub. Große Firmen bevorzugen in der Regel einen etablierten Anbieter mit Supportvertrag. Copilot lässt sich über Azure OpenAI auch als on-Premises-ähnlicher Service buchen – eine Option für Unternehmen, die Datenhoheit verlangen.

Fazit: Welche IDE für welchen Anwendungsfall?

Zum Abschluss einige Empfehlungen für verschiedene Zielgruppen und Zwecke – denn „das beste Tool“ gibt es nicht, es kommt darauf an, was man damit vorhat.

GitHub Copilot (in VS Code) – empfehlenswert für …

… Entwickler:innen, die einen bewährten und kostengünstigen KI-Assistenten suchen, der sich ohne Aufwand in ihren bestehenden Entwicklungsprozess einfügt. Wenn Sie bereits VS Code oder JetBrains IDEs nutzen und bessere Autocompletion sowie gelegentliche Chathilfe wünschen, ist Copilot ideal. Er brilliert bei Alltagsaufgaben, unterstützt eine enorme Bandbreite an Sprachen und verfügt über eine große Community und Support als Rückendeckung. Mit der Einführung des Agent-Modus und MCP-Support steht Copilot den anderen Lösungen auch im Hinblick auf Features in nichts nach. Ebenso spricht viel für Copilot, wenn das Budget ein Kriterium ist oder man in einem Unternehmen mit strikten Richtlinien arbeitet (Copilot for Business bietet entsprechenden Support und Compliance).

Cursor AI – empfehlenswert für …

… Entwickler:innen, die einen bewährten und kostengünstigen KI-Assistenten wünschen, sowie für Advanced Developer und Softwarearchitekten, die komplexe Codebasen betreuen und bereit sind, in ein neues Tool zu investieren. Cursor spielt seine Stärken aus, wenn ein tiefes Projektverständnis gefragt ist – z. B. beim Refactoring großer Codebestände, beim schrittweisen Ausbau einer bestehenden Architektur oder wenn ein einzelner Entwickler sehr viel erledigen möchte (Cursor wirkt fast wie ein zweiter Entwickler, der einem nebenher Aufgaben abnimmt). Die Möglichkeit, mit verschiedenen KI-Modellen zu experimentieren, sowie die Integration von Websuche und firmeneigenen Dokumentationen sind für viele Profis ein Plus. Wenn Sie also gerne „Early Adopter“ von KI-Funktionen sind und die eigene Produktivität maximieren möchten, ist Cursor einen Blick wert. Bedenken Sie aber: Sie müssen Ihre Arbeitsgewohnheiten etwas umstellen (neue IDE) und sich mit den vielen Features vertraut machen, sonst nutzen Sie vielleicht nur 20 Prozent des Potenzials. In kleineren Teams ist Cursor äußerst leistungsfähig. In großen Teams mit heterogener Toollandschaft könnte die Einführung jedoch auf Widerstand stoßen.

Windsurf – empfehlenswert für …

… Entwickler:innen, die Wert auf einen reibungslosen KI-Workflow legen und viel im Web-/Mobile-Bereich unterwegs sind. Windsurfs eigene IDE ist hervorragend geeignet, um neue Projekte schnell zu realisieren – beispielsweise einen Prototyp, bei dem die KI gleich Code, Tests und Deployment vorbereiten soll. Dank der visuellen Vorschau und der Schritt-für-Schritt-Agentenlogik bleibt man im „High-Level“-Denken und lässt die KI vieles ausführen. Auch KI-Neulinge oder weniger erfahrene Coder:innen profitieren von Windsurf: Es fühlt sich an, als hätte man einen Mentor, der mitdenkt (z. B. schlägt Windsurf vor, was als Nächstes zu tun sein könnte). Wenn Sie hingegen Ihren Lieblingseditor nicht aufgeben wollen, bietet das Plug-in von Windsurf die Kernfunktionen von Windsurf überall. Das ist ideal für gemischte Teams, z. B. VS-Code- und IntelliJ-Nutzer, die einen einheitlichen KI-Assistenten möchten. Zu beachten ist, dass Windsurf als Produkt noch jung ist. Es ist also perfekt für diejenigen, die Experimentierfreude mitbringen und Feedback geben möchten, um zu helfen, eventuelle Probleme zu lösen. Größere Unternehmen könnten Windsurf attraktiv finden, da Windsurf bereits Selbsthosting und Datenschutzoptionen anbietet, etwa für Firmen, die kein Hochladen von Code in externe Clouds dulden. Außerdem ist Windsurf preislich fair (es gibt eine Free Tier).

Fazit

Alle drei Kandidaten zeigen, wie KI die Softwareentwicklung revolutioniert. Welche Lösung die beste ist, hängt vom persönlichen Workflow und Anwendungsgebiet ab. Professionelle Entwickler:innen und Architekt:innen sollten sich überlegen, welche Rolle die KI einnehmen soll: als dezenter Helfer im Hintergrund (Copilot), umfassender Projektassistent mit allen Schikanen (Cursor) oder als Flow-orientierter Partner, der Entwicklerergonomie großschreibt (Windsurf). Um den eigenen Perfect Fit zu finden, lohnt es sich, alle einmal auszuprobieren. Es gibt für alle kostenfreie Testphasen.

Frequently Asked Questions (FAQ)

1. Was ist Cursor?

Cursor ist eine eigenständige, KI-native Entwicklungsumgebung, die auf Visual Studio Code basiert. Sie bietet tief integrierte KI-Funktionen und unterstützt Entwickler bei komplexen Aufgaben mit automatisierten Workflows.

2. Was unterscheidet Windsurf von anderen KI-IDEs?

Windsurf legt den Schwerpunkt auf Datenschutz und lokales Projektverständnis. Der Editor indexiert Code lokal und ermöglicht KI-gestützte Abläufe über mehrere Dateien hinweg, ohne sensible Daten in die Cloud zu senden.

3. Wie funktioniert GitHub Copilot?

GitHub Copilot ist keine eigenständige IDE, sondern eine Erweiterung für Editoren wie Visual Studio Code. Sein Vorteil ist die enge Integration mit GitHub, sodass Pull-Requests, Issues und Repositories direkt einbezogen werden können.

4. Welche Unterschiede gibt es beim Datenschutz?

Cursor und Windsurf setzen verstärkt auf lokale Verarbeitung und Schutz von Quellcode. Copilot arbeitet hingegen cloudbasiert, bietet aber durch GitHub eine enge Anbindung an Entwickler-Workflows.

5. Wie unterscheiden sich die Preismodelle?

Die drei Tools bieten unterschiedliche Preismodelle: Cursor und Windsurf mit gestaffelten Tarifen, Copilot mit einem günstigeren Abo, das besonders durch GitHub-Integration attraktiv ist. Die Wahl hängt von Budget und Teamgröße ab.

6. Für wen eignet sich Cursor?

Cursor richtet sich an Entwickler:innen, die eine komplett KI-native IDE suchen. Besonders bei komplexen Projekten mit vielen Dateien entfaltet Cursor seine Stärken.

7. Welche Zielgruppe passt zu Windsurf?

Windsurf eignet sich für Teams, die Datenschutz und lokale Datenhaltung priorisieren. Es bietet gleichzeitig flexible KI-Workflows über mehrere Dateien hinweg.

8. Wer profitiert am meisten von GitHub Copilot?

GitHub Copilot ist ideal für Entwickler:innen, die GitHub intensiv nutzen und eine nahtlose Integration in bestehende Workflows wünschen. Durch die Anbindung an Repositories und Issues erleichtert es den Alltag im GitHub-Ökosystem.

Links & Literatur

[1] https://cursor.com

[2] https://windsurf.com

[3] https://github.com

[4] https://code.visualstudio.com

The post KI-IDEs im Vergleich: Cursor, Windsurf & Copilot appeared first on BASTA!.

• das .NET 10.0 SDK [1], das die drei .NET-Laufzeitumgebungen beinhaltet, sowie
• Visual Studio 2022 Version 17.14.

.NET 10.0 SDK kann direkt zusammen mit Visual Studio 2022 Version 17.14 installiert werden.

C# 14.0: Erweiterungsmitglieder (Extension Members)

Die nachträgliche Erweiterbarkeit von Klassen (auch wenn diese bereits anderenorts kompiliert sind, z. B. in den von Microsoft gelieferten Klassen in den .NET-Klassenbibliotheken) um zusätzliche Methoden, gibt es unter dem Namen „Extension Methods“ bereits seit C#-Sprachversion 3.0, die zusammen mit .NET Framework 3.5 im Jahr 2007 erschienen ist. Man kann mit Extension Methods aber lediglich eine Instanzmethode zu bestehenden Klassen ergänzen. So mussten Entwicklerinnen und Entwickler zwangsweise Konstrukte, die vom Namen her eigentlich Properties waren, leidigerweise als Methoden ausdrücken, siehe IsEmptyClassic() in Listing 1.

public static class StringExtensionClassic
{
  public static string TruncateClassic(this string s, int count)
  {
    if (s == null) return "";
    if (s.Length <= count) return s;
    return s.Substring(0, count) + "...";
  }

  public static bool IsEmptyClassic(this string s)
    => String.IsNullOrEmpty(s);
}

In der .NET-Klassenbibliothek gibt es aus diesem Grund einige Erweiterungsmethoden, die Namen besitzen, die man intuitiv als Property erwarten würde, z. B.:

• Enumerable.Count()
• Queryable.Count()
• Enumerable.First()
• Enumerable.Last()

In C# 14.0 bietet Microsoft nun mit dem neuen Blockschlüsselwort extension eine verallgemeinerte Möglichkeit der Erweiterung bestehender .NET-Klassen, die „Extension Members“ heißt.

Das Schlüsselwort extension muss Teil einer statischen, nichtgenerischen Klasse auf der obersten Ebene sein (also keine Nested Class). Nach dem Schlüsselwort extension deklariert man den zu erweiternden Typ (Receiver). In Listing 2 ist der Receiver die Klasse System.String (alternativ abgekürzt durch den eingebauten Typ string). Alle Methoden und Properties innerhalb des Extension-Blocks erweitern dann den hier genannten Receiver-Typ. Aktuell kann man in diesen Extension-Blöcken folgende Konstrukte verwenden (Listing 2):

• Instanz-Methoden
• statische Methoden
• Instanz-Properties mit Getter
• statische Properties mit Getter

Eine Klasse darf mehrere Extension-Blöcke sowie zusätzlich auch klassische Extension Methods und andere statische Mitglieder enthalten (Listing 2). Das erlaubt Entwicklerinnen und Entwicklern, eine bestehende Klasse mit Extension Methods um Extension-Blöcke zu erweitern. Es darf auch mehrere Klassen mit Extension-Blöcken für einen Receiver-Typ geben.

public static class MyExtensions
{
  extension(System.String s)
  {
  
    // Erweitern um eine Instanz-Methode
    public string Truncate(int count)
    {
      if (s == null) return "";
      if (s.Length <= count) return s;
      return s.Substring(0, count) + string.Dots;
    }
 
    // Erweitern um eine Instanz-Eigenschaft
    public bool IsEmpty => String.IsNullOrEmpty(s);
 
    // Erweitern um eine Instanz-Eigenschaft mit Getter und Setter
    public int Size
    {
      get { return s.Length; }
      set
      {
        if (value < s.Length) s = s.Substring(0, value);
        if (value > s.Length) s = s + new string('.', value - s.Length); // Neuzuweisung geht nicht !!!
      }
    }
  
    // Erweitern um eine statische Methode
    public static string Create(int count, char c = '.')
    {
      return new string(c, count);
    }
  
    // Erweitern um eine statische Instanz-Eigenschaft
    public static string Dots => "...";
  }
  
  // Es darf auch eine Extension für einen anderen Typen geben
  extension(List<int> source)
  {
    public List<int> WhereGreaterThan(int threshold)
      => source.Where(x => x > threshold).ToList();
 
    public bool IsEmpty
      => !source.Any();
 
    // Erweitern um eine Instanz-Eigenschaft mit Getter und Setter
    public int Size
    {
      get { return source.Count; }
      set
      {
        if (value < source.Count) source = source.Take(value).ToList();
        if (value > source.Count) source.AddRange(Enumerable.Repeat(0, value - source.Count));
      }
    }
  }
  
  // Es kann auch eine klassische Extension Method in der gleichen Kasse geben
  public static string TruncateClassic2(this string s, int count)
  {
    if (s == null) return "";
    if (s.Length <= count) return s;
    return s.Substring(0, count) + "...";
  }
  
  // Es kann auch andere statische Methoden in der gleichen Klasse geben
  public static Version ExtensionVersion => new Version(1, 0, 0);
}

Zu beachten ist:

• Man kann mit Extension Members auch das Gleiche tun, was Extension Methods bisher konnten. Entwicklerinnen und Entwickler haben nun die Wahl, Extension Methods für alte oder die neue Syntax zu verwenden. Microsoft nennt die alte Syntax zur Abgrenzung „this-parameter extension methods“. Visual Studio wird Refactoring-Methoden zur Umwandlung zwischen beiden Syntaxformen anbieten.
• Beim Versuch, in einem Extension-Block ein Field zu geben, meckert der Compiler leider mit der unzutreffenden Meldung „Extension declarations can include only methods or properties“.
• Die Syntax für Extensions, die Microsoft für C# 13.0 in Arbeit hatte (public implicit extension Name for Typ), wurde verworfen.
• Microsoft plant in kommenden Preview-Versionen weitere Konstrukte in Extension-Blöcken zu erlauben, z. B. Konstruktoren.
• Listing 3 zeigt den Aufruf der alten und neuen Erweiterungen.

public class CS14_ExtensionDemo
{
  public void Run()
  {
    CUI.Demo(nameof(CS14_ExtensionDemo) + ": String");
  
    string s1old = "Hallo Holger";
    string s1oldtruncated = s1old.TruncateClassic(5);
    Console.WriteLine(s1oldtruncated); // Hello...
    string s2old = null;
    Console.WriteLine(s2old.IsEmptyClassic()); // true
  
    string s1 = "Hallo Holger";
    string s1truncated = s1.Truncate(5);
    Console.WriteLine(s1truncated); // Hello...
  
    // Das geht nicht, weil das Size Property versucht, die Zeichenkette neu zuzuweisen!
    s1.Size = 5;
    Console.WriteLine(s1); // Hallo Holger statt wie erwartet Hallo
  
    string s2 = null;
    Console.WriteLine(s2.IsEmpty); // true
  
    string s3 = string.Create(5, '#');
    Console.WriteLine(s3); // "#####"
  
    CUI.Demo(nameof(CS14_ExtensionDemo) + ": Collection");
  
    var list = new List<int> { 1, 2, 3, 4, 5 };
    var large = list.WhereGreaterThan(3);
    Console.WriteLine(large.IsEmpty);
    if (large.IsEmpty)
    {
      Console.WriteLine("Keine Zahlen größer als 3!");
    }
    else
    {
      Console.WriteLine(large.Count + " Zahlen sind größer als 3!");
    }
  
    // Das klappt: Die Liste wird auf 10 Elemente aufgefüllt
    list.Size = 10;
    foreach (var x in list)
    {
      Console.WriteLine(x);
    }
  }
}

C# 14.0: Null-Conditional Assignment mit ?.

Ein weiteres sehr hilfreiches neues Sprachkonstrukt in C# 14.0 nennt Microsoft das „Null-Conditional Assignment“. Damit können Entwicklerinnen und Entwickler eine Zuweisung an eine Eigenschaft machen ohne vorher zu prüfen, ob das Objekt null ist. Anstelle von

Website aktuelleDOTNETWebsite = Website.Load(123);
if (aktuelleDOTNETWebsite!= null)
{
  // Aktualisieren der URL
    aktuelleDOTNETWebsite.Url = "https://www.dotnet10.de";
}

darf man nun verkürzt mit dem Fragezeichen vor dem Punkt (?.) schreiben:

aktuelleDOTNETWebsite?.Url = "https://www.dotnet10.de";

Dies führt zur Laufzeit zu keinem Fehler. Allerdings passiert auch rein gar nichts, falls die Variable aktuelleDOTNETWebsite den Wert null besitzt.

.NET SDK: Kompilieren und Starten einzelner C#-Dateien (C# Scripting)

Seit .NET 10.0 Preview 4 können Entwicklerinnen und Entwickler einzelne C#-Dateien direkt übersetzen und starten – ohne dass es eine Projektdatei geben muss. Das ist möglich mit dem .NET-SDK-CLI-Befehl dotnet run (Abb. 1).

Abb. 1: Start einer eigenständigen C#-Datei mit dotnet run

Damit kann C# nun auch als Skriptsprache zum Einsatz kommen. Es gab dafür aber schon vorher Ansätze außerhalb von Microsoft:

• CS-Script [2]
• DOTNET-Script [3]
• Cake [4]
• DOTNET Scripting Host (DSH) [5]

Auch der klassische Stil mit class Program und Main()-Methode ist möglich in den eigenständigen C#-Dateien:

class Program
{
  static void Main(string[] args)
  {
    Console.WriteLine("Hallo von " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
  }
}

Für Informationen, die üblicherweise in einer Projektdatei liegen, hat Microsoft eine eigene Syntax beginnend mit der Raute # (Präprozessordirektiven) eingeführt:

• Festlegung des SDK: #:sdk Microsoft.NET.Sdk.Web
• Referenz auf ein NuGet-Paket: #:package [email protected].*
• Build-Eigenschaften, z. B. Versionsnummer: #:property Version 1.1.2

Listing 4 zeigt ein Beispiel mit zwei NuGet-Paketen.

#:package [email protected]
#:package [email protected].*
#:property LangVersion preview
#:property Version 1.1.2

using Spectre.Console;
using Humanizer;

var title = "C# Script " + System.Reflection.Assembly.GetExecutingAssembly().GetName().Version + " mit " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription;
var panel = new Panel(title);
AnsiConsole.Write(panel);

Console.WriteLine();

var d = new Data
{
  Version = "9.0",
  Release = "2024-12-3"
};

var dotNet9Released = DateTimeOffset.Parse(d.Release);
var since = DateTimeOffset.Now - dotNet9Released;
Console.WriteLine($"It has been {since.Humanize()} since .NET {d.Version} was released.");

class Data
{
  public string Version { get; set; }
  public string Release { get; set; }
}

Das nächste Beispiel in Listing 5 und Abbildung 2 zeigt ein ASP.NET Core Minimal WebAPI als eigenständige C#-Datei.

#:sdk Microsoft.NET.Sdk.Web
#:package Microsoft.AspNetCore.OpenApi@10.*-*
#:package [email protected]
#:property Version 1.1.4

using Humanizer;
using Microsoft.OpenApi;

// Webserver einrichten
var builder = WebApplication.CreateBuilder();
builder.Services.AddOpenApi();
var app = builder.Build();
app.MapOpenApi(); // http://localhost:5000/openapi/v1.json

app.MapGet("/", () =>
  {
    // Daten für Operation
    var d = new Data
    {
      Version = "9.0",
        Release = "2024-12-3"
    };
    var dotNet9Released = DateTimeOffset.Parse(d.Release);
    var since = DateTimeOffset.Now - dotNet9Released;

    return $"It has been {since.Humanize()} since .NET {d.Version} was released.";
});
app.Run();

class Data
{
  public string Version { get; set; }
  public string Release { get; set; }
}

Abb. 2: Start und Ausgabe des Webservers

.NET SDK: Umwandeln eigenständiger C#-Dateien in C#-Projekte

Wenn die Anforderungen höher werden, sind C#-Skripte keine Sackgasse. Man kann per Kommandozeilenbefehl aus einem C#-Skript ein C#-Projekt machen (Abb. 3):

dotnet project convert .\WebserverStandalone.cs

Abb. 3: Umwandeln einer eigenständigen C#-Skriptdatei in ein C#-Projekt

Dabei werden ein neuer Ordner und eine Projektdatei angelegt, wobei letztere die Präprozessorinformationen aus der C#-Datei übernimmt (Abb. 4).

Abb. 4: Das eigenständige C#-Projekt

Basisklassenbibliothek: asynchrone ZIP-Operationen

ZIP-Komprimierung gibt es in der .NET-Basisklassenbibliothek seit dem klassischen .NET Framework 4.5 und im modernen .NET seit Version .NET Core 1.0. Seit .NET 10.0 Preview 4 gibt es nun in den Klassen System.IO.Compression.ZipFile, System.IO.Compression.ZipArchive und System.IO.Compression.ZipEntry asynchrone Pendants zu bestehenden synchronen Methoden, z. B. ExtractToDirectoryAsync(), ExtractToFileAsync(), CreateFromDirectoryAsync(), OpenAsync(), OpenReadAsync(), CreateAsync() und CreateEntryFromFileAsync(). Listing 6 zeigt mehrere Beispiele für asynchrone ZIP-Operationen.

using System.IO.Compression;
using System.Text;
using ITVisions;

namespace NET10_Console;

internal class FCL10_Zip
{
  private const string ArchiveFileName = @"t:\CTempArchive.zip";
  private const string SourceDirectoryName = @"c:\temp";
  private const string DestinationDirectoryName = @"t:\CTempArchiveExtract";
  private const string TempFileName = @"t:\tempfile.pdf";
  
  public async Task Run()
  {
    CUI.Demo(nameof(FCL10_Zip));
  
    // Prüfe, ob die Datei existiert
    if (File.Exists(ArchiveFileName)) File.Delete(ArchiveFileName);
  
    // Create a Zip archive
    await ZipFile.CreateFromDirectoryAsync(SourceDirectoryName, ArchiveFileName, CompressionLevel.SmallestSize, includeBaseDirectory: true, entryNameEncoding: Encoding.UTF8);
  
    // Prüfe, ob die Datei existiert
    if (File.Exists(ArchiveFileName)) CUI.Green("ZIP-Datei erstellt: " + ArchiveFileName);
    else CUI.Red("ZIP-Datei nicht erstellt: " + ArchiveFileName);
  
    // Extract a Zip archive
    await ZipFile.ExtractToDirectoryAsync(ArchiveFileName, DestinationDirectoryName, overwriteFiles: true);
  
    // Prüfe, ob das Verzeichnis existiert
    if (Directory.Exists(DestinationDirectoryName)) CUI.Green("Verzeichnis extrahiert: " + DestinationDirectoryName);
    else CUI.Red("Verzeichnis nicht extrahiert: " + DestinationDirectoryName);
  
    #region Lesen und Schreiben von Einträgen in eine ZIP-Datei
  
    using (var archiveStream = new FileStream(ArchiveFileName, FileMode.OpenOrCreate, FileAccess.ReadWrite))
    {
  
      await using (ZipArchive a = await ZipArchive.CreateAsync(archiveStream, ZipArchiveMode.Update, leaveOpen: false, entryNameEncoding: Encoding.UTF8))
      {
  
        // Suche die erste PDF-Datei in a.Entries
        var pdfFileEntry = a.Entries.Where(x => x.Name.EndsWith(".pdf")).FirstOrDefault();
        if (pdfFileEntry != null)
        {
          await pdfFileEntry.ExtractToFileAsync(destinationFileName: TempFileName, overwrite: true);
  
          await using Stream entryStream = await pdfFileEntry.OpenAsync();
 
          ZipArchiveEntry createdEntry = await a.CreateEntryFromFileAsync(sourceFileName: TempFileName, entryName: "Doppelt_" + pdfFileEntry.Name);
          CUI.Green("Erste PDF-Datei wurde verdoppelt: " + pdfFileEntry.Name);
        }
      }
    }
    #endregion
  }
}

Basisklassenbibliothek: mehr Kontrolle beim Zertifikatsexport mit X509Certificate.ExportPkcs12()

Eine Verbesserung für den Zertifikatsexport stand schon in den Release Notes zu .NET 10.0 Preview 2 [6], funktionierte dort aber nicht. Seit .NET 10.0 Preview 3 kann man tatsächlich Zertifikate mit AES-Verschlüsselung und Hashing via SHA-2-256 exportieren – mit der neuen Methode ExportPkcs12() als Ergänzung zur bestehenden Methode Export():

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);

Die bisherige Methode Export() verwendet noch veraltete Algorithmen (3DES-Verschüsselung und SHA-1-Hashing). Die alten Verfahren (3DES/SHA-1) aus Export() sind aber auch über die neue Methode möglich, wenn man es wirklich will:

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);

Listing 7 zeigt ein Beispiel für die Erstellung und den Export eines Zertifikats.

string certPath = "meinZertifikat.pfx";
string password = "meinPasswort"; // Passwort zum Schutz des Zertifikats

// Selbstsigniertes Zertifikat erstellen
using (var rsa = RSA.Create(2048))
{
  var request = new CertificateRequest(
    "CN=TestZertifikat",
    rsa,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pkcs1);
  
  // Zertifikat für 1 Jahr gültig machen
  var cert = request.CreateSelfSigned(
    DateTimeOffset.Now,
    DateTimeOffset.Now.AddYears(1));
  
  // ALT: Zertifikat mit 3DES-Verschüsselung und SHA1-Hashing exportieren
  //byte[] pfxData = cert.Export(X509ContentType.Pkcs12, password);
  
  // NEU: Zertifikat als AES mit SHA-2-256 exportieren
  byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);
  
  // NEUE Methode, aber alte Sicherheitsverfahren: 3DES mit SHA-1
  //byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);
  
  // PFX-Datei speichern
  File.WriteAllBytes(certPath, pfxData);
  
  Console.WriteLine($"Test-Zertifikat erstellt und gespeichert unter: {certPath}");
}

System.Text.Json: JSON-Patch-Unterstützung

System.Text.Json beherrscht nun den JSON-Patch-Standard nach RFC 6902. JSON Patch ist ein standardisiertes Format (definiert in RFC 6902), um Änderungen an JSON-Dokumenten zu beschreiben. Es ermöglicht die Übertragung von Änderungen an einem JSON-Dokument in Form einer Liste von Anweisungen (Operationen). JSON Patch wird häufig in WebAPIs eingesetzt.

Bisher musste man in ASP.NET-Core-basierten WebAPIs für JSON Patch die ältere Community-Bibliothek Newtonsoft.Json einsetzen. Nun geht es auch mit der neueren Microsoft-Bibliothek System.Text.Json [7].

Für JSON Patch mit System.Text.Json gibt es eine Erweiterung für System.Text.Json in Form des neuen NuGet-Pakets Microsoft.AspNetCore.JsonPatch.SystemTextJson, das erstmalig mit .NET 10.0 Preview 4 erschienen ist [8].

Trotz des “AspNetCore” im Namen funktioniert dieses Zusatzpaket auch außerhalb von ASP.NET Core, wie Listing 8 beweist! Allerdings funktioniert das neue Paket nicht mit dem NativeAOT-Compiler.

public class Person
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string Email { get; set; }
  public List<PhoneNumber> PhoneNumbers { get; set; } = new();
  public Address Address { get; set; }
}

public class Address
{
  public string Street { get; set; }
  public string City { get; set; }
  public string State { get; set; }
  public string ZipCode { get; set; }
}

public enum PhoneNumberType
{
  Mobile,
  Home,
  Work,
  Other
}

public class PhoneNumber
{
  public string? Number { get; set; }
  public PhoneNumberType Type { get; set; }
}

public void JSONPatchDemo()
{
  // Originalobjekt
  var person = new Person
  {
    FirstName = "Holger",
    LastName = "Schwichtenberg",
    Email = "[email protected]",
    PhoneNumbers = [new PhoneNumber() { Number = "0201 649590-0", Type = PhoneNumberType.Work }],
    Address = new Address
    {
      Street = "Fahrenberg 40b",
      City = "Essen",
      State = "NRW"
    }
  };
  
  CUI.H2("Ausgabe des Objekts in seinem alten Zustand");
  CUI.Print(ITVisions.ObjectDumper.Dump(person));
  
  // JSON Patch-Document
  string jsonPatch = """
  [
    { "op": "replace", "path": "/FirstName", "value": "Dr. Holger" },
    { "op": "remove", "path": "/Email"},
    { "op": "add", "path": "/Address/ZipCode", "value": "45257" },
    { "op": "add", "path": "/PhoneNumbers/-", "value": { "Number": "0201 649590-40" } }
  ]
  """;
  
  // JSON Patch-Document laden
  JsonPatchDocument<Person>? patchDoc = JsonSerializer.Deserialize<JsonPatchDocument<Person>>(jsonPatch);
 
  // JSON Patch-Document anwenden auf das Person-Objekt
  patchDoc!.ApplyTo(person);
 
  CUI.H2("Ausgabe des Objekts in seinem neuen Zustand");
  CUI.Print(ITVisions.ObjectDumper.Dump(person));
}

Microsoft verspricht in der neuen Implementierung „eine verbesserte Leistung und weniger Speichernutzung im Vergleich zu der existierenden Implementierung in Newtonsoft.Json“ [9] in Verbindung mit einem ähnlichen Design wie bei Newtonsoft.Json, einschließlich der Aktualisierung eingebetteter Objekte und Arrays. Bisher nicht verfügbar ist JSON Patch für dynamische Objekte, weil Newtonsoft.Json dafür Reflection einsetzt, System.Text.Json soll aber auch mit dem NativeAOT-Compiler funktionieren.

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Im NuGet-Paket Microsoft.AspNetCore.JsonPatch.SystemTextJson gibt es eine Klasse Microsoft.AspNetCore.JsonPatch.SystemTextJson.JsonPatchDocument<T> mit einer Methode ApplyTo (obj), die eine JSON-Patch-Operation auf das übergebene Objekt anwendet (Listing 8). Das resultierende JSON-Dokument für die Person nach Anwendung des JSON-Patch-Dokuments sieht dann aus wie in Abbildung 5.

Abb. 5: Ausgabe des Listings 8

Alternativ kann man das Objekt natürlich auch als JSON ausgeben (Abb. 6). Das ist nur in dem obigen Listing nicht passiert, weil nicht der Eindruck entstehen soll, man müsse das Objekt als JSON weiterverwenden.

Abb. 6: Ausgabe des geänderten Objekts im JSON-Format

Mit JSON Patch kann man auch Werte in einem Objekt testen (Listing 9).

CUI.H2("Testen mit JSON Patch-Dokument");
string jsonPatchTest = """
[
  { "op": "test", "path": "/FirstName", "value": "Dr. Holger" },
  { "op": "test", "path": "/Email", "value": null},
  { "op": "test", "path": "/Address/ZipCode", "value": "45257" }
]
""";

// JSON Patch-Document laden
JsonPatchDocument<Person>? patchTestDoc = JsonSerializer.Deserialize<JsonPatchDocument<Person>>(jsonPatchTest);

// JSON Patch-Document anwenden auf das Person-Objekt
patchTestDoc!.ApplyTo(person, patchError => CUI.PrintError(patchError.ErrorMessage));

In diesem Fall gibt es keine Fehlerausgabe. Wenn man das Dokument aber verändert (Listing 10), bekommt man drei Fehlertexte (Abb. 7).

CUI.H2("Testen mit JSON Patch-Dokument");
string jsonPatchTest = """
[
  { "op": "test", "path": "/FirstName", "value": "Dr.Holger" },
  { "op": "test", "path": "/Email", "value": ""},
  { "op": "test", "path": "/Address/ZipCode", "value": "45251" }
]
""";

Abb. 7: Fehlertexte

Dabei ist die Fehlermeldung bei Email nicht gut, denn sie unterscheidet nicht zwischen Leerstring und Null. Im Objekt steht null, getestet wird auf Leerstring. In der Fehlermeldung steht in beiden Fällen ‘ ‘.

Entity Framework Core: verbesserte Suche mit CosmosDB

Entity Framework Core 10.0 unterstützt seit Preview 4 in Verbindung mit Azure CosmosDB zwei neue Suchmodi, die es dort seit März 2025 als Vorschauversion gibt: Volltextsuche [10] und hybride Suche, die die Vektorsuche und Volltextsuche mit einer Reciprocal Rank Fusion (RRF) Function kombiniert [11]. Microsoft hat zudem angekündigt [12], dass die in Entity-Framework-Core-Version 9.0 eingeführte Vektorsuche mit CosmosDB nun stabil ist.

ASP.NET Core: OpenAPI Specification (OAS) in der WebAPI-AOT-Projektvorlage

Bisher war die Metadatengenerierung mit OpenAPI Specification (OAS) nur in der Projektvorlage ASP.NET Core Web API (Kurzname: webapi) aktiv, die keine Kompilierung mit dem NativeAOT-Compiler erlaubt. In der Projektvorlage ASP.NET Core Web API (nativeAOT) (Kurzname: webapiaot) mit aktivierter NativeAOT-Kompilierung war OAS zwar integrierbar, aber das mussten Entwicklerinnen und Entwickler manuell vornehmen.

Seit .NET 10.0 Preview 4 ist in der Projektvorlage ASP.NET Core Web API (nativeAOT) nun die Metadatengenerierung mit OAS im Standard aktiviert (Abb. 8). Mit dem Befehl

dotnet new webapiaot --name ITVisionsWebAPI

entsteht ein Projekt, das das NuGet-Paket Microsoft.AspNetCore.OpenApi referenziert und die OpenAPI-Unterstützung in der Program.cs mit

builder.Services.AddOpenApi();

und

app.MapOpenApi();

aktiviert.

In der Projektvorlage webapiaot können Entwicklerinnen und Entwickler die OpenAPI-Features wahlweise auch mit dem Parameter –no-openapi deaktivieren:

dotnet new webapiaot --name ITVisionsWebAPI --no-openapi

Abb. 8: Die neue Option für WebAPI-AOT-Projekte in Visual Studio

Mit aktiviertem OpenAPI-Support wird dann dieses NuGet-Paket eingebunden:

<PackageReference Include="Microsoft.AspNetCore.OpenApi" … />

In Program.cs steht dann:

builder.Services.AddOpenApi();
...
if (app.Environment.IsDevelopment())
{
  app.MapOpenApi();
}

Der Standard-URL des OpenAPI-Dokuments ist dann: https://localhost:PORT/openapi/v1.json.

ASP.NET Core: OpenAPI-Transformer für Minimal WebAPIs

Seit .NET 10.0 Preview 3 gibt es eine neue Methode AddOpenApiOperationTransformer(), mit der Entwicklerinnen und Entwickler das generierte OpenAPI-Dokument verändern können. Beispiel: Eine Operation /checkwebsite liefert normalerweise HTTP-Statuscode 200 mit der Beschreibung „OK“ zurück (Abb. 9).

Abb. 9: Ausschnitt aus dem OpenAPI-Dokument vor Veränderung des Antwortbeschreibungstexts und der Parameterliste

Dieser Text kann verändert werden mit Aufruf von AddOpenApiOperationTransformer(). Ebenso kann ein Parameter ergänzt werden, z. B. ein zusätzlicher Wert, der im Header des HTTP-Requests übergeben werden muss (Listing 11), (Abb. 10).

app.MapGet("/checkwebsite", Operations.CheckWebsite)
  .WithName("checkwebsite")
  .AddOpenApiOperationTransformer((operation, ContextBoundObject, ct) =>
  {
    // Ergänzen eines Parameters, der im Header übergeben werden muss
    operation.Parameters.Add(new OpenApiParameter
    {
      Name = "Customer-GUID",
      In = ParameterLocation.Header,
      Description = "Your Customer GUID for Authentication",
      Required = true,
      Schema = new OpenApiSchema
      {
        Type = JsonSchemaType.String,
        Format = "uuid"
      }
    });
  
    // Änderung des Beschreibungstextes für Statuscode 200
    operation.Responses?["200"].Description = "Die Prüfung war erfolgreich";
  
    return Task.CompletedTask;
});

Abb. 10: Ausschnitt aus dem OpenAPI-Dokument nach Veränderung des Antwortbeschreibungstextes

ASP.NET Core: Validierung für ASP.NET Core Minimal WebAPIs

ASP.NET Core Minimal WebAPIs beherrschen seit .NET 10.0 Preview 3 auch die Parametervalidierung mit Data Annotations. Das konnten bisher nur die Controller-basierten WebAPIs [13].

Für Minimal WebAPIs müssen Entwicklerinnen und Entwickler das Validierungsfeature allerdings erst in der Projektdatei aktivieren mit

<PropertyGroup>
    <!-- Enable the generation of interceptors for the validation attributes -->
    <InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.Http.Validation.Generated</InterceptorsNamespaces>
  </PropertyGroup>

und in der Startdatei mit

builder.Services.AddValidation();

Dann kann man auch in Minimal WebAPIs mit den bekannten Validierungsannotationen wie [MinLength], [MaxLength], [Range], [Url], [EmailAddress], [Phone], [CreditCard], [RegularExpression] u. v. m. [14] arbeiten, z. B.

app.MapGet("/checkwebsite", ([MinLength(5)] string name, [Url] string url)
  => WebsiteChecker.CheckWebsite(name, url));

Hier führt nun der HTTP-Aufruf https://Server:Port/checkwebsite?name=ITVisions&url=www.IT-Visions.de zur Laufzeit zur Rückgabe eines JSON-Dokuments zu zwei Validierungsfehlern (Abb. 11). Seit Preview 4 funktioniert das auch, wenn die Parameter ein Record-Typ sind.

Abb. 11: Beide Parameter beim Aufruf dieses ASP.NET Core Minimal WebAPI entsprachen hier nicht den Validierungsregeln

Blazor: deklarativer Persistent Component State

Microsoft Webframework ASP.NET Core erlaubt bei Blazor Server und Blazor WebAssembly bisher schon die Übergabe von Daten zwischen dem Prerendering und dem Hauptrendering via JSON-Anhang in HTML-Dokumenten. Dieser Persistent Component State war bisher aber recht aufwendig für die Entwicklerinnen und Entwickler in der Realisierung, denn man musste zunächst ein Objekt per Dependency Injection bekommen

@inject PersistentComponentState ApplicationState

und dann den Zustand als Objekt dort ablegen

private PersistingComponentStateSubscription? persistingSubscription;

persistingSubscription = ApplicationState.RegisterOnPersisting(() =>
  {
    ApplicationState.PersistAsJson("name", daten);
    return Task.CompletedTask;
});

und jeweils vor der Nutzung wieder explizit herausholen:

if (ApplicationState.TryTakeFromJson<Typ>("name", out var daten))
  {
    Daten = daten;
}

Das hat Microsoft in .NET 10.0 Preview 3 mit dem deklarativen Persistent Component State radikal vereinfacht. Entwicklerinnen und Entwickler müssen jetzt nur noch ein Property mit der Annotation [SupplyParameterFromPersistentComponentState] versehen und sich sonst um nichts kümmern:

[SupplyParameterFromPersistentComponentState]
public Daten? daten { get; set; }

Im Beispiel in Listing 12 sehen Sie auskommentiert die alte Variante im Vergleich zur neuen Variante.

@page "/State"
@using BO.WWWings
@* @inject PersistentComponentState ApplicationState *@

<PageTitle>Counter</PageTitle>

<h1>Flight-Counter <span class="badge bg-warning">@this.RendererInfo.Name</span></h1>

<p role="status" title="@pageState.LastChange">Current count: @pageState.CurrentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">+</button>
<button class="btn btn-primary" @onclick="DecrementCount">-</button>

@if (this.pageState?.FlightSet != null)
{
  <hr noshade>
  <ol>
    @foreach (Flight f in this.pageState.FlightSet.Take(this.pageState.CurrentCount))
    {
      <li>Flug #@f.FlightNo (@f.FlightDate.ToShortDateString()) @f.Departure -> @f.Destination </li>
    }
  </ol>
}

@code {
  [SupplyParameterFromPersistentComponentState]
  public PageState pageState { get; set; } = null;
  
  private void IncrementCount()
  {
    pageState.CurrentCount++;
  }
  
  private void DecrementCount()
  {
    if (pageState.CurrentCount > 0) pageState.CurrentCount--;
  }
  
  // -----------------------------
  
  // private PersistingComponentStateSubscription? persistingSubscription;
  
  protected override void OnInitialized()
  {
  
    // persistingSubscription = ApplicationState.RegisterOnPersisting(() =>
    //     {
    //      ApplicationState.PersistAsJson(nameof(PageState), pageState);
    //      return Task.CompletedTask;
    //     });
  
    if (pageState == null)
    {
      DA.WWWings.WwwingsV1EnContext ctx = new();
      pageState = new() { 
        FlightSet = ctx.Flights.Take(100).ToList(), 
  
        CurrentCount = 10, Created = DateTime.Now };
    }

    // if (ApplicationState.TryTakeFromJson<PageState>(nameof(PageState), out PageState daten))
    // {
    //  pageState = daten;
    // }
  }
  
  public class PageState
  {
    public DateTime Created { get; set; }
    public DateTime LastChange { get; set; }
    public int _CurrentCount;
    public int CurrentCount
    {
      get
      {
        return _CurrentCount;
      }
      set
      {
        _CurrentCount = value;
        LastChange = DateTime.Now;
      }
    }
    public List<Flight> FlightSet { get; set; }
  }
}

Blazor: Erweiterungen der Klasse NavigationManager

Die in Blazor eingebauten Implementierungen der abstrakten Basisklasse Microsoft.AspNetCore.Components.NavigationManager haben in Blazor 10.0 Preview 4 zwei neue Mitglieder erhalten: NotFound() und OnNotFound().

Die neue Methode NotFound() signalisiert Blazor, dass eine angeforderte Ressource nicht vorhanden ist. Beim statischen Server-side Rendering bekommt der Webbrowser dann eine HTTP-Antwort mit Statuscode 404. Beim interaktiven Rendering (Blazor Server, Blazor WebAssembly, Blazor Hybrid) wird gerendert, was im Router bei <NotFound> definiert ist.

OnNotFound() ist ein Ereignis, das von Blazor ausgelöst wird, wenn die Methode NotFound() aufgerufen wird.

NavigationManager.NavigateTo() funktioniert nun auch beim statischen Server-side Rendering. Bisher lieferte dies immer den Laufzeitfehler NavigationException. Für Anwendungen, die diesen Fehler erwarten, hat Microsoft einen Schalter eingebaut, der das bisherige Verhalten zurückholt:

AppContext.SetSwitch("Microsoft.AspNetCore.Components.Endpoints.NavigationManager.EnableThrowNavigationException", isEnabled: true);

Blazor: Fingerprinting für Blazor WebAssembly Standalone

Das bereits in Blazor 9.0 eingeführte Fingerprinting (Anhängen eines Hashwerts auf Basis des Dateiinhalts an den Dateinamen, was vermeidet, dass Webbrowser alte Versionen aus dem Browsercache verwenden) funktioniert nun auch für die in Blazor eingebaute JavaScript-Datei in den sogenannten „Standalone Blazor WebAssembly“-Projekten, die nicht in ASP.NET Core betrieben werden, sondern auf einem statischen Webserver gehostet sein können.

Man verwendet dazu man in den Projekteinstellung

<OverrideHtmlAssetPlaceholders>true</OverrideHtmlAssetPlaceholders>

und im HTML-Kopfbereich in der index.html:

<link rel="preload" id="webassembly" />
<script type="importmap"></script>

Das <script>-Tag ist dann

<script src="proxy.php?url=_framework/blazor.webassembly#[.{fingerprint}].js"></script>

Diese Verbesserung ist seit .NET 10.0 Preview 4 auch in der Projektvorlage blazorwasm umgesetzt:

dotnet new blazorwasm -n ITVisionsDemo

Die index.html-Datei sieht dort so aus wie in Listing 13 gezeigt.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>NET10_BlazorWasmStandalone</title>
  <base href="/" />
  <link rel="preload" id="webassembly" />
  <link rel="stylesheet" href="lib/bootstrap/dist/css/bootstrap.min.css" />
  <link rel="stylesheet" href="css/app.css" />
  <link rel="icon" type="image/png" href="favicon.png" />
  <link href="NET10_BlazorWasmStandalone.styles.css" rel="stylesheet" />
  <link href="manifest.webmanifest" rel="manifest" />
  <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" />
  <link rel="apple-touch-icon" sizes="192x192" href="icon-192.png" />
  < script type="importmap"></script>
</head>
 
<body>
  <div id="app">
    <svg class="loading-progress">
      <circle r="40%" cx="50%" cy="50%" />
      <circle r="40%" cx="50%" cy="50%" />
    </svg>
    <div class="loading-progress-text"></div>
  </div>
 
  <div id="blazor-error-ui">
    An unhandled error has occurred.
    <a href="." class="reload">Reload</a>
    <span class="dismiss">🗙</span>
  </div>
  < script src="_framework/blazor.webassembly#[.{fingerprint}].js"></script>
  < script>navigator.serviceWorker.register('service-worker.js');</script>
</body>
 
</html>

Der Build-Prozess sorgt dafür, dass einige Ersetzungen stattfinden (siehe grüne Rahmen in den Abbildungen 12 und 13).

Abb. 12: Ersetzungen in der index.html durch den Build-Prozess (Teil 1)

Abb. 13: Ersetzungen in der index.html durch den Build-Prozess (Teil 2)

Wichtig: In bestehenden Projekten müssen Entwicklerinnen und Entwickler die Änderungen manuell vornehmen, um die Optimierungen zu nutzen.

Blazor: Umgebungen für Blazor WebAssembly

In Blazor-WebAssembly-Anwendungen mussten Entwicklerinnen und Entwickler die Umgebungsdefinition (Development, Staging, Production) bisher per HTTP-Header vornehmen [15]. Nun nimmt Microsoft beim Kompilieren von Blazor-WebAssembly-Anwendungen automatisch folgende Umgebungen an:

• bei dotnet build: Development
• bei dotnet publish: Production

Entwicklerinnen und Entwickler können die Umgebungsart auch per Projekteinstellung in der Projektdatei (.csproj) explizit setzen, z. B. für die Umgebung Staging:

<WasmApplicationEnvironmentName>Staging</WasmApplicationEnvironmentName>

Blazor: Response Streaming im HttpClient in Blazor WebAssembly

In Blazor-WebAssembly-basierten Anwendungen ist in der Klasse System.Net.Http.HttpClient im Standard nun das Response Streaming aktiv, um die Leistung zu erhöhen und den Speicherbedarf zu verringen (Listing 14, Abb. 14). Zuvor mussten Entwicklerinnen und Entwickler das Response Streaming manuell aktivieren mit

request.SetBrowserResponseStreamingEnabled(true);

@page "/HttpStreaming"
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using System.Net.Http
@using System.Diagnostics

@inject HttpClient HttpClient

<h1>HTTP Response Streaming</h1>

<button type="button" class="btn btn-primary" @onclick="Get">Laden</button>
<button type="button" class="btn btn-warning" @onclick="Stop">Abbrechen</button>
<input type="checkbox" @bind="streamingEnabled" /> Response Streaming aktivieren
<hr />
<p>Status: @status</p>
<p>Response Streaming aktiv: @streamingEnabled</p>
<p>Stream-Type: @streamType</p>
<p>Bytes gelesen: @byteCount</p>
<p>Dauer: @sw.ElapsedMilliseconds ms</p>

@code {
  int byteCount;
  string status = "";
  string streamType = "Unknown";
  bool streamingEnabled = false; // Set to true to enable streaming
  Stopwatch sw = new Stopwatch();
  CancellationTokenSource cts;
  
  // Laden
  async Task Get()
  {
    status = "Lade..."; 
    sw.Reset();
    sw.Start();
    cts = new CancellationTokenSource();
  
    using var request = new HttpRequestMessage(HttpMethod.Get, "https://www.it-visions.de/produkte/pdf/www.IT-Visions.de_Firmenbrosch%C3%BCre.pdf");
    if (streamingEnabled) request.SetBrowserResponseStreamingEnabled(true);
    else request.SetBrowserResponseStreamingEnabled(false);
 
    // Beim Streaming; HttpCompletionOption.ResponseHeadersRead / Der Standardwert ist ResponseContentRead, was bedeutet, dass der Vorgang erst abgeschlossen werden soll, nachdem die gesamte Antwort, einschließlich des Inhalts, aus dem Socket gelesen wurde.
    using var response = await HttpClient.SendAsync(request, streamingEnabled ? HttpCompletionOption.ResponseHeadersRead : HttpCompletionOption.ResponseContentRead);
  
    using Stream stream = await response.Content.ReadAsStreamAsync();
    streamType = stream.GetType().FullName; // Get the type of the stream: System.IO.MemoryStream oder System.Net.Http.HttpConnection+ContentLengthReadStream
 
    // Blockweises Lesen des Streams
    var bytes = new byte[10000];
    while (!cts.Token.IsCancellationRequested)
    {
      var read = await stream.ReadAsync(bytes, cts.Token);
      if (read == 0) // Ende des Streams erreicht
      {
        sw.Stop(); 
        status = "Fertig!";
        return;
      }
  
      byteCount += read;
 
      // UI-Update
      StateHasChanged();
      await Task.Delay(1);
    }
  }
  
  // Abbrechen
  void Stop()
  {
    sw.Stop();
    cts?.Cancel();
  }
}

Abb. 14: Screenshot des Beispiels aus Listing 14 unter .NET 9.0

In .NET 10.0 ist das Response Streaming nun automatisch aktiv und der Stream-Typ ist ein anderer (Abb. 15).

Abb. 15: Screenshot des Beispiels aus Listing 14 unter .NET 10.0

Durch das im Standard aktive Response Streaming sind allerdings nur noch asynchrone Operationen und keine synchronen Operationen mehr möglich. Ein Aufruf der synchronen Send()-Methode HttpClient.Send(request) führt dann zum Laufzeitfehler „Operation is not supported on this platform.“ Diese Verhaltensänderung gehört zu den Breaking Changes in .NET 10.0 [16].

Das Response Streaming im HttpClient ist in .NET 10.0 deaktivierbar mit:

request.SetBrowserResponseStreamingEnabled(false);

Alternativ ist die Deaktivierung global in der Projektdatei möglich:

<WasmEnableStreamingResponse>false</WasmEnableStreamingResponse>

Blazor: neue Interoperabilitätsmethoden zwischen C# und JavaScript

In Blazor erweitert Microsoft die Schnittstellen für die Interoperabilität zwischen C# und JavaScript (IJSRuntime, IJSInProcessRuntime, IJSObjectReference und IJSInProcessObjectReference) um neue Mitglieder, um eine Instanz von einem JavaScript-Objekt zu erzeugen und dabei Konstruktorparameter zu übergeben (InvokeNew() und InvokeNewAsync()) sowie um Variablen oder Objekteigenschaften zu lesen (GetValue() und GetValueAsync()) bzw. zu setzen (SetValue()und SetValueAsync()).

Bisher konnte man von C# aus lediglich Funktionen in JavaScript mit Invoke(), InvokeVoid(), InvokeAsync() und InvokeVoidAsync() aufrufen. Die neuen Interoperabilitätsmethoden vermeiden in einigen Fällen, dass man eine JavaScript-Wrapper-Funktion schreiben muss; stattdessen kann man nun direkt Objekte erzeugen und Werte lesen/schreiben. Ein Beispiel sieht man in den Listings 15 und 16 sowie Abbildung 16.

window.JSUtil = class {
  constructor(text) {
    // zwei Eigenschaften der JavaScript-Klasse
    this.text = text;
    this.caseSensitive = false;
  }
  
  // Hole Textlänge
  getTextLength() {
    return this.text.length;
  }
  
  // Prüfe, ob Text in der aktuellen URL vorkommt
  containsTextInUrl() {
    const url = window.location.href;
    if (this.caseSensitive) return url.includes(this.text);
    else return url.toLowerCase().includes(this.text.toLowerCase());
  }

}

@inject IJSRuntime JSRuntime
@page "/interop"
@using ITVisions.Blazor
@inject BlazorUtil util

< script src="JSUtil.js"></script>
<h3>Blazor 10.0 C#/JavaScript-Interop</h3>
<hr noshade />
 
<button @onclick="Aktion">JavaScript aufrufen</button>
<br />

<ul>
@((MarkupString)Ausgabe)
</ul>


@code {
  
  protected override Task OnInitializedAsync()
  {
    return base.OnInitializedAsync();
  }
  
  public string Ausgabe { get; set; } = "";
  
  async Task Aktion()
  {
    // Eine einfache Variable setzen im Browser
    await JSRuntime.SetValueAsync<Guid>("Token", Guid.NewGuid());
    var token = await JSRuntime.GetValueAsync<string>("Token");
    Ausgabe = "<li>Aktuelles Token: " + token + "</li>";
  
    // Eine Eigenschaft des vorhandenen document-Objekts ändern
    var titleOld = await JSRuntime.GetValueAsync<string>("document.title");  
    var titleNew = "Interop-Demo: " + DateTime.Now.ToLongTimeString();
    await JSRuntime.SetValueAsync<string>("document.title", titleNew);
    Ausgabe += "<li>Title geändert von '" + titleOld + "' auf '" + titleNew + "'" + "</li>";
  
    // Ein neues JavaScript-Objekt erstellen und damit arbeiten
    var jsObj = await JSRuntime.InvokeNewAsync("JSUtil", "Localhost");
    var text = await jsObj.GetValueAsync<string>("text");
    var textLength = await jsObj.InvokeAsync<int>("getTextLength");
    await jsObj.SetValueAsync<bool>("caseSensitive", true);
    var caseSensitive = await jsObj.GetValueAsync<bool>("caseSensitive");
    var containsTextInUrl = await jsObj.InvokeAsync<bool>("containsTextInUrl");
    Ausgabe += $"<li>Die Zeichenkette {text} hat {textLength} Zeichen und kommt{(containsTextInUrl ? "" : " NICHT")} in der aktuellen URL vor. Der Vergleich war '{(caseSensitive ? "casesensitive" : "caseinsensitive")}'.</li>";
  }

}

Abb. 16: Ausgabe des Beispiels der Listing 15 und 16

Blazor: automatisches Schließen des Filterkriteriendialogs im QuickGrid via HideColumnOptionsAsync()

Die in ASP.NET Core 10.0 Preview 2 eingeführte Methode CloseColumnOptionsAsync() heißt seit Preview 4 nun HideColumnOptionsAsync(). Damit kann man den Eingabedialog für Filterkriterien im Steuerelement <QuickGrid> schließen, wenn der Filter angewendet wurde (Listing 17).

<QuickGrid @ref="flightGrid" RowClass="ApplyRowClass" ItemsProvider="@itemsProvider" TGridItem="BO.WWWings.Flight" Virtualize="true" OverscanCount="@overscanCount">
  <PropertyColumn Property="@(p => p.FlightNo)" Title="FlugNr" Sortable="true" />
  <PropertyColumn Property="@(p => p.Departure)" Title="Abflugort" Sortable="true">
  
    <ColumnOptions>
      <input type="search" @bind="departureFilter" placeholder="Filter by Departure"
        @bind:after="@(() => flightGrid.HideColumnOptionsAsync())" />
    </ColumnOptions>
 
  </PropertyColumn>
  <PropertyColumn Property="@(p => p.Destination)" Title="Zielort" Sortable="true" />
  <PropertyColumn Property="@(p => p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
</QuickGrid>

Blazor: Diagnosedaten für Blazor WebAssembly

Eine größere neue Diagnosefunktion in .NET 10.0 bekam in Preview 4 die WebAssembly-basierte Variante von Blazor, die als Single Page App im Webbrowser läuft: Entwicklerinnen und Entwickler können im Webbrowser zur Laufzeit Diagnosedaten über Performance, Speicherinhalt und diverse Metriken sammeln.

Dazu muss man als Voraussetzung die .NET WebAssembly Build Tools in der aktuellen .NET-10.0-Version als .NET-SDK-Workload installieren (Abb. 17):

dotnet workload install wasm-tools

Abb. 17: Bei dotnet workload list sollte die jeweils aktuelle Version erscheinen (hier im Bild: Preview 4 von .NET 10.0)

In den .NET WebAssembly Build Tools gibt es zwei neue Funktionen:

• Performanceanalyse in den Browser-Entwicklerwerkzeugen („F12-Tools“)
• Sammeln und Herunterladen von Tracedateien und Memory Dumps aus dem Browser

Für die Nutzung der Performanceanalyse in den Browser-Entwicklerwerkzeugen gibt es in der Projektdatei die in Tabelle 1 aufgelisteten Einstellungen (Listing 18).

Tabelle 1: Projekteinstellungen für Blazor-WebAssembly-Diagnosedaten (Quelle: [17])

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
...
  <!-- NEU: Blazor WebAssembly Runtime Diagnostics  -->
  <PropertyGroup>
  
    <!-- Für Anzeige von "Timings" im Performance-Tab der Browser-Developer-Tools-->
    <WasmProfilers>browser</WasmProfilers>
    <WasmNativeStrip>false</WasmNativeStrip>
    <WasmNativeDebugSymbols>true</WasmNativeDebugSymbols>
  </PropertyGroup>
</Project>

Mit diesen Einstellungen erhält man in den Browser-Entwicklerwerkzeugen in der Registerkarte Performance eine Ansicht Timings mit der Ablauffolge der aufgerufenen .NET-Methoden (Abb. 18).

Abb. 18: Aufrufhierarchie der Methoden im Browser mit Zeitverbrauch in den Browser-Entwicklerwerkzeugen unter „Performance | Timings“

Mit den folgenden Einstellungen in der Projektdatei erlaubt man das Sammeln von Tracedaten und Memory Dumps einer Blazor-WebAssembly-Anwendung im Webbrowser. Die Daten werden als .nettrace-Datei im Browser heruntergeladen (Tabelle 2, Listing 19).

Tabelle 2: Projekteinstellungen für Blazor-WebAssembly-Diagnosedaten (Quelle: [17])

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
  ...
  <!-- NEU: Blazor WebAssembly Runtime Diagnostics  -->
  <PropertyGroup>
  
    <!-- Für Trace- und Memory-Dump-Files -->
    <WasmPerfTracing>true</WasmPerfTracing>
    <WasmPerfInstrumentation>all</WasmPerfInstrumentation>
    <EventSourceSupport>true</EventSourceSupport>
    <MetricsSupport>true</MetricsSupport>

  </PropertyGroup>
</Project>

Danach kann man per JavaScript APIs auf die Diagnosedaten zugreifen. Diese Befehle gibt man in der Browserkonsole in den Browser-Entwicklerwerkzeugen ein:

• CPU-Nutzung sammeln für die nächsten 5 Sekunden:

globalThis.getDotnetRuntime(0).collectCpuSamples({durationSeconds: 5});

• Metriken sammeln für die nächsten 5 Sekunden:

globalThis.getDotnetRuntime(0).collectPerfCounters({durationSeconds: 5});

• Speicherabbildung erstellen:

globalThis.getDotnetRuntime(0).collectGcDump();

Entwicklerinnen und Entwickler erhalten die gesammelten Daten in einer .nettrace-Datei im Downloads-Ordner des Webbrowsers (Abb. 19).

Abb. 19: Herunterladen der Memory-Dump-Datei in Format .nettrace

Die .nettrace-Dateien mit CPU- und Performance-Counter-Dateien kann man ohne weitere Schritte in Visual Studio öffnen, indem man die Datei per File | Open öffnet oder einfach per Drag and Drop in den Dateibereich von Visual Studio zieht (Abb. 20 und 21).

Abb. 20: Ansicht der CPU-Nutzung der Blazor-WebAssembly-Anwendung in Visual Studio

Abb. 21: Nach Klick auf System.String.Join() sieht man die Anzahl der Aufrufe und die CPU-Nutzungszeit

Während man .netrace-Dateien mit CPU- und Performance-Counter-Dateien direkt in Visual Studio öffnen kann, muss man eine Speicherabbilddatei zunächst mit dem .NET-CLI-Werkzeug dotnet-gcdump [18] in eine .gcdump-Datei für Visual Studio konvertieren (Abb. 22).

Die Installation der aktuellen Version dieses Werkzeugs erfolgt mit

dotnet tool install --global dotnet-gcdump

Die Konvertierung einer .nettrace-Datei in eine .gcdump-Datei geht dann so:

dotnet-gcdump convert Dateiname.nettrace

Abb. 22: Konvertieren einer Speicherabbilddatei von .nettrace zu .gcdump

Die erzeugte .gcdump-Datei kann man dann in Visual Studio betrachten (Abb. 23). Man sieht, welche Typen wie oft instanziiert wurden und wie viele Bytes sie verbrauchen. Die Spalte Size (Bytes) sind dabei die Bytes, die der Typ selbst verbraucht. inclusive Size (Bytes) umfasst auch die von Unterobjekten verbrauchten Speicherplätze.

Abb. 23: Betrachten der Memory-Dump-Datei (.gcdump) in Visual Studio

Weitere Neuerungen

Über die in diesem Beitrag besprochenen Neuerungen hinaus bietet .NET 10.0 einige kleinere Verbesserung für Validation Context, Telemetry und ML.NET, die man in den Release Notes zu .NET 10.0 Preview 3 findet [19].

Bei Windows Forms und WPF verwendet Microsoft seit .NET 10.0 Preview 4 den gleichen Programmcode für die Arbeit mit der Zwischenablage [20]. Das erleichtert Microsoft die Wartung des Programmcodes; Entwicklerinnen und Entwickler haben davon aber erstmal nichts.

Ausblick

Bis zum geplanten Erscheinen von .NET 10.0 im November 2025 werden noch drei weitere Preview-Versionen (Preview 5, 6 und 7) und zwei Release-Candidate-Versionen erscheinen. Mit der fertigen Version kann am 11. November 2025 gerechnet werden, denn Microsoft hat bereits eine virtuelle .NET Conf für den 11. bis 13. November 2025 angekündigt.

Als gerade Versionsnummer wird .NET 10.0 wieder Long Term Support (LTS) für 36 Monate erhalten, also bis November 2028, während der Support für .NET 9.0 schon im Mai 2027 enden wird. Weiterhin ist aktuell .NET 8.0 im Support, das Microsoft noch bis November 2026 unterstützen wird.

Frequently Asked Questions (FAQ)

1. Wann wurden .NET 10 Preview 3 und Preview 4 veröffentlicht und wie installieren?

Preview 3 erschien am 10. April 2025, und Preview 4 folgte am 13. Mai 2025. Zur Nutzung benötigt man das .NET 10 SDK (inklusive der drei Laufzeitumgebungen) sowie Visual Studio 2022 Version 17.14, die gemeinsam installiert werden können.

2. Welche C#-Neuerungen bringt Preview 3?

Mit C# 14.0 führt Preview 3 sogenannte Extension Members ein – eine Erweiterung bestehender Klassen um Methoden und Eigenschaften (instanz- sowie statisch), über das neue extension-Schlüsselwort, abseits der bisherigen this-basierenden Methoden. Zudem erlaubt das Null-Conditional Assignment (?.) das sichere Zuweisen von Eigenschaften ohne vorherige Null-Prüfung.

3. Welche Features enthält das SDK ab Preview 4?

Ab Preview 4 können einzelne C#-Dateien direkt mit dotnet run ausgeführt werden – ohne Projektdatei. Die Skript-Dateien nutzen Präprozessor-Direktiven (#:sdk, #:package, #:property), um z. B. SDK, NuGet-Pakete oder Build-Parameter zu definieren.

4. Was gibt es Neues in der Basis-Klassenbibliothek (BCL)?

Die BCL erweitert seit Preview 4 die System.IO.Compression-APIs um asynchrone ZIP-Operationen, etwa CreateFromDirectoryAsync(), ExtractToDirectoryAsync(), OpenAsync() oder CreateAsync().

5. Welche Verbesserungen gibt es beim Zertifikatsexport?

Seit Preview 3 ermöglicht die neue Methode ExportPkcs12() den Export von Zertifikaten mit AES‑Verschlüsselung und SHA‑2‑256 Hashing – sicherer als der alte Export()-Ansatz mit 3DES/SHA‑1.

6. Was ändert sich bei JSON-Patch?

Preview 4 führt native Unterstützung für den JSON‑Patch‑Standard (RFC 6902) in System.Text.Json ein – via dem neuen NuGet-Paket Microsoft.AspNetCore.JsonPatch.SystemTextJson. So kann JSON‑Patch ohne Newtonsoft.Json genutzt werden (außer unter NativeAOT).

7. Welche Neuerungen bringt Entity Framework Core mit CosmosDB?

EF Core 10.0 unterstützt in Preview 4 mit Azure Cosmos DB nun Volltextsuche und eine hybride Suche, die Vektorsuche und Volltextsuche kombiniert – inklusive Reciprocal Rank Fusion (RRF). Die zuvor als Vorschau verfügbare Vektorsuche ist damit in EF Core stabilisiert.

8. Was ist neu bei ASP.NET Core / OpenAPI und Minimal APIs?

• In Web API Native AOT–Vorlage ist OpenAPI-Spec (OAS) nun standardmäßig aktiviert.

• Seit Preview 3 gibt es AddOpenApiOperationTransformer(), mit dem generierte OpenAPI-Dokumente modifiziert werden können (z. B. Beschreibung oder Header-Parameter).

• Minimal WebAPIs erhalten Parametervalidierung über DataAnnotations, durch Aktivieren (AddValidation()) auch für Record-Typen ab Preview 4.

8. Welche Neuerungen bringt Blazor?

• Persistent Component State kann jetzt einfach durch [SupplyParameterFromPersistentComponentState] verwendet werden (Preview 3).

• In Preview 4 erweitert sich NavigationManager um NotFound() (Signalisiert 404 im statischen Rendering) und das Ereignis OnNotFound(). Zudem funktioniert NavigateTo() im statischen Rendering out-of-the-box, optional kann Verhalten per Switch angepasst werden.

• Standalone Blazor WebAssembly nutzt nun automatisch Fingerprinting für die eingebundene JS-Datei, um Caching-Probleme zu vermeiden.

• Response Streaming im HttpClient (WASM) ist jetzt standardmäßig aktiviert – was effizienter ist, aber synchrones Send() nicht mehr unterstützt (Breaking Change). Abschaltbar via Projektfile oder SetBrowserResponseStreamingEnabled(false).

• JS-Interop wurde um Methoden erweitert: InvokeNew, GetValue, SetValue (sync + async), um z. B. JS-Objekte direkt zu erstellen oder Eigenschaften zu lesen/setzen.

• In QuickGrid wurde CloseColumnOptionsAsync() umbenannt in HideColumnOptionsAsync().

• Runtime Diagnostics für Blazor WebAssembly (Preview 4): Performance- und Memory-Dumps sind im Browser möglich, mittels wasm-tools Workload und entsprechenden Projektsettings (WasmProfilers, WasmNativeDebugSymbols).

Links & Literatur

[1] https://dotnet.microsoft.com/en-us/download/dotnet/10.0

[2] https://github.com/oleg-shilo/cs-script

[3] https://github.com/dotnet-script/dotnet-script

[4] https://cakebuild.net

[5] https://www.it-visions.de/scripting/dotnetscripting/dsh

[6] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview2/libraries.md#encryption-algorithm-can-now-be-specified-in-pkcs12pfx-export

[7] https://dotnet-lexikon.de/SystemTextJson/Lex/10722

[8] https://www.nuget.org/packages/Microsoft.AspNetCore.JsonPatch.SystemTextJson/10.0.0-preview.4.25258.110

[9] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview4/aspnetcore.md#json-patch-with-systemtextjson

[10] https://learn.microsoft.com/en-us/azure/cosmos-db/gen-ai/full-text-search

[11] https://learn.microsoft.com/en-us/azure/cosmos-db/gen-ai/hybrid-search

[12] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview4/efcore.md#vector-similarity-search-exits-preview

[13] https://learn.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api

[14] https://learn.microsoft.com/de-de/dotnet/api/system.componentmodel.dataannotations?view=net-9.0

[15] https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-9.0#set-the-client-side-environment-via-header

[16] https://learn.microsoft.com/en-us/dotnet/core/compatibility/10.0

[17] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview4/aspnetcore.md#blazor-webassembly-runtime-diagnostics

[18] https://learn.microsoft.com/de-de/dotnet/core/diagnostics/dotnet-gcdump

[19] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/libraries.md

[20] https://github.com/dotnet/winforms/issues/12179

The post .NET 10 Preview 3 & 4: Das steckt drin appeared first on BASTA!.

An der Grundstruktur (drei Runtimes, ein SDK) hat sich nichts geändert [1]. Auch die unterstützten Plattformen sind gleichgeblieben. Laut dem Screenshot der Downloadseite in Abbildung 1 sind weiterhin die Sprachversionen C# 13.0, F# 9.0 und Visual Basic .NET 17.13 enthalten; das ist aber nicht richtig, denn es gibt in .NET 10.0 bereits erste neue Sprachfeatures von C# 14.0.

Abb. 1: .NET-10.0-Downloadseite [1]

Zielframework und Sprachversion setzen

Für .NET 10.0 braucht man die Preview-Version von Visual Studio 2022 Version 17.14 (zum Redaktionsschluss für diesen Beitrag verfügbar auf dem Stand Preview 2, Abb. 2). Alternativ kann man das Target Framework auch manuell setzen:

<TargetFramework>net10.0</TargetFramework>

Allerdings reicht es zur Nutzung der neuen Sprachfeatures derzeit nicht aus, nur das Target Framework zu setzen; Man muss auch noch

<LangVersion>preview</LangVersion>

angeben, um alle neuen Sprachfeatures nutzen zu können.

Abb. 2: .NET 10.0 erscheint bereits in Visual Studio 2022 17.14 Preview 2

C# 14.0: Vereinfachung für nameof() mit generischen Typen

Bisher musste man in C# immer konkrete Typparameter angeben, um den Operator nameof() auf generische Typen anzuwenden. Jetzt, in C# 14.0, kann man als kleine Syntaxvereinfachung auch die Typparameter im Code weglassen (Listing 1).

<em>// BISHER</em>
Console.WriteLine(nameof(List<int>)); <em>// --> List</em>
Console.WriteLine(nameof(System.Collections.Generic.LinkedListNode<int>)); <em>// --> LinkedListNode</em>
<em>Console.WriteLine(nameof(System.Collections.Generic.KeyValuePair<int, string>)); // --> KeyValuePair</em>

<em>// NEU</em>
Console.WriteLine(nameof(List<>)); <em>// --> List</em>
Console.WriteLine(nameof(System.Collections.Generic.LinkedListNode<>)); <em>// --> LinkedListNode</em>
Console.WriteLine(nameof(System.Collections.Generic.KeyValuePair<,>)); <em>// --> KeyValuePair</em>

C# 14.0: Vereinfachungen bei Lambdaausdrücken

In Lambdaausdrücken kann man in C# 14.0 jetzt Parameter-Modifizierer wie scoped, ref, in, out und _ref readonly_verwenden, ohne dabei den Datentyp benennen zu müssen. Als Beispiel für den delegate

delegate bool Extract<T>(string text, out T result);

musste man vor C# 14.0 schreiben:

Extract<int> ExtractOld = (string text, out int result) => Int32.TryParse(text, out result);

Jetzt in C# 14.0 können Entwickler:innen im Lambdaausdruck die Nennung der Datentypen _string_und int weglassen, weil diese Datentypen aus dem Kontext bereits klar sind:

Extract<int> ExtractNew = (text, out result) => Int32.TryParse(text, out result);

Das geht allerdings nicht, wenn ein variadischer Parameter mit params zum Einsatz kommt:

Add<int> AddOld = (out int result, params List<int> data) => { result = data.Sum(); return true; };

Nicht möglich ist also diese Verkürzung:

Add<int> AddNew = (out result, params data) => { result = data.Sum(); return true; };

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

C# 14.0: mehr Konvertierungen für Span und ReadOnlySpan

Im Rahmen der Initiative „First-Class Span Types” [2] soll C# 14.0 neue automatische Konvertierungen zwischen Arrays und Span sowie ReadOnlySpan enthalten. Dabei waren einige Konvertierungen bisher schon möglich und da das Dokument „What’s new in C# 14″ [3] nicht genau auflistet, was die Neuerungen sind, sondern nur auf die Liste aller möglichen Konvertierungen verweist, fällt es schwer, herauszufinden, was wirklich neu ist.

In einem Test konnte aber folgender Fall gefunden werden: Wenn die Klasse Developer von der Basisklasse Person erbt, dann kann ein Array

Developer[] devs = new Developer[3];

in C# 14.0 wie folgt konvertiert werden:

Span<Developer> devsSpan = devs;
ReadOnlySpan<Developer> devsROSpan = devs;
ReadOnlySpan<Person> personROSpan = devs;
ReadOnlySpan<Person> personROSpanFromSpan = devsSpan;

In C# 13.0 war hier nur der letzte Fall erlaubt, wenn man dort preview setzte. Vermutlich wird auch dieses Sprachfeatures in C# 14.0 dann als stabil gelten.

C# 14.0: Schlüsselwort field

Im Dokument „What’s new in C# 14″ [3] beschreibt Microsoft zudem das Schlüsselwort field, mit dem man sogenannte Semi-Auto Properties erstellen kann (Listing 2). Auch dieses Sprachfeature gibt es schon in der stabilen Version von .NET 9.0 – darin aber im Status Preview, d. h., man musste auch dafür preview setzen. Die Erwähnung in „What’s new in C# 14″ legt die Vermutung nahe, dass das Sprachfeature in C# 14.0 dann als stabil gelten wird.

<em>/// <summary></em>
<em>/// Semi-Auto Property</em>
<em>/// </summary></em>
public int ID
{
  get;
  set <em>// init w&#xE4;re hier auch erlaubt!</em>
  {
    if (value < 0) throw new ArgumentOutOfRangeException();
    if (field > 0) throw new ApplicationException("ID schon gesetzt");
    field = value;
  }
} = -1;

C# 14.0: partielle Konstruktoren und partielle Events

C# kennt seit Version 2.0 partielle Klassen und seit Version 3.0 partielle Methoden. Im Jahr 2024 kamen in C# 13.0 partielle Properties und Indexer hinzu. Nun in C# 14.0 sollen Entwickler:innen das Schlüsselwort partial auch auf Konstruktoren und Events in C#-Klassen anwenden können (Listing 3). So es steht in den Releases-Notes zu C# in .NET 10.0 Preview 2 [4].

partial class C
{
  partial C(int x, string y);
  partial event Action<int, string> MyEvent;
}

partial class C
{
  partial C(int x, string y) { }
  partial event Action<int, string> MyEvent
  {
    add { }
    remove { }
  }
}

Der C#-Compiler möchte das Beispiel aus der Dokumentation [5] aber noch nicht übersetzen und meldet Fehler sowohl in Visual Studio als auch beim Kommandozeilenbefehl dotnet build (Abb. 3 und 4), selbst wenn man preview in die Projektdatei schreibt. Laut [6] kommt das Feature in Visual Studio auch erst mit Version 17.4 Preview 3; diese Version war zum Redaktionsschluss noch nicht verfügbar.

Abb. 3: Kompilierungsfehler in Visual Studio beim Versuch der Verwendung von partiellen Konstruktoren und partiellen Events in .NET 10.0 Preview 2

Abb. 4: Kompilierungsfehler auf der Kommandozeile beim Versuch der Verwendung von partiellen Konstruktoren und partiellen Events in .NET 10.0 Preview 2

Visual Basic .NET: OverloadResolutionPriority

Auch beim Visual-Basic-.NET-Compiler gibt es nach langer Stagnation mal wieder kleine Neuerungen: Der Compiler hält sich nun an die in .NET 9.0 und C# 13.0 eingeführte Annotation [OverloadResolutionPriority] zur Priorisierung von Überladungen.

.NET SDK: vereinheitlichte Kommandozeilenparameterreihenfolge

In dem .NET-SDK-Kommandozeilenwerkzeug _dotnet_hat Microsoft in .NET 10.0 die Parameterreihenfolge vereinheitlicht. Es gab bisher viele Befehle, die aus einem Substantiv gefolgt von einem Verb oder Adjektiv bestanden (z. B. dotnet new list, dotnet workload install, dotnet nuget add).

Es gab aber auch einige Befehle, bei denen am Anfang ein Verb stand, z. B. dotnet add reference und dotnet remove package. Das hat Microsoft nun vereinheitlicht zu folgenden neuen Befehlen:

dotnet package add
dotnet package list
dotnet package remove
dotnet reference add
dotnet reference list
dotnet reference remove

Die alten Kommandozeilenbefehle mit dem Verb vorne sind aber weiterhin vorhanden, sodass hier kein Breaking Change entsteht.

.NET SDK: neuer Standard bei Workload Sets

Das .NET SDK verwendet bei der Workload-Verwaltung in .NET 10.0 nun als Standard den in .NET 9.0 eingeführten Modus „Workload Sets” anstelle des bisherigen Standards, den Microsoft „Loose Manifests” nennt [7].

Im .NET SDK gibt es zudem eine Optimierung für die Beschleunigung des Package Restore [8].

Basisklassenbibliothek: LINQ-Operatoren LeftJoin() und RightJoin()

Wie in den letzten .NET-Versionen auch, liefert Microsoft in .NET 10.0 wieder neue Operatoren für Language Integrated Query (LINQ), die bestehende Konstrukte vereinfachen. Dieses Mal sind es mit LeftJoin() und RightJoin() zwei elementare Operatoren aus der Mengenlehre und den relationalen Datenbanken. Tatsächlich waren diese Operationen in LINQ bereits möglich, allerdings umständlich mit Hilfe einer Gruppierung mit GoupJoin() und SelectMany() sowie DefaultIfEmpty(). Die neuen Methoden LeftJoin() und RightJoin() vereinfachen die Verwendung, wie Listing 4 am Beispiel des Joins zwischen den Klassen Company und _Website_zeigt, die Ausgabe ist in Abbildung 5 zu sehen.

Company[] companies =
  [
    new Company{ ID = 1, Name = "www.IT-Visions.de" },
    new Company{ ID = 2, Name = "Software & Support" },
    new Company{ ID = 3, Name = "Startup i.Gr." } <em>// hat noch keine Website</em>
  ];

Website[] websites =
  [
    new Website{ CompanyID = 1, URL = "www.IT-Visions.de" },
    new Website{ CompanyID = 1, URL = "www.dotnet10.de" },
    new Website{ CompanyID = 2, URL = "www.entwickler.de" },
    new Website{ URL = "www.Microsoft.com" }, <em>// Firma ist noch nicht angelegt</em>
  ];

CUI.H2("--- LeftJoin ALT seit .NET Framework 3.5 ---");

var AllCompaniesWithWebsitesSetOld = companies
  .GroupJoin(websites,
    c => c.ID,
    w => w.CompanyID,
    c, websites) => new { Company = c, Websites = websites })
  .SelectMany(
    x => x.Websites.DefaultIfEmpty(), <em>// Falls keine Webseite existiert, wird `null` verwendet</em>
    (c, w) => new WebsiteWithCompany
    {
      Name = c.Company.Name,
      URL = w.URL, <em>// Falls `w` null ist, bleibt URL null</em>
      City = c.Company.City
  });

foreach (var item in AllCompaniesWithWebsitesSetOld)
{
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma - ") + " -> " + (item.URL ?? "- keine URL -"));
}

CUI.H2("--- LeftJoin NEU ab .NET 10.0 ---");
var AllCompaniesWithWebsitesSet = companies.LeftJoin(websites, e => e.ID, e => e.CompanyID, (c, w) => new WebsiteWithCompany { Name = c.Name, City = c.City, URL = w.URL });
foreach (var item in AllCompaniesWithWebsitesSet)
{
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma - ") + " -> " + (item.URL ?? "- keine URL -"));
}

CUI.H2("--- RightJoin OLD seit .NET Framework 3.5  ---");
var WebsiteWithCompanySetOLD = websites
  .GroupJoin(companies,
    w => w.CompanyID,
    c => c.ID,
    (w, companies) => new { Website = w, Companies = companies })
  .SelectMany(
    x => x.Companies.DefaultIfEmpty(), <em>// Falls kein Unternehmen existiert, bleibt `null`</em>
    (w, c) => new WebsiteWithCompany
    {
      Name = c.Name, <em>// Falls `c` null ist, bleibt `Name` null</em>
      City = c.City, <em>// Falls `c` null ist, bleibt `City` null</em>
      URL = w.Website.URL
  });

foreach (var item in WebsiteWithCompanySetOLD)
{
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma - ") + " -> " + (item.URL ?? "- keine URL -"));
}

CUI.H2("--- RightJoin NEU ab .NET 10.0 ---");
var WebsiteWithCompanySet = companies.RightJoin(websites, e => e.ID, e => e.CompanyID, (c, w) => new WebsiteWithCompany { Name = c.Name, City = c.City, URL = w.URL });

foreach (var item in WebsiteWithCompanySet)
{
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma - ") + " -> " + (item.URL ?? "- keine URL -"));
}

<em>// Zum Vergleich: Inner Join, den es seit .NET Framework 3.5 gibt</em>
CUI.H2("--- InnerJoin seit .NET Framework 3.5 ---");
var CompaniesWithWebsitesSet = companies.Join(websites,
  c => c.ID,
  w => w.CompanyID,
  (c, w) => new WebsiteWithCompany
  {
    Name = c.Name,
    URL = w.URL,
    City = c.City
});
foreach (var item in CompaniesWithWebsitesSet)
{
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma - ") + " -> " + (item.URL ?? "- keine URL -"));
}

Abb. 5: Ausgabe von Listing 4

Basisklassenbibliothek: TryAdd() und TryGetValue() für OrderedDictionary<T,T>

Die erst in .NET 9.0 neu eingeführte generische Klasse System.Collections.Generic.OrderedDictionary<T,T> bot bisher schon eine Methode TryAdd(), die versucht, ein Element hinzuzufügen. Neben der bestehenden Variante TryAdd(TKey key, TValue value) gibt es nun in .NET 10.0 auch die Methode TryAdd(TKey key, TValue value, out int index) (Listing 5). Diese neue Überladung liefert den Index zurück, falls es das Element in der Menge schon gibt. Analog dazu gibt es für die Methode TryGetValue() nun eine neue Überladung, die nicht nur den Wert eines Eintrags liefert, sondern auch die Position des gefundenen Elements per Index.

OrderedDictionary<string, string> websites = new OrderedDictionary<string, string>();
websites.Add("Software & Support", "www.Entwickler.de");
websites.Add("Microsoft", "www.Microsoft.com");
websites.Add("IT-Visions", "www.IT-Visions.de");

var propertyName = "IT-Visions";
var value = "www.IT-Visions.de";

<em>// bisher</em>
if (!websites.TryAdd(propertyName, value))
{
  int index1 = websites.IndexOf(propertyName); <em>// Second lookup operation</em>
  CUI.Warning("Element " + value + " ist bereits vorhanden!");
}

<em>// neu</em>
if (!websites.TryAdd(propertyName, value, out int index))
{
  CUI.Warning("Element " + value + " ist bereits vorhanden an der Position " + index + """!""");
}

<em>// neu</em>
if (websites.TryGetValue(propertyName, out string? value2, out int index2))
{
  CUI.Success($"Element {value2} wurde gefunden an der Position {index2}.");
}

Basisklassenbibliothek: IP-Adressen prüfen

Zur Prüfung von IP-Adressen gibt es in der Klasse System.Net schon seit .NET Framework 2.0 die statische Methode IPAddress.TryParse(), die eine IP-Adresse aus einer Zeichenkette extrahiert. Seit .NET Core 2.1 ist die Extraktion auch aus dem Typ ReadOnlySpan möglich. Der Rückgabewert ist ein bool-Wert und die extrahierte IP-Adresse wird in Form einer Instanz der Klasse IPAddress als out-Parameter geliefert. Wenn man nur prüfen will, ob die IP-Adresse stimmt, schreibt man _IPAddress.TryParse(eingabe, out ).

In .NET 10.0 bietet Microsoft nun in der statischen Methode _IsValid()_eine weitere Prüfungsvariante mit weniger internem Aufwand. Beispiel:

System.Net.IPAddress.IsValid("192.168.1.0")

Dabei kehrt Microsoft nun einfach eine bisher interne Methode TargetHostNameHelper.IsValidAddress() nach außen [9].

Basisklassenbibliothek: Verbesserung beim Zertifikatsexport

Seit .NET 10.0 Preview 2 soll laut Release Notes in der Klasse X509Certificate2 eine neue Methode ExportPkcs12() existieren, die Entwickler:innen mehr Kontrolle über die Verschlüsselungs- und Digest-Algorithmen geben soll. Die bisherige Methode Export() verwendet noch veraltete Algorithmen wie 3DES und SHA1. Die neue Methode ExportPkcs12() soll auch AES und SHA-2-256 bieten.

In den Release Notes zu .NET 10.0 Preview 2 [10] fehlt allerdings ein Beispiel und im Test konnte der Compiler weder auf der Klasse X509Certificate2 noch der Basisklasse X509Certificate die Methode ExportPkcs12() finden. Das zugehörige Issue auf GitHub steht auf dem Status Closed [11]. Da sich im Change-Log zu .NET 10.0 Preview 2 [12] auch kein Eintrag zu ExportPkcs12() finden lässt, sind die Release-Notes an dieser Stelle vermutlich voreilig und die neue Methode kommt erst in einer späteren Vorschauversion.

Basisklassenbibliothek: weitere Verbesserungen

Außerdem hat Microsoft diese drei Punkte in der .NET-Basisklassenbibliothek in .NET 10.0 Preview 1 und 2 verbessert:

• In der Klasse X509Certificate2Collection existiert eine neue Methode _FindByThumbprint()_um ein digitales Zertifikat anhand des SHA-Fingerabdrucks zu finden.
• Die Klasse ISOWeek bietet drei neue Methoden zum Umgang mit dem Datentyp System.DateOnly. Bisher war hier nur System.DateTime möglich:

DateOnly now = DateOnly.FromDateTime(DateTime.Now);
Console.WriteLine(ISOWeek.GetWeekOfYear(now));
Console.WriteLine(ISOWeek.GetYear(now));
Console.WriteLine(ISOWeek.ToDateOnly(2025, 1, DayOfWeek.Tuesday)); <em>// 30.12.2024</em>

• Die Implementierung der Verarbeitung von ZIP-Archiven wurde optimiert, z. B. wurde das Aktualisieren von ZIP-Archiven um 99,8 Prozent beschleunigt (ein Hinzufügen einer 2-GB-Datei von 177 ms auf 0,13 ms) und verbraucht nun 99,99 Prozent weniger RAM (nun 7,01 KB statt 2 GB RAM) [13].

Verbesserungen in Windows Forms und WPF

In Windows Forms in .NET 10.0 [14] sind nun einige Überladungen der GetData()-Methode für die Zwischenablage sowie Drag-and-Drop-Operationen als [Obsolet] markiert, die noch die Klasse BinaryFormatter verwenden, die Microsoft in .NET 9.0 ausgebaut hat und für die man nun ein eigenes NuGet-Paket braucht. Dafür gibt es nun neue Operationen, die mit JSON arbeiten, z. B. SetDataAsJson() und TryGetData().

In WPF gibt es laut Release Notes zu Preview 1 [15] und Preview 2 [16] nur Leistungsverbesserungen und Bug Fixes, u. a. am in .NET 9.0 eingeführten Fluent Design für WPF.

System.Text.Json: GetPropertyCount() in der Klasse JsonElement

In der JSON-Bibliothek System.Text.Json hat Microsoft die Klasse JsonElement um die Methode GetPropertyCount() erweitert, mit der man ermitteln kann, wie viele Eigenschaften ein JSON-Objekt besitzt:

JsonElement element1 = JsonSerializer.Deserialize<JsonElement>("""{ "ID" : 1, "Name" : "Dr. Holger Schwichtenberg", "Website": "www.IT-Visions.de" }""");
Console.WriteLine(element1.GetPropertyCount()); <em>// 3</em>

Bisher war nur möglich, die Anzahl der Objekte in einem Array zu ermitteln:

JsonElement element2 = JsonSerializer.Deserialize<JsonElement>("""[ 1, 2, 3, 4 ]""");
Console.WriteLine(element2.GetArrayLength()); <em>// 4</em>

System.Text.Json: RemoveRange() und RemoveAll() in JsonArray

In der Klasse JsonArray, im Namensraum System.Text.Json.Nodes, bietet Microsoft nun zwei Methoden RemoveRange() und RemoveAll()(Listing 6):

• RemoveRange() nimmt zwei Zahlen entgegen: Index und Count. Der Index ist wie üblich nullbasiert, d. h., array.RemoveRange(5, 2) entfernt das sechste und siebte Element.
• RemoveAll() erwartet ein Predicate-Objekt und erlaubt die Angabe eines Löschkriteriums, z. B. array.RemoveAll(n => n.GetValue() > 5);

System.Text.Json.Nodes.JsonArray array = JsonSerializer.Deserialize<System.Text.Json.Nodes.JsonArray>("""[ 1, 2, 3, 4, 5, 6, 7, 8, 9 ]""");
System.Console.WriteLine(array.Count); <em>// 9</em>
PrintJsonArray(array);

array.RemoveRange(5, 2);
PrintJsonArray(array);

array.RemoveAll(n => n.GetValue<int>() > 5);
PrintJsonArray(array);

System.Text.Json: Einstellungen für zirkuläre Referenzen

Die Annotation [JsonSourceGenerationOptions] für den Source Generator in der Bibliothek System.Text.Json erlaubt nun auch die Einstellung des Verhaltens bei zirkulären Referenzen auf Unspecified, _Preserve_oder IgnoreCycles, z. B.:

[JsonSourceGenerationOptions(ReferenceHandler = JsonKnownReferenceHandler.Preserve)]

ASP.NET Core: OpenAPI Specification (OAS) 3.1

In ASP.NET Core WebAPIs in .NET 10.0 werden Metadaten nun im Standard in der Version 3.1 – bisher Version 3.0 – der OpenAPI Specification (OAS) mit vollständiger Unterstützung des JSON-Schema-Standards 2020-12 [17] generiert. Die Umstellung von Version 3.0 auf Version 3.1 geht einher mit Breaking Changes [18].

Entwickler:innen können daher bei Bedarf im Startcode des ASP.NET-Core-Webservers die OAS-Version mit diesem Befehl zurückstufen:

builder.Services.AddOpenApi(options =>
{
  options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_0;
});

Wenn OAS-Dokumente im Rahmen des Build-Prozesses gesteuert werden, geht die Zurückstufung wie folgt in der Projektdatei (.csproj):

<OpenApiGenerateDocumentsOptions>
  --openapi-version OpenApi3_0
</OpenApiGenerateDocumentsOptions>

ASP.NET Core: OpenAPI-Dokumente in YAML

Die OAS-Dokumente in ASP.NET Core waren bisher immer im JSON-Format. ASP.NET Core 10.0 bietet seit Preview 1 alternativ auch das YAML-Format an, das kürzere Dokumente liefert (Abb. 6). YAML als Alternative zu JSON stellt man im Startcode ein, indem man bei der Methode MapOpenApi() einen Dokumentnamen angibt, der auf .yml oder .yaml endet:

app.MapOpenApi("/openapi/{documentName}.yml");

oder

app.MapOpenApi("/openapi/{documentName}.yaml");

Die YAML-Metadaten können Entwickler:innen aber noch nicht im Build-Prozess einstellen. Microsoft will diese Option in einer kommenden Preview-Version liefern.

Abb. 6: Ein OpenAPI-3.1-Dokument im JSON- (links) und kompakteren YAML-Format (rechts)

ASP.NET Core: OpenAPI-Dokumente mit XML-Kommentaren

Die von dem NuGet-Paket Microsoft.AspNetCore.OpenApi generierten OpenAPI-Metadaten für ein ASP.NET Core WebAPI können nun auch Informationen aus den XML-Kommentaren enthalten, die zu Klassen bzw. Methoden hinterlegt sind. Diese Integration können Entwickler:innen mit einem Eintrag in der Projektdatei aktivieren:

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

Welche XML-Kommentare auf welche Weise in das OpenAPI-Dokument übernommen werden, steht leider nicht in den Release-Notes [19] und bedauerlicherweise ließ sich das auch nicht testen, da durch die Installation des .NET 10.0 Preview 2 SDK alle WebAPI-Projekte beim Start nur noch HTTP-Fehler 404 liefern, auch mit den aktuellsten Projektvorlagen neu angelegter Projekte. Das Problem trat auf zwei verschiedenen Testrechnern auf.

ASP.NET Core: Beschreibungstexte für Rückgabewerte

Bei Controller-basierten WebAPIs können Entwickler:innen nun in den Annotationen [ProducesAttribute], [ProducesResponseTypeAttribute] und [ProducesDefaultResponseType] jeweils Beschreibungstexte angeben, die auch im OAS-Dokument erscheinen:

[HttpGet(Name = "GetWeatherForecast")]
[ProducesResponseType<IEnumerable<WeatherForecast>>(StatusCodes.Status200OK, Description = "The weather forecast for the next 5 days.")]
public IEnumerable<WeatherForecast> Get()
{
  ...
}

Das geht in Minimal WebAPIs schon seit Version 7.0 mit dem Methodenaufruf WithDescription().

Blazor: Anpassung der Verbindungsproblemmeldungen bei Blazor Server

Blazor Server stellt einen modalen Dialog dar, falls ein Abbruch der WebSockets-Verbindung zwischen Webbrowser und Webserver erfolgt ist und eine Wiederaufnahme versucht wird. Diese Darstellung war bisher nicht anpassbar.

In der Projektvorlage Blazor Web App findet man seit .NET 10.0 Preview 2 eine neue Razor Component im Ordner _Layout mit Namen ReconnectModal.razor(Listing 7). Diese Komponente enthält die Standarddarstellung des modalen Fensters bei Verbindungsproblemen. Damit können Entwickler:innen in .NET 10.0 also Einfluss auf die Texte und die Darstellung in drei Fällen nehmen:

• Wiederherstellung wird versucht
• Wiederherstellung ist fehlgeschlagen und wird erneut versucht
• Wiederherstellung ist endgültig fehlgeschlagen

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20type%3D%22module%22%20src%3D%22%40Assets%5B%22Components%2FLayout%2FReconnectModal.razor.js%22%5D%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&lt;script&gt;" title="&lt;script&gt;" />

<dialog id="components-reconnect-modal" data-nosnippet>
  <div class="components-reconnect-container">
    <div class="components-rejoining-animation" aria-hidden="true">
      <div></div>
      <div></div>
    </div>
    <p class="components-reconnect-first-attempt-visible">
      Rejoining the server...
    </p>
    <p class="components-reconnect-repeated-attempt-visible">
      Rejoin failed... trying again in <span id="components-seconds-to-next-attempt"></span> seconds.
    </p>
    <p class="components-reconnect-failed-visible">
      Failed to rejoin.<br />Please retry or reload the page.
    </p>
    <button id="components-reconnect-button" class="components-reconnect-failed-visible">
      Retry
    </button>
  </div>
</dialog>

Zur Razor Component ReconnectModal.razor gehören auch eine CSS-Datei ReconnectModal.razor.css und eine JavaScript-Datei ReconnectModal.razor.js. Auch diese Dateien sind anpassbar. ReconnectModal.razor wird am Ende der Datei MainLayout.razor eingebunden via und kann auch komplett ersetzt werden.

Blazor: NavigateTo() behält Scrollposition

Die Methode NavigateTo() in der Blazor-Klasse _NavigationManager_führt den Nutzer bzw. die Nutzerin nicht mehr zum Beginn der Seite zurück, falls der Entwickler bzw. die Entwicklerin nur URL-Parameter an die Seite anhängt:

nav.NavigateTo(nav.GetUriWithQueryParameter("count", currentCount));

Ein Rücksprung an den Seitenanfang findet allerdings bei Angabe von true für forceLoad weiterhin statt

nav.NavigateTo(nav.GetUriWithQueryParameter("count", currentCount), forceLoad: true);

oder bei Änderungen eines Teils des relativen Pfades:

nav.NavigateTo("/counter/" + currentCount);

Blazor: Verbesserungen beim QuickGrid

Im Tabellensteuerelement können Entwickler:innen nun eine Methode angeben, die bei jeder Zeile aufgerufen wird, um die CSS-Klasse der Zeile individuell auf Basis der Daten zu setzen (Listing 8).

<QuickGrid RowClass="ApplyRowClass" ItemsProvider="@itemsProvider" TGridItem="BO.WWWings.Flight" Virtualize="true" OverscanCount="@overscanCount">
  <PropertyColumn Property="@(p => p.FlightNo)" Title="FlugNr" Sortable="true" />
  <PropertyColumn Property="@(p => p.Departure)" Title="Abflugort" Sortable="true" />
  <PropertyColumn Property="@(p => p.Destination)" Title="Zielort" Sortable="true" />
  <PropertyColumn Property="@(p => p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
</QuickGrid>

@code {
  private string ApplyRowClass(BO.WWWings.Flight rowItem) => rowItem.FreeSeats < 10 ? "red" : null;
}

Außerdem gibt es im QuickGrid-Steuerelement nun eine neue Methode CloseColumnOptionsAsync()(Listing 9), die Entwickler:innen aufrufen können, damit sich die Eingabe von Filterkriterien schließt, wenn der Filter aktiviert wird: Der Aufruf CloseColumnOptionsAsync() sorgt dafür, dass die geöffnete Filtereingabe sich automatisch wieder schließt, wenn der Nutzer bzw. die Nutzerin ein Eingabetaste drückt (Abb. 7).

<QuickGrid @ref="flightGrid" RowClass="ApplyRowClass" ItemsProvider="@itemsProvider" TGridItem="BO.WWWings.Flight" Virtualize="true" OverscanCount="@overscanCount">
  <PropertyColumn Property="@(p => p.FlightNo)" Title="FlugNr" Sortable="true" />
  <PropertyColumn Property="@(p => p.Departure)" Title="Abflugort" Sortable="true">

    <ColumnOptions>
      <input type="search" @bind="departureFilter" placeholder="Filter by Departure"
        @bind:after="@(() => flightGrid.CloseColumnOptionsAsync())" />
    </ColumnOptions>

  </PropertyColumn>
  <PropertyColumn Property="@(p => p.Destination)" Title="Zielort" Sortable="true" />
  <PropertyColumn Property="@(p => p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
</QuickGrid>

Abb. 7: Geöffnete Filtereingabe soll sich durch CloseColumnOptionsAsync() automatisch schließen

Blazor: Fingerprinting für Blazors JavaScript-Datei

Die bei Blazor mitgelieferte JavaScript-Datei (je nach verwendeter Projektvorlage: blazor.web.js, blazor.server.js bzw. blazor.webassembly.js) erhält in .NET 10.0 die bereits in .NET 9.0 eingeführte Möglichkeit zur Komprimierung und einem Fingerabdruck des Inhalts im Dateinamen, der verhindert, dass alte Versionen aus dem Browsercache verwendet werden.

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Entity Framework: Verbesserungen für ExecuteUpdate() und ExecuteUpdateAsync()

Bei den Methoden zum Massenaktualisieren, namentlich ExecuteUpdate() und ExecuteUpdateAsync(), bietet Entity Framework Core 10.0 nun eine bessere Übersichtlichkeit bei komplexeren Ausdrücken, indem nicht nur Expression-Lambdas, sondern auch Statement-Lambdas erlaubt sind. Anstelle von

var c0 = ctx.Flights.Where(f => f.FlightNo <= 100).ExecuteUpdate(s => s.SetProperty(f => f.FreeSeats, f => f.FreeSeats - 1)
  .SetProperty(f => f.Memo, f => (setMemo ? "Freie Pl&#xE4;tze ge&#xE4;ndert am " + DateTime.Now : f.Memo))
);

können Entwickler:innen nun auch schreiben:

var c1 = ctx.Flights.Where(f => f.FlightNo <= 100).ExecuteUpdate(s =>
  {
    s.SetProperty(f => f.FreeSeats, f => f.FreeSeats - 1);
    if (setMemo)
    {
      s.SetProperty(f => f.Memo, "Freie Pl&#xE4;tze ge&#xE4;ndert am " + DateTime.Now);
    }
});

Auch wenn die Release-Notes explizit nur von der asynchronen Methode _ExecuteUpdateAsync()_sprechen, funktioniert das Feature im Schnelltest auch mit der synchronen Variante ExecuteUpdate().

Entity Framework: RightJoin() und LeftJoin()

Die in .NET 10.0 neu eingeführten Operatoren LeftJoin() und RightJoin() werden auch in Entity Framework Core 10.0 bereits für Datenbankzugriffe unterstützt [20], [21]. Die folgenden Listings zeigen den Einsatz von RightJoin() und LeftJoin() bei Entity Framework Core 10.0 in Verbindung mit einer relationalen Datenbank. Auch in Entity Framework konnte man das Ergebnis von RightJoin() und LeftJoin() bisher schon via _GoupJoin()_und _SelectMany()_mit _DefaultIfEmpty()_erzielen.

Aus dem LINQ-Befehl mit LeftJoin() in Listing 10 entsteht der SQL-Befehl in Listing 11. Aus diesem LINQ-Befehl mit RightJoin() in Listing 12 entsteht der SQL-Befehl in Listing 13.

CUI.H2("Suche alle Flüge, zu denen es keinen Piloten gibt via LeftJoin()");
var ctx = new DA.WWWings.WwwingsV1EnContext();
var fluegeOhnePilot = ctx.Flights
  .LeftJoin(
    ctx.Pilots,
    f => f.PilotPersonId,
    p => p.PersonId,
    (f, p) => new
    {
      f.FlightNo,
      f.Departure,
      f.Destination,
      f.FlightDate,
      PilotId = f.PilotPersonId == null ? "n/a" : f.PilotPersonId.ToString(),
      p.Employee.Person.GivenName,
      p.Employee.Person.Surname,
  }).Where(x => x.Surname == null).Take(20).ToList();

foreach (var item in fluegeOhnePilot)
{
  Console.WriteLine($"{item.FlightNo} {item.Departure}->{item.Destination} am {item.FlightDate}: Pilot {item.PilotId} {item.GivenName} {item.Surname}");
}

SELECT TOP(@p) [f].[FlightNo], [f].[Departure], [f].[Destination], [f].[FlightDate], CASE
  WHEN [f].[Pilot_PersonID] IS NULL THEN 'n/a'
  ELSE COALESCE(CONVERT(varchar(11), [f].[Pilot_PersonID]), '')
END AS [PilotId], [p0].[GivenName], [p0].[Surname]
FROM [Operation].[Flight] AS [f]
LEFT JOIN [People].[Pilot] AS [p] ON [f].[Pilot_PersonID] = [p].[PersonID]
LEFT JOIN [People].[Employee] AS [e] ON [p].[PersonID] = [e].[PersonID]
LEFT JOIN [People].[Person] AS [p0] ON [e].[PersonID] = [p0].[PersonID]
WHERE [p0].[Surname] IS NULL

var pilotenMitFlug = ctx.Flights
  .RightJoin(
    ctx.Pilots.OrderByDescending(x => x.PersonId).Take(3),
    f => f.PilotPersonId,
    p => p.PersonId,
    (f, p) => new
    {
      PilotId = p.PersonId,
      p.Employee.Person.GivenName,
      p.Employee.Person.Surname,
      Flight = f,
      f.Departure,
      f.Destination,
      <em>//Date = f.FlightDate == DateTime.MinValue ? "n/a" : f.FlightDate.ToShortDateString(), // TODO: LAUFZEITFEHLER. Pr&#xFC;fen in RTM!</em>

  }).OrderBy(x => x.PilotId).ToList();

foreach (var p in pilotenMitFlug)
{
  Console.WriteLine($"Pilot #{p.PilotId} {p.GivenName} {p.Surname} fliegt " + (p.Flight != null ? $"Flug #{p.Flight?.FlightNo} {p.Flight.Departure}->{p.Flight.Destination} am {p.Flight.FlightDate}" : "bisher keinen Flug"));
}

SELECT [p0].[PersonID] AS [PilotId], [p1].[GivenName], [p1].[Surname], [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
RIGHT JOIN (
  SELECT TOP(@p) [p].[PersonID]
  FROM [People].[Pilot] AS [p]
  ORDER BY [p].[PersonID] DESC
) AS [p0] ON [f].[Pilot_PersonID] = [p0].[PersonID]
INNER JOIN [People].[Employee] AS [e] ON [p0].[PersonID] = [e].[PersonID]
INNER JOIN [People].[Person] AS [p1] ON [e].[PersonID] = [p1].[PersonID]
ORDER BY [p0].[PersonID]

Es sei zudem explizit darauf hingewiesen, dass man die neuen Operatoren _RightJoin()_und LeftJoin() einschließlich der vorher schon vorhandenen Operatoren _Join()_und GroupJoin() nur für die Verbindung von Tabellen braucht, für die es im Objektmodell keine Navigationsbeziehung gibt. So kann man statt des aufwendigen RightJoin() bei einer vorhandenen Navigationsbeziehung im Objektmodell dasselbe Ausgabeergebnis mit einem Include() erreichen. In diesem Fall erhält man allerdings keine flache Liste mit Daten aus Pilot und Flug, sondern eine Objekthierarchie, daher zwei verschachtelte foreach-Schleifen (Listing 14). Entity Framework Core führt dabei nur Inner Joins aus (Listing 15).

CUI.H2("Gib zu den letzten drei angelegten Piloten alle Flüge aus via Navigation Property");

var pilotenMitFlug2 = ctx.Pilots.Include(p => p.Employee).ThenInclude(p => p.Person).Include(p => p.Flights).OrderByDescending(x => x.PersonId).Take(3).OrderBy(x => x.PersonId).ToList();

foreach (Pilot p in pilotenMitFlug2)
{
  if (p.Flights.Count == 0)
  {
    Console.WriteLine($"Pilot #{p.PersonId} {p.Employee.Person.GivenName} {p.Employee.Person.Surname} fliegt bisher keinen Flug");
  }
  else
  {
    foreach (var f in p.Flights)
    {
      Console.WriteLine($"Pilot #{p.PersonId} {p.Employee.Person.GivenName} {p.Employee.Person.Surname} fliegt Flug #{f.FlightNo} {f.Departure}->{f.Destination} am {f.FlightDate}");
    }
  }
}

SELECT [p0].[PersonID], [p0].[FlightHours], [p0].[FlightSchool], [p0].[LicenseDate], [p0].[LicenseType], [e].[PersonID], [e].[EmployeeNo], [e].[HireDate], [e].[Supervisor_PersonId], [p1].[PersonID], [p1].[Birthday], [p1].[City], [p1].[Country], [p1].[EMail], [p1].[GivenName], [p1].[Memo], [p1].[Photo], [p1].[Surname], [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], [f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], [f].[Seats], [f].[Timestamp]
FROM (
  SELECT TOP(@p) [p].[PersonID], [p].[FlightHours], [p].[FlightSchool], [p].[LicenseDate], [p].[LicenseType]
  FROM [People].[Pilot] AS [p]
  ORDER BY [p].[PersonID] DESC
) AS [p0]
INNER JOIN [People].[Employee] AS [e] ON [p0].[PersonID] = [e].[PersonID]
INNER JOIN [People].[Person] AS [p1] ON [e].[PersonID] = [p1].[PersonID]
LEFT JOIN [Operation].[Flight] AS [f] ON [p0].[PersonID] = [f].[Pilot_PersonID]
ORDER BY [p0].[PersonID], [e].[PersonID], [p1].[PersonID]

Entity Framework: weitere Verbesserungen für LINQ

Entity Framework Core bietet in Version 10.0 Preview 1 und 2 zwei Verbesserungen bei der Übersetzung von LINQ in SQL:

• Die .NET-Methode DateOnly.ToDateTime(timeOnly) wird nun in SQL übersetzt.
• Optimiert wurde die Übersetzung von Count() in ICollection.

.NET MAUI: ShadowTypeConverter

In .NET MAUI 10.0 Preview 2 können Entwickler:innen nun mit einer vereinfachten Syntax Schatten definieren:

<VerticalStackLayout BackgroundColor="#fff" Shadow="4 4 16 #000000 0.5" />

Dabei stehen die Zahlen in der Eigenschaft _Shadow_für Offset X, Offset Y, Radius, Farbe und Opazität. Zuvor musste man hier eigene Tags verwenden:

<VerticalStackLayout BackgroundColor="#fff" >
  <Shadow       Brush="#000000"
                Offset="4,4"
                Radius="16"
                Opacity="0.5" />
</VerticalStackLayout>

.NET MAUI: Steuerung von Farben

Entwickler:innen können beim Steuerelement __nun neben OnColor auch _OffColor_festlegen:

<Switch OffColor="Red"
        OnColor="Green" />

Beim Steuerelement lässt sich die Farbe des Symbols steuern:

<SearchBar Placeholder="Search items..." SearchIconColor="Blue" />

.NET MAUI: Steuerung der Geschwindigkeit der Sprachausgabe

Bei Sprachausgabe mit der Schnittstelle Klasse TextToSpeech kann man nun die Geschwindigkeit via Eigenschaft Rate angeben (Listing 16).

IEnumerable<Locale> locales = await TextToSpeech.Default.GetLocalesAsync();
  SpeechOptions options = new SpeechOptions()
  {
    Rate = 2.0f, <em>// 0.1 - 2.0</em>
    Pitch = 1.5f, <em>// 0.0 - 2.0</em>
    Volume = 0.75f, <em>// 0.0 - 1.0</em>
    Locale = locales.FirstOrDefault()
  };
await TextToSpeech.Default.SpeakAsync("Hallo aus .NET 10.0!", options);

.NET MAUI: Verbesserungen für Android

.NET MAUI unterstützt nun JDK-Version 21 und Android-Version 16 (Codename Baklava, API-Version 36). Die MAUI-Projektvorlage verwendet nun im Standard API-Version 24 (Nougat) statt API-Version 21 (Lollipop). Man kann aber weiterhin auf API-Version 21 zurückstufen, Microsoft empfiehlt aber in den Release-Notes [22], das nicht zu tun: „While API-21 is still supported in .NET 10, we recommend updating existing projects to API-24 in order to avoid unexpected runtime errors.”

Android-Projekte können Entwickler:innen nun mit dem Befehl dotnet run direkt von der Kommandozeile aus starten, z. B.:

<em>// Start auf Ger&#xE4;t (wenn nur ein Ger&#xE4;t angeschlossen ist)</em>
dotnet run -p:AdbTarget=-d

<em>// Start auf Emulator (wenn es nur einen gibt)</em>
dotnet run -p:AdbTarget=-e

<em>// Start auf einem bestimmten Emulator</em>
dotnet run -p:AdbTarget="-s emulator-5554"

.NET MAUI: Verbesserungen für iOS, Mac Catalyst, macOS und tvOS

Beim Kompilieren für die Apple-Plattformen (iOS, Mac Catalyst, macOS, tvOS) erzeugt der Compiler nun automatisch Trimmer-Warnungen. Diese Warnungen kann man aber ausschalten mit:

<PropertyGroup>
  <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings>
</PropertyGroup>

.NET MAUI: weitere Neuerungen

Das Steuerelement gilt nun als veraltet. Entwickler:innen sollten verwenden. Ebenso ist die Mark-up-Erweiterung FontImageExtension veraltet. Man sollte jetzt das Tag __verwenden.

Breaking Changes

Wie in jeder .NET-Version der letzten Jahre üblich, wird es auch dieses Mal in .NET 10.0 wieder einige Breaking Changes gegenüber der Vorgängerversion 9.0 geben. Einige der Breaking Changes sind bereits in Preview 1 und 2 enthalten und unter [23] dokumentiert.

Dokumentation der Neuerungen

Der .NET-API-Browser mit der .NET-Klassendokumentation [24] ist bereits auf .NET 10.0 Preview 2.0 aktualisiert, sodass man dort die neuen Klassen und Methoden sieht.

Während letztes Jahr bei .NET 9.0 die Preview-Versionen nach Preview 1 nur noch auf GitHub angekündigt wurden, gibt es seit diesem Jahr wieder einen Blogeintrag zu jeder Preview-Version (Preview 1 [25], Preview 2 [26]). Die Blogbeiträge verlinken auf die Release-Notes-Dokumente auf GitHub. Zudem gibt es jeweils aber auch immer eine Ankündigung auf GitHub [27], die neben den Release-Notes auch auf „What’s New”-Dokumente in der Dokumentation verlinkt. Das ist aber nicht immer konsistent: In der Ankündigung zu Preview 1 auf GitHub [28] fehlt der Link auf die Release-Notes von Entity Framework Core [29] gänzlich.

API-Reviews und Unboxing auf YouTube

Das .NET-Entwicklungsteam überträgt seit einiger Zeit die Diskussionen bezüglich neuer APIs (API-Reviews) live im Netz auf YouTube. Nun gibt es diese API-Reviews auch öffentlich beim Entwicklungsteam von ASP.NET Core und Blazor [30]. Die Termine der API-Reviews findet man unter [31]; die Videos der Vergangenheit findet man auf dem YouTube-Kanal der .NET Foundation [32].

Zu jeder Preview gibt es jetzt auch neu einen Unboxing-Live-Stream auf YouTube. Die Aufzeichnung ist in den Blogbeiträgen verlinkt.

Weitere Pläne für .NET 10.0

Auf GitHub findet man Roadmaps für einzelne Bereiche von .NET 10.0, z. B. C# 14.0 [33] und ASP.NET Core und Blazor [34]. Demzufolge arbeitet das C#-Team an den Extension Types (der Verallgemeinerung der Extension Methods, sodass Entwickler:innen auch Eigenschaften und Konstruktoren ergänzen können), was eigentlich schon als Sprachfeature für C# 13.0 geplant war.

Die Pläne des ASP.NET-Core-Entwicklungsteams zeigen die Abbildungen 8 und 9. Ein großes Thema sind demnach die Verbesserungen der Authentifizierungsmöglichkeiten z. B. mit Passkeys und Demonstration of Proof of Possession (DPop) Authentication Tokens. Die Microsoft Identity Platform soll in die Blazor-Web-App-Projektvorlage integriert werden [35]. Minimal WebAPIs sollen auch Validierung mit Data Annotations unterstützen [36].

Der bisher schon verfügbare Persistent Component State zur Übergabe von Daten vom Prerendering bei Blazor soll nun deklarativ via Annotation [SupplyParameterFromPersistentComponentState] möglich sein [37]. Auch soll man in Blazor Server die Circuits zur späteren Wiederaufnahme persistieren können [38]. Blazor WebAssembly soll ein Performance-Profiling erhalten (Abb. 8).

Abb. 8: Geplante Verbesserungen für Blazor

Abb. 9: Geplante Verbesserungen für ASP.NET Core WebAPIs und den Kestrel-Webserver

Andere Entwicklungsteams haben ihre Roadmaps leider bisher nicht auf .NET 10.0 aktualisiert:

• .NET MAUI [39]
• Windows Forms [40]
• WPF [41]

Auch bei Entity Framework Core gibt es keine Roadmap für Version 10.0. Man kann aber natürlich auf GitHub nach dem Milestone filtern [42], findet dort aber auch viele kleinere Bugfixes in der Liste und kann auf den ersten Blick keine Strategie erkennen. Bei Entity Framework Core findet man zum Beispiel geplante Verbesserungen für komplexe Typen: Diese sollen zukünftig optional sein können [43] und ein JSON-Mapping unterstützen [44]. Damit wird es dann auch möglich, Mengen komplexer Typen zu haben [45].

Ausblick

Bis zum geplanten Erscheinen von .NET 10.0 im November 2025 werden noch fünf weitere Preview-Versionen und zwei Release-Candidate-Versionen erscheinen, über die ich selbstverständlich auch berichten werde.

Frequently Asked Questions (FAQ)

1. Wann erschienen .NET 10.0 Preview 1 und Preview 2, und was sind die nächsten Schritte?

Preview 1 wurde am 25. Februar 2025 veröffentlicht, gefolgt von Preview 2 am 18. März 2025. .NET 10.0 soll voraussichtlich im November 2025 als LTS-Version erscheinen, mit insgesamt fünf weiteren Preview-Versionen und zwei Release Candidates.

2. Wie setzt man .NET 10.0 und neue Sprachfeatures ein?

Um neue Sprachfeatures zu verwenden, muss das Target-Framework auf net10.0 gestellt und in der Projektdatei zusätzlich <LangVersion>preview</LangVersion> gesetzt werden. Außerdem ist Visual Studio 2022 Version 17.14 Preview 2 erforderlich.

3. Welche nützlichen Sprachfeatures kommen mit C# 14.0?

• Von nameof() mit generischen Typen können nun Typparameter weggelassen werden (z. B. nameof(List<>)).

• Lambda-Ausdrücke erlauben nun Parameter-Modifizierer wie scoped, ref, in, out, _ref readonly, ohne explizite Typphase.

• Neue automatische Konvertierungen zwischen Arrays, Span<T> und ReadOnlySpan<T>, z. B. Developer[] → Span<Developer>.

• Das neue Schlüsselwort field unterstützt semi-automatische Properties („Semi-Auto Properties“).

• Partielle Konstruktoren und Events werden als partial gekennzeichnet, sind aktuell aber noch nicht voll funktionsfähig (Debugger/Compiler-Unterstützung geplant ab VS 17.4 Preview 3).

4. Welche Verbesserungen gibt es in der Basisklassenbibliothek (BCL)?

• SDK: Vereinheitlichung der dotnet CLI-Kommandos (z. B. dotnet package add statt dotnet add package).

• Workload Sets sind nun Standard beim .NET SDK, mit besserem Package-Restore.

• LINQ-Erweiterungen: Einfache Nutzung von LeftJoin() und RightJoin() statt zuvor komplexer Konstrukte.

• OrderedDictionary<T,T> bekommt neue Overloads: TryAdd(key, value, out index) und TryGetValue(key, out value, out index).

• System.Net: IPAddress.IsValid() ergänzt TryParse() zur leichteren IP-Prüfung.

• Certificate APIs: ExportPkcs12() für sichereren PKCS#12-Export – noch nicht vollständig verfügbar; X509Certificate2Collection erhält FindByThumbprint().

• ISOWeek-Klasse: Neue Methoden für DateOnly-Verarbeitung (z. B. GetWeekOfYear()).

• ZIP-Performance optimiert: Deutlich geringerer RAM-Verbrauch (z. B. 2 GB → 7 KB) und deutlich schneller.

5. Welche neuen Features gibt es in .NET MAUI?

• ShadowTypeConverter: Definieren von Schatten vereinfacht durch kurze Syntax (Shadow="4 4 16 #000000 0.5").

• Farbsteuerung: Bei Switch kann nun OffColor und bei SearchBar die Symbolfarbe über SearchIconColor gesteuert werden.

• TextToSpeech: Sprachgeschwindigkeit (Rate) jetzt einstellbar (z. B. Rate = 2.0f).

• Android-Support: JDK 21 und neue API-Level automatisch (empfohlen ab API 24); Steuerung per dotnet run -p:AdbTarget=….

• Apple-Plattformen (iOS, macOS, tvOS): Automatische Trimmer-Warnungen, optional abschaltbar in der Projektdatei.

6. Was ändert sich bei ASP.NET Core und OpenAPI?

• OpenAPI Specification wird nun standardmäßig in Version 3.1 unterstützt (zuvor 3.0) – bringt Breaking Changes.

• OpenAPI-Ausgabe kann jetzt auch im YAML-Format generiert werden.

• XML-Kommentare lassen sich in OpenAPI-Dokumente einbinden – aktiviert über Projektdatei.

• Response-Beschreibungen: Annotations wie [ProducesResponseType(..., Description="…")] erscheinen nun im OpenAPI-Dokument.

7. Welche Blazor-Verbesserungen gibt es in der Vorschau?

• ReconnectModal.razor erlaubt Anpassung der UI bei Verbindungsabbrüchen (Blazor Server).

• NavigateTo() behält nun Scrollposition – Sprung nur bei forceLoad = true oder Pfadänderung.

• QuickGrid: Zeilenklassen per Funktion setzen; CloseColumnOptionsAsync() schließt Filtereingaben automatisiert.

• Fingerprinting von JS-Datei verhindert Cache-Probleme.

Links & Literatur

[1] https://dotnet.microsoft.com/en-us/download/dotnet/10.0

[2] https://github.com/dotnet/csharplang/issues/7905

[3] https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-14

[4] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview2/csharp.md#partial-events-and-constructors

[5] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/partial-events-and-constructors

[6] https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md

[7] https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/10.0/default-workload-config

[8] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/sdk.md

[9] https://github.com/dotnet/runtime/issues/111282

[10] https://github.com/dotnet/core/blob/main/releasenotes/10.0/preview/preview2/libraries.md#encryption-algorithm-can-now-be-specified-in-pkcs12pfx-export

[11] https://github.com/dotnet/runtime/issues/80314

[12] https://github.com/dotnet/runtime/releases/tag/v10.0.0-preview.2.25163.2

[13] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/libraries.md#ziparchive-performance-and-memory-improvements

[14] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/winforms.md

[15] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/wpf.md

[16] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview2/wpf.md

[17] https://json-schema.org/specification-links#2020-12

[18] https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-10.0?view=aspnetcore-9.0#openapi-31-breaking-changes

[19] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview2/aspnetcore.md#populate-xml-doc-comments-into-openapi-document

[20] https://github.com/dotnet/efcore/issues/12793

[21] https://github.com/dotnet/efcore/issues/35367

[22] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/dotnetmaui.md

[23] https://learn.microsoft.com/en-us/dotnet/core/compatibility/10.0

[24] https://learn.microsoft.com/en-us/dotnet/api/

[25] https://devblogs.microsoft.com/dotnet/dotnet-10-preview-1

[26] https://devblogs.microsoft.com/dotnet/dotnet-10-preview-2

[27] https://github.com/dotnet/announcements/issues

[28] https://github.com/dotnet/announcements/issues/344

[29] https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/efcore.md

[30] https://github.com/dotnet/aspnetcore/issues/60003

[31] https://apireview.net

[32] https://www.youtube.com/@NETFoundation/streams

[33] https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md

[34] https://github.com/dotnet/aspnetcore/issues/59443

[35] https://github.com/dotnet/aspnetcore/issues/51202

[36] https://github.com/dotnet/aspnetcore/issues/46349

[37] https://github.com/dotnet/aspnetcore/issues/26794

[38] https://github.com/dotnet/aspnetcore/issues/30344

[39] https://github.com/dotnet/maui/wiki/Roadmap

[40] https://github.com/dotnet/winforms/blob/main/docs/roadmap.md

[41] https://github.com/dotnet/wpf/blob/main/roadmap.md

[42] https://github.com/dotnet/efcore/milestone/204

[43] https://github.com/dotnet/efcore/issues/31376

[44] https://github.com/dotnet/efcore/issues/31252

[45] https://github.com/dotnet/efcore/issues/31237

The post Was bringt .NET 10.0? Erste Einblicke in Preview 1 & 2 appeared first on BASTA!.

In diesem Artikel werden wir uns zunächst mit den theoretischen Grundlagen von KI-Agenten und agentenbasierten Systemen befassen. Anschließend folgt eine praxisnahe Einführung in die Entwicklung eigener KI-Agenten mit dem Semantic Kernel. Ziel ist es, ein tiefgehendes Verständnis für die Konzepte zu vermitteln und gleichzeitig eine praktische Anleitung bereitzustellen, mit der Entwickler:innen eigene Projekte umsetzen können.

Zeitachse und Entwicklung

Frühe 2000er: Traditionelle Workflow-Engines

In den frühen 2000ern wurde die Automatisierung weitgehend von Workflow-Engines wie Nintex, Windows Workflow Foundation, IBM WebSphere Process Server und BizTalk Server dominiert. Diese Tools ermöglichten es Unternehmen erstmals, Geschäftsprozesse ohne tiefgehende Programmierung zu automatisieren. Bekannte Merkmale waren:

• Workflow-Engines zeichneten sich durch starre, vordefinierte Logiken und Entscheidungsbäume aus.
• Entwickler:innen implementierten Automatisierungen mithilfe von if-then-else Bedingungen und regelbasierten Konfigurationen.
• Der Fokus lag auf wiederholbaren, strukturierten Aufgaben mit klar definierten Ergebnissen.
• Systeme waren wenig anpassungsfähig und erforderten umfangreiche Neukonfigurationen bei Prozessänderungen.

Diese Tools steigerten zwar die Effizienz in strukturierten Umgebungen, waren jedoch begrenzt in der Verarbeitung unstrukturierter Daten und der Anpassung an dynamische Geschäftsanforderungen.

Mitte der 2010er: Aufstieg von KI und maschinellem Lernen

Während regelbasierte Systeme in den frühen 2000ern dominierten, begann in den 2010ern eine neue Ära mit datengetriebenen Ansätzen. Mit dem zusätzlichen Aufkommen von maschinellem Lernen verlagerte sich der Fokus zu mehr automatisierter Entscheidungsfindung. Dies führte zu flexibleren und intelligenteren Automatisierungslösungen, die auf Mustern und Vorhersagen basierten. Wichtige Entwicklungen waren:

• _Einführung von prädiktiven Analysen:_Systeme begannen, Datenmuster zu nutzen, um Vorhersagen zu treffen und manuelle Eingriffe zu reduzieren (SAS Advanced Analytics, IBM SPSS Modeler, RapidMiner).
• _Übergang von regelbasierten zu lernbasierten Modellen:_KI-Anwendungen analysierten historische Daten und passten sich verändernden Bedingungen an (TensorFlow (2015), Microsoft Azure Machine Learning (2015), H2O.ai).
• _Frühe Anwendungen:_Betrugserkennung, Empfehlungssysteme und Prozessoptimierung (PayPal Fraud Detection, Amazon Recommendation Engine, Google RankBrain (2015)).
• Diese Veränderungen legten die Grundlage für eine intelligentere Automatisierung, jedoch wurde KI noch weitgehend als Ergänzung zu regelbasierten Workflows und nicht als eigenständige Entscheidungsinstanz genutzt (UiPath, Automation Anywhere, Blue Prism).

Frühe 2020er: Aufkommen von Generativer KI

Ende der 2010er Jahre erlebte die Welt den Aufstieg von Generativer KI, wie z. B. GPT, das bemerkenswerte Fähigkeiten im Verstehen und Generieren natürlicher Sprache zeigte. Mit der Fähigkeit, menschenähnliche Texte zu generieren und kontextbezogene Antworten zu liefern, wurde KI nicht mehr nur als unterstützendes Werkzeug, sondern als eigenständige Entscheidungsinstanz betrachtet. Hauptmerkmale sind:

• KI-Systeme wurden kontextbewusster und konnten menschenähnliche Texte verstehen und generieren.
• Generative KI weckte das Interesse an intelligenter Automatisierung, die über traditionelle Workflows hinausging.
• Anwendungen dehnten sich auf Chatbots, virtuelle Assistenten und KI-gestützte Inhaltserstellung aus.

Mit diesen Fortschritten wurde der Grundstein für KI-Agenten gelegt – autonome Systeme, die nicht nur Entscheidungen treffen, sondern auch aus Interaktionen lernen und sich kontinuierlich verbessern.

Gegenwart: KI-Agenten und agentenbasierte Systeme

Mit den kontinuierlichen Fortschritten in der KI stehen wir nun an der Schwelle zu Agenten-basierter Technologie – autonomen Entitäten, die ihre Umgebung wahrnehmen, Entscheidungen treffen und handeln, um bestimmte Ziele zu erreichen.

Beschreibung von KI-Agenten

Im Gegensatz zu herkömmlichen Workflows sind KI-Agenten in der Lage, unstrukturierte Daten zu verarbeiten und komplexe Entscheidungen zu treffen. Diese Agenten lernen aus Interaktionen und können, wenn implementiert, ihre Leistung kontinuierlich verbessern. KI-Agenten sind zielorientiert und passen ihr Verhalten dynamisch an neue Gegebenheiten an. Zur Optimierung ihrer Entscheidungsfähigkeit nutzen sie fortschrittliche Techniken wie Reinforcement Learning, selbstüberwachtes Lernen und tiefe neuronale Netze.

Abb. 1: AI-Ops-Agenten: Eine Gruppe von KI-Agenten, die Probleme am lokalen System angehen

KI-Agenten stellen einen Paradigmenwechsel dar – von statischer Automatisierung hin zu adaptiven, sich selbst verbessernden Systemen, die in dynamischen, realen Umgebungen funktionieren können (Abb. 1).

Agentenbasierte Systeme (oft auch agentische Systeme genannt) führen den Ansatz von KI-Agenten fort. Unter diesem Begriff versteht man das Skalieren der Fähigkeiten von KI-Agenten. Während KI-Agenten oftmals als eine Gruppe von Agenten bezeichnet werden, die ein bestimmtes Thema verarbeiten, übernehmen agentenbasierte Systeme die Orchestrierung über mehrere Gruppen von KI-Agenten, wodurch eine hohe Skalierbarkeit erreicht wird (Abb. 2).

Ein Beispiel: Während eine Gruppe von KI-Agenten nur in der Lage ist, auf die Frage „Warum ist mein Netzwerk so langsam?” zu antworten, nutzt ein agentisches System die Fähigkeiten ganzer Gruppen von KI-Agenten (Netzwerk, Application Monitoring, TicketSysteme, usw.), um ein komplexeres Problem zu lösen.

Abb. 2: Skalierbares Agentic-System

Grundlegende KI-Technologien für KI-Agenten

KI-Agenten verwenden Schlüsseltechnologien der Künstlichen Intelligenz zur Analyse von Daten, zum Verstehen von Sprache und zur Verarbeitung visueller Informationen. Machine Learning, eine Unterkategorie der Künstlichen Intelligenz, ermöglicht es KI-Agenten, Datenmuster zu erkennen und Vorhersagen oder Entscheidungen zu treffen, basierend auf gesammelten Erfahrungen. Dies führt zu folgenden Spezialisierungen:

• Neuronale Netze und Deep Learning: Von Gehirnstrukturen inspirierte neuronale Netze helfen KI-Agenten, komplexe Daten zu verstehen. Deep Learning nutzt mehrschichtige Netze für Aufgaben wie Bild- und Spracherkennung.
• _Natürliche Sprachverarbeitung (NLP):_NLP ermöglicht die Verständigung in menschlicher Sprache – wichtig für Chatbots, virtuelle Assistenten und automatisierte Systeme.
• _Computer Vision:_KI-Agenten interpretieren visuelle Daten und treffen Entscheidungen, hilfreich in Robotik, Qualitätskontrolle und Gesichtserkennung.
• _Reinforcement Learning:_Durch Belohnungssysteme lernen KI-Agenten optimale Entscheidungen zu treffen, besonders in dynamischen Umgebungen.
• _Transformermodelle und LLMs:_Transformermodelle, eine Architektur für neuronale Netze, ermöglichen eine effiziente Verarbeitung und Generierung von Texten. Sie bilden die Grundlage für LLMs, die anhand großer Mengen an Textdaten trainiert werden und fortschrittliche Sprachverarbeitung, Textverständnis und Generierung ermöglichen.

Von der Theorie zur Praxis: Eigenen KI-Agent erstellen

In diesem Abschnitt entwickeln wir einen eigenen KI-Agenten mit Semantic Kernel. Wir gehen dabei schrittweise vor und beginnen mit dem Erstellen eines Projektes.

Warum Semantic Kernel?

Es gibt mehrere Frameworks zur Entwicklung von KI-Agenten, darunter LangChain/-Graph, AutoGen/2 und Semantic Kernel (Kasten: „Hinweise zu Semantic Kernel”). Wir verwenden Semantic Kernel, da es speziell für .NET optimiert ist und eine einfache Integration mit Large Language Models (LLMs) ermöglicht. Zudem wird es aktiv von der Community und Microsoft weiterentwickelt, was eine langfristige Unterstützung und Verbesserungen sichert.

Hinweise zu Semantic Kernel

• Preview Status: Semantic Kernel ist noch in der Preview-Phase, wird aber aktiv weiterentwickelt.
• unterstützte Sprachen: Neben C# unterstützt Semantic Kernel auch Python und Java, was Entwicklern Flexibilität bietet.
• Fokus auf Sprachmodelle: Semantic Kernel eignet sich besonders für KI-Agenten, die auf LLMs basieren.

In den nächsten Schritten werden wir:

1. Ein .NET-Projekt erstellen
2. Semantic Kernel installieren
3. Einen einfachen KI-Agenten bauen
4. Ein Agenten-Team aufsetzen

Die Voraussetzungen dafür sind:

• _Technische Kenntnisse:_Erfahrung mit C#, .NET und Terminal-Befehlen
• Zugang zu einem LLM: Azure OpenAI, OpenAI API oder lokal gehostete Modelle mit Ollama oder LMStudio

Kurze Einführung in den Semantic Kernel

Semantic Kernel ist ein Framework, das als Middleware zwischen Anwendungen und LLMs fungiert. Es bietet eine Abstraktionsschicht, die es Entwickler:innen ermöglicht, KI-Funktionen einfach in ihre Software zu integrieren. Durch den modularen Aufbau können verschiedene KI-Modelle und Plug-ins flexibel kombiniert werden.

Wichtige Merkmale sind:

• Einfache Integration: Lässt sich nahtlos in bestehende .NET-Projekte einbinden.
• Modularität: Flexible Anpassung von KI-Komponenten an spezifische Anforderungen.
• Skalierbarkeit: Unterstützt den Einsatz in großen Umgebungen und verteilten Systemen.

Durch den Einsatz von Semantic Kernel können Entwickler:innen leistungsfähige KI-Agenten erstellen und ihre Anwendungen mit intelligenten Funktionen erweitern.

Schritt-für-Schritt-Anleitung: Integration des Semantic Kernel mit dem Agent-Framework

Wir beginnen mit der Einrichtung eines neuen Projekts, fügen die notwendigen Abhängigkeiten hinzu und konfigurieren den Zugriff auf ein LLM. Am Ende dieses Abschnitts hast du eine funktionierende Basis für deinen KI-Agenten.

Ein nützliches Beispiel: „AI Ops”

Ich plane ein Analyse-System für AI Ops, das generative KI zur automatisierten Lösung von IT-Tickets nutzt. Das Ziel ist es, dass KI-Agenten Problembeschreibungen analysieren und lösen. Diese Agenten benötigen Zugriff auf Netzwerk, CPU und Speicher. Es wird einen Analyse-Agent und einen Bewertungs-Agent im Team geben. Das System soll eigenständig Probleme und Lösungen auf Expertenniveau finden können (Abb. 1).

Projekt erstellen und Semantic Kernel installieren

Der erste Schritt ist das Anlegen eines .NET-Projektes nach diesem Schema:

dotnet new console -o MyAIAgenten
cd MyAIAgenten

Für die Installation und Arbeit mit dem Semantic-Kernel-Framework benötigst du folgende NuGet-Pakete:

dotnet add package microsoft.SemanticKernel
dotnet add package microsoft.semantickernel.Agenten.abstractions --version 1.35.0-alpha
dotnet add package microsoft.semantickernel.Agenten.core --version 1.35.0-alpha
dotnet add package microsoft.semantickernel.Agenten.openai --version 1.35.0-alpha

Zugang zu einem LLM

Um einen KI-Agenten zu erstellen, benötigst du Zugriff auf ein LLM. Es gibt viele Möglichkeiten – beispielsweise eine der folgenden drei:

1. Azure OpenAI: Erstelle einen Azure OpenAI-Service im Azure-Portal und notiere den API-Schlüssel.
2. OpenAI API: Registriere dich auf der OpenAI-Webseite und generiere einen API-Schlüssel.
3. Lokale Modelle: Nutze Ollama oder LMStudio für ein lokal gehostetes Modell.

Falls du LMStudio verwendest, beachte, dass Function Calling derzeit nicht unterstützt wird. Ich empfehle daher Ollama als Model-Host für Semantic Kernel.

Ich nutze für dieses Projekt den Azure OpenAI-Service, weshalb ich die nachfolgenden Schritte entsprechend darauf abgestimmt habe. Die API von OpenAI bedarf nur geringfügige Änderungen im Code, da beide Vorgehensweisen in Semantic Kernel nahezu identisch implementiert sind.

Umgebungsvariablen setzen

Um Informationen wie API-Schlüssel als Konfiguration zu hinterlegen, speichere ich diese in Umgebungsvariablen. So lässt sich das Projekt auch leicht in anderen Umgebungen wie Docker verschieben.

Nun ist es an der Zeit eine Datei namens .env im Projektverzeichnis zu erstellen und folgende Zeilen hinzuzufügen:

AZURE_OPENAI_API_KEY=<dein_api_schluessel>
AZURE_OPENAI_ENDPOINT=<dein_api_endpunkt>
AZURE_OPENAI_MODEL_ID=<dein_deployment_model>

Das Deployment-Modell ist der Name des Modells, das du in Azure OpenAI bereitgestellt hast.

Installiere als Nächstes das DotNetEnv-Paket, um die Umgebungsvariablen in deinem Code zu laden: dotnet add package DotNetEnv. Falls noch nicht geschehen, erstelle eine .gitignore und füge .env hinzu, um nicht versehentlich sensiblen Inhalt in deinem Git Repo zu speichern.

Nachdem wir Semantic Kernel in unser .NET-Projekt integriert haben, erstellen wir nun einen einfachen KI-Agenten, der mit einem LLM interagiert. Mit diesem Wissen können wir nun beginnen den Code zu schreiben.

Semantic Kernel initialisieren

Um Semantic Kernel einzurichten und mit einem LLM zu verbinden, passen wir die Program.cs an wie in Listing 1.

Listing 1: Program.cs

class Program
{
static async Task Main(string[] args)
{
<em>//Alternative zu appsettings.json..:</em>
DotNetEnv.Env.Load(); <em>// lade die Env Vars</em>
<em>// Kernel initialisieren</em>
var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
Environment.GetEnvironmentVariable("AZURE_OPENAI_MODEL_ID"),
Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT"),
Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY"));
var kernel = builder.Build();

<em>// Klon anlegen, um eine Netzwerk-F&#xE4;higkeit bereitzustellen</em>
var networkKernel = kernel.Clone();
var pluginNetwork = KernelPluginFactory
.CreateFromType<NetworkMonitor>();
networkKernel.Plugins.Add(pluginNetwork);

<em>// zweiter Kernel mit Host-Monitoring-F&#xE4;higkeit</em>
var hostMetricsKernel = kernel.Clone();
var pluginHost = KernelPluginFactory
.CreateFromType<HostMetrics>();
hostMetricsKernel.Plugins.Add(pluginHost);
<em>//&#x2026; weiterer Code &#x2013; ein</em> <em>wenig logging und weiteres house keeping</em>
}
}

Zuerst wird der KernelBuilder erstellt. Mit AddAzureOpenAIChatCompletion bekommt der Kernel die Fähigkeit, mit entsprechendem LLM zu interagieren. Für diejenigen, die sich für eine Implementierung mit OpenAIs API entschieden haben, würde die Funktion dann builder.AddOpenAIChatCompletion heißen.

Wir klonen den Kernel, um spezialisierte Funktionen durch Plugins hinzuzufügen – zum Beispiel Netzwerkchecks oder Host-Metriken. Das Klonen ermöglicht eine Trennung der Verantwortlichkeiten. Es verhindert, dass Agenten falsche Funktionen aufrufen. Ein Agent kann nur die im Kernel vorhandenen Plug-ins verwenden, um seine vorgesehenen Aufgaben zu erfüllen.

In unserem Beispiel haben wir einen Agenten, der Netzwerkchecks durchführen kann.

KernelPluginFactory.CreateFromType<NetworkMonitor>();
networkKernel.Plugins.Add(pluginNetwork);

Um das Plug-in besser verstehen zu können, möchte ich nachfolgend einen Auszug aus der Plug-in-Klasse zeigen.

Listing 2: Klasse NetworkMonitor

[KernelFunction()]
[Description("Returns information about the network adapters")]
public static List<string> adapterInfos()
{
List<string> adapterInfos = new List<string>();
foreach (NetworkInterface ni in NetworkInterface.GetAllNetworkInterfaces())
{
string info = $"Name: {ni.Name}, Typ: {ni.NetworkInterfaceType}, Status: {ni.OperationalStatus}";
adapterInfos.Add(info);
}
return adapterInfos;
}

Mit Semantic Kernel können wir Methoden mit speziellen Decorators versehen. KernelFunction stellt die Verbindung zwischen Semantic Kernel und der Methode her. Description hilft dem LLM, die Methode inhaltlich zu verstehen (Listing 2). Dies ermöglicht es dem LLM, gezielt Funktionen aufzurufen, ohne direkten Zugriff auf das System zu haben. Parameter können ebenfalls übergeben werden und sollten unbedingt in der Description mit beschrieben sein.

Das Konzept ist simpel: Bei der Lösungssuche, etwa bei der Überprüfung von Netzwerkadaptern, generiert das LLM einen Function Call auf ‘ adapterInfos()’. Diese Funktionsaufrufe sind entscheidend für die Verbindung zwischen LLM und lokalen Ressourcen (eine tiefere Diskussion darüber würde jedoch den Rahmen sprengen).

Kurz gesagt, durch Decorators im Semantic Kernel erstellt das LLM ein JSON, füllt es mit Werten und gibt es an den Semantic Kernel zurück. Das LLM hat dabei keinen direkten Zugriff auf das System.

Unser erster Agent

Nun definieren wir einen ersten KI-Agenten, der als Netzwerkanalyst fungiert (Listing 3).

Listing 3

ChatCompletionAgent agentNetworkChecker = new()
{
Name = nameNetworkChecker,
Instructions =
"""
**Role:** You are a Network Checker with over 10 years of experience. You specialize in diagnosing network connectivity issues.

<em><&#x2026; (gek&#xFC;rzt) Der Prompt definiert die Rolle des Agenten und enth&#xE4;lt Anweisungen zur Analyse von Netzwerkproblemen></em>
""",
Kernel = networkKernel,
Arguments = new KernelArguments(new AzureOpenAIPromptExecutionSettings() { FunctionChoiceBehavior = FunctionChoiceBehavior.Auto() }),
LoggerFactory = loggerFactory
};

Ein Agent benötigt mindestens Name, Instructions (Promp – textuelle Beschreibung der Aufgabe) und Kernel. Die Arguments-Konfiguration erlaubt es dem LLM, selbst zu entscheiden, ob es eine Plug-in-Funktion aufruft oder eine direkte Antwort generiert. Dieser Agent hier bekommt mit dem networkKernel Zugriff auf verschiedene netzwerknahe Implementierungen, also Plug-ins.

Der KI-Agent ist fertiggestellt. Jetzt fehlt nur noch der Aufruf des Agenten, um eine erste Interaktion zu starten (Listing 4).

Listing 4

<em>// erstelle ein ChatHistory object, um den Chatverlauf zu verwalten.</em>
ChatHistory chat = [];

<em>// F&#xFC;ge die User-Message hinzu</em>
chat.Add(new ChatMessageContent(AuthorRole.User, "<user input>"));

<em>// Generiere die Agent-Antwort(en)</em>
await foreach (ChatMessageContent response in agentNetworkChecker.InvokeAsync(chat))
{
<em>  //Verarbeite die Antwort(en)...</em>
}

Ein Agentensystem

Während ein einzelner KI-Agent bereits nützlich ist, entfaltet sich das volle Potenzial erst in einer Gruppe von Agenten. Hier arbeiten mehrere spezialisierte Agenten zusammen, um komplexe Aufgaben zu bewältigen. Für unser Analyseteam werden zusätzlich zum Network-Agent noch weitere Agenten benötigt, die ich hier nicht mehr detailliert aufführe. Das Grundprinzip bleibt jedoch gleich: Jeder Agent benötigt einen Namen, einen spezifischen Prompt und einen Kernel, der optional mit Plug-ins erweitert werden kann:

ChatCompletionAgent agentNetworkChecker = &#x2026; ; <em>// pr&#xFC;ft das Netzwerk</em>
ChatCompletionAgent agentCommonChecker = &#x2026; ; <em>// pr&#xFC;ft CPU, Storage, &#x2026;</em>
ChatCompletionAgent agentAnalyst = &#x2026; ; <em>// Analysiert die Ergebnisse der Agenten</em>
ChatCompletionAgent agentResolver = &#x2026; ; <em>// bewertet das Analyseergebnis</em>

Listing 5: GroupChat-Definition

AgentGroupChat groupChat =
new(agentAnalyst, agentNetworkChecker, agentResolver, agentCommonChecker)
{
ExecutionSettings = new()
{
SelectionStrategy = new KernelFunctionSelectionStrategy(selectionFct, kernel)
{
InitialAgent = agentAnalyst,
HistoryReducer = new ChatHistoryTruncationReducer(1),
HistoryVariableName = "lastmessage",
<em>//return the response from the current agent/or its name</em>
ResultParser = (result) =>{
var selection = result.GetValue<string>() ?? agentAnalyst.Name;
return selection;
}
},
TerminationStrategy = new KernelFunctionTerminationStrategy( terminationFct, kernel)
{
Agenten = new[] { agentResolver },
HistoryVariableName = "lastmessage",
HistoryReducer = new ChatHistoryTruncationReducer(1),<em>//last message</em>
MaximumIterations = 10, <em>// </em><em>maximum 10 rounds</em>
ResultParser = (recall) => <em>{//check agent response for presence of word &#x201C;YES&#x201D; </em>
var result =recall.GetValue<string>();
var yes = result?.ToLower().Contains("yes");
return yes ?? false;
}
}
}
};

Die SelectionStrategy legt fest, welcher Agent als nächstes antwortet. Dazu definieren wir Regeln, die sich an der letzten Nachricht orientieren (Listing 6).

Listing 6

KernelFunction selectionFct = AgentGroupChat.CreatePromptFunctionForStrategy(
$$$"""
**Task:** Determine which agent should act next based on the last response. Respond with **only** the agent's name from the list below. Do not add any explanations or extra text.

**Agenten:**

- {{{nameAnalyst}}}
- {{{nameNetworkChecker}}}
- {{{nameCommonChecker}}}
- {{{nameResolver}}}

**Selection Rules:**

- **If the last response is from the user:** Choose **{{{nameAnalyst}}} **.
- **If the last response is from {{{nameAnalyst}}}  and they are requesting network details:** Choose **{{{nameNetworkChecker}}}**.
- **If the last response is from {{{nameAnalyst}}}  and they are requesting non-network system checks:** Choose **{{{nameCommonChecker}}}**.
- **If the last response is from {{{nameAnalyst}}}  and they have provided an analysis report:** Choose **{{{nameResolver}}}**.
- **If the last response is from {{{nameNetworkChecker}}} or {{{nameCommonChecker}}}:** Choose **{{{{nameAnalyst}}} }**.
- **Never select the same agent who provided the last response.**

**Last Response:**

{{$lastmessage}}
""",
safeParameterNames: "lastmessage"
);

Die geschweiften Klammern {{{nameAnalyst}}} sind generell Platzhalter, die zur Laufzeit mit den tatsächlichen Agentennamen ersetzt werden. Das Muster {{{$}}} ist ein Platzhalter für Variableninhalte, die zur Laufzeit während des Chats eingefügt werden.

Hier ist es die Variable „ lastmessage“, die zuvor über das Feld HistoryVariableName der SelectionStrategy bekannt gemacht wurde. Beim Verwenden des Templates wird dort die ChatHistory vom Framework eingesetzt.

Die Zeile HistoryReducer = new ChatHistoryTruncationReducer(1) sorgt im Übrigen dafür, dass nur die letzte ChatMessage aus der Historie übergeben wird, da für die Selektion des nächsten Agenten ältere Nachrichten keine Relevanz haben. Zugleich spart dies Kosten, denn es reduziert die Anzahl der verwendeten Token, die derzeit die Währung der LLMs sind und mit der Länge des Texts in ihrer Menge steigen.

Die TerminationStrategy wird ähnlich wie die SelectionStrategy verwaltet. Sie legt fest, wann der Chat endet. Dazu wird das LLM angewiesen, eine Abschlussantwort zu geben, etwa „YES” oder „APPROVED”. Ein JSON-Schema erfasst diese Antwort strukturiert für die Automatisierungsprozesse. Zudem gibt es ein Fallback: Falls der Analyst ständig neue Details vom NetworkChecker anfordert und keine Entscheidung trifft, wird die Anzahl der Runden auf zehn begrenzt.

Unsere KI-Agenten sind nun vollständig – das Team kann Nachrichten verarbeiten, Entscheidungen treffen und den Chat sinnvoll beenden. Um unser Agenten-Team zu nutzen, fügen wir eine Nachricht hinzu und starten die asynchrone Verarbeitung. Die Antworten der Agenten werden dann in einer Schleife ausgegeben (Listing 7).

Listing 7

groupChat.AddChatMessage(new ChatMessageContent(AuthorRole.User, <User Input Nachricht>));
await foreach (ChatMessageContent response in groupChat.InvokeAsync())
{
Console.WriteLine($"{response.AuthorName.ToUpperInvariant()}:\n{response.Content}");
}

Mit diesem Konstrukt können wir diese KI-Agenten nun überall einbetten. Zum Beispiel in einem Support-Chatbot, einem automatisierten Incident-Management-System oder einer internen Analyse-Pipeline. In meinem GitHub-Projekt [1] findest du eine vollständige Implementierung mit einer interaktiven Schleife, in der Nutzer:innen direkt mit den Agenten kommunizieren können.

Fazit

KI-Agenten sind mehr als nur eine technologische Innovation – sie verändern die Art und Weise, wie wir Automatisierung und Entscheidungsfindung betrachten. Mit Semantic Kernel steht ein leistungsfähiges Werkzeug bereit, das es Entwickler:innen ermöglicht, intelligente Systeme zu bauen, die autonom zu einem gegebenen Problem nach einer Lösung suchen können.

Die Entwicklung in diesem Bereich schreitet rasant voran. Neue Modelle, verbesserte Orchestrierungsmechanismen und optimierte Agenten-Interaktionen werden in den kommenden Jahren die Möglichkeiten weiter ausbauen.

Links & Literatur

[1] https://github.com/totosan/tutorial-aiagents

The post KI-Agenten mit Semantic Kernel appeared first on BASTA!.

Dieser Kurs wird in Version 9 konsequent fortgesetzt. Unternehmen, die neue plattformübergreifende Apps entwickeln oder von Xamarin.Forms auf .NET MAUI umsteigen, profitieren gleichermaßen von einer stabilen Plattform, die sich auf Verlässlichkeit konzentriert. Gleichzeitig liefert .NET MAUI 9 sinnvolle Ergänzungen, die die Arbeit mit der Plattform vielseitiger und produktiver machen.

Quality first

Entwickler:innen lieben neue Features, doch genau diese lieferte Microsoft mit der neuen Version von .NET MAUI nur in sehr begrenztem Umfang. Stattdessen konzentrierte sich das Team fast ausschließlich auf die Fehlerbehebung. Dieser Fokus war essenziell, nicht nur, um den Anforderungen moderner Anwendungen gerecht zu werden, sondern vor allem, weil seit dem Supportende von Xamarin.Forms am 1. Mai 2024 immer mehr Unternehmen gezwungen sind, von Xamarin.Forms auf .NET MAUI umzusteigen. In dieser Situation sind Stabilität und Zuverlässigkeit entscheidend – Showstopper dürfen schlichtweg nicht auftreten.

Das Ergebnis dieser Strategie kann sich sehen lassen: Zwischen den Versionen 7 und 8 wurden insgesamt 689 Issues in 1 618 Pull Requests geschlossen. Von Version 8 auf 9 stiegen diese Zahlen auf über 2 800 geschlossene Issues und mehr als 1 900 Pull Requests. Die tatkräftige Unterstützung aus der Community hat diese beeindruckende Steigerung ermöglicht.. Nachdem zuvor Einzelpersonen Bugfixes zu Microsofts plattformübergreifendem Framework beigetragen hatten, beteiligte sich der Komponentenhersteller Syncfusion im Sommer dieses Jahres in großem Umfang am MAUI-Projekt. Allein zwischen dem 30. Juli und dem 1. Oktober stammte mehr als die Hälfte aller Community-Pull-Requests von Syncfusion-Mitarbeiter:innen.

Mit der TitleBar macht MAUI weiteres Land auf dem Desktop gut

Obwohl .NET MAUI als echtes Cross-Platform-Framework positioniert wird, das sich gleichermaßen für mobile Geräte und den Desktop eignet, wird es in der Community – ähnlich wie sein Vorgänger Xamarin.Forms – oft als reines Mobile-Framework wahrgenommen, das primär unter Android und iOS eingesetzt wird.

Um dieser Wahrnehmung entgegenzuwirken, hat Microsoft in den letzten Versionen von MAUI gezielt Desktopfeatures eingeführt. Funktionen wie Menüs, Kontextmenüs und Maus-Events haben den Desktop bereits gestärkt. Mit der aktuellen Version 9 kommt nun ein weiteres Feature für den Windows-Desktop hinzu: die TitleBar Control.

Dieses Steuerelement erlaubt es Entwickler:innen, die Titelleiste von Windows-Desktop-Anwendungen umfassend anzupassen. Wie bei modernen Office-Anwendungen kann die Titelleiste nun neben einem App-Icon und einem Titel auch einen Untertitel sowie drei separate Inhaltsbereiche enthalten. Diese bieten in den Bereichen LeadingContent, Content und TrailingContent Platz für interaktive Elemente wie Suchleisten, Buttons oder zusätzliche Icons, was die Titelleiste funktionaler und moderner macht.

Listing 1 zeigt die Definition einer TitleBar. Das Beispiel veranschaulicht, wie man Icons, eine Suchleiste und weitere Inhalte in die Titelleiste einfügen kann. Zusätzlich lassen sich Titel, Untertitel und das App-Icon individuell anpassen, um die Titelleiste an das Design Ihrer Anwendung anzupassen. Das Ergebnis ist in Abbildung 1 zu sehen.

<?xml version="1.0" encoding="utf-8" ?>
<Window xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
        xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
        x:Class="DontLetMeExpire.AppWindow">
  <Window.TitleBar>
    <TitleBar Title="Don't let me expire"
              Icon="logo.png" 
              Subtitle="Stop wasting food"
              HeightRequest="50">
      <TitleBar.LeadingContent>
        <Label Text="" VerticalOptions="Center"/>
      </TitleBar.LeadingContent>
      <TitleBar.Content>
        <SearchBar 
          Placeholder="Search" 
          MaximumWidthRequest="300" 
          MaximumHeightRequest="40"/>
      </TitleBar.Content>
      <TitleBar.TrailingContent>
        <Label Text="" VerticalOptions="Center"/>
      </TitleBar.TrailingContent>
    </TitleBar>
  </Window.TitleBar>
</Window>

Abb. 1: Das TitleBar-Steuerelement verleiht Windows-Apps ein modernes Design, das sich an Office-Anwendungen orientiert

Derzeit ist das TitleBar-Steuerelement ausschließlich für Windows verfügbar. Microsoft plant jedoch, die Unterstützung in einem zukünftigen Update auf Mac Catalyst zu erweitern. Damit würde das Steuerelement auch auf dem Mac verfügbar sein und zur plattformübergreifenden Konsistenz beitragen, was die Entwicklung von Desktop-Apps für mehrere Plattformen erheblich erleichtert.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

HybridWebView: Web trifft auf native App-Entwicklung

Das neue HybridWebView-Steuerelement in .NET MAUI 9 bietet die Möglichkeit, Webinhalte nahtlos in plattformübergreifende Anwendungen zu integrieren. Ursprünglich als experimentelles Projekt von Microsoft-Mitarbeiter Eilon Lipton gestartet [1], hat sich das Steuerelement in den letzten zwei Jahre zu einem vollwertigen Bestandteil des Frameworks entwickelt.

Während das klassische WebView-Steuerelement, das es bereits seit der ersten .NET-MAUI-Version und schon unter Xamarin gab, die Darstellung von Webinhalten wie HTML, CSS und JavaScript ermöglichte, geht HybridWebView einen Schritt weiter: Es erlaubt eine bidirektionale Kommunikation zwischen der Webansicht und der nativen App. Dadurch können Webtechnologien und native Funktionen optimal miteinander kombiniert werden.

HybridWebView ist eine ideale Wahl für hybride Anwendungen, die auf Frameworks wie Angular, React, Svelte oder Vue basieren. Anders als die Blazor-Integration über BlazorWebView, die ausschließlich auf das .NET-Ökosystem ausgelegt ist, ermöglicht HybridWebView die nahtlose Einbindung beliebiger Webframeworks. Bestehende Webanwendungen können einfach in den Ordner Resources\Raw\wwwroot kopiert werden. Da die Inhalte lokal bereitgestellt werden, ist keine Internetverbindung für die Ausführung erforderlich.

Für neue Projekte bietet sich HybridWebView besonders für Teams an, die sich stärker auf Webtechnologien wie HTML, CSS und JavaScript fokussieren und weniger Erfahrung oder Vorlieben in C# und XAML haben. Es erlaubt diesen Teams, ihre vorhandene Webexpertise zu nutzen, ohne dabei auf die Vorteile nativer Funktionen wie den Zugriff auf Gerätesensoren, Offlinefähigkeiten oder die tiefere Integration ins Betriebssystem verzichten zu müssen.

Darüber hinaus eignet sich HybridWebView perfekt für Szenarien, in denen bestehende HTML- und JavaScript-Anwendungen als App ausgeliefert und durch native Funktionen ergänzt werden sollen. Es schlägt eine Brücke zwischen der Flexibilität des Webs und der Leistungsfähigkeit nativer Apps – eine ideale Lösung für hybride Projekte, die das Beste aus beiden Welten verbinden möchten.

Das HybridWebView in der Praxis

Im folgenden Beispiel betrachten wir die Einbettung des HybridWebView-Steuerelements in eine .NET-MAUI-App sowie die bidirektionale Kommunikation zwischen der App und der eingebetteten Webanwendung.

In Listing 2 sehen wir die Definition einer einfachen Bildschirmmaske, die aus einem Eingabefeld, einem Button und einer HybridWebView besteht. Beim Klick auf den Button wird der Inhalt des Eingabefelds über die HybridWebView an die Webanwendung gesendet. Gleichzeitig sollen Nachrichten aus der Webanwendung empfangen und in der App verarbeitet werden können.

<Grid RowDefinitions="auto, *" ColumnDefinitions="*,auto">
  <!-- Eingabefeld für die Nachricht -->
  <Entry
    x:Name="messageText"
    Grid.Column="0"
    Placeholder="Bitte Nachricht eintragen" />

  <!-- Button zum Senden der Nachricht -->
  <Button
    Clicked="OnSendMessageButtonClicked"
    Grid.Column="1"
    Text="Senden" />

  <!-- HybridWebView für die Webansicht -->
  <HybridWebView
    x:Name="hybridWebView"
    Grid.Row="1"
    RawMessageReceived="OnHybridWebViewRawMessageReceived" />
</Grid>

Den zugehörigen C#-Code für die Interaktion sehen wir in Listing 3. Hier gibt es zwei zentrale Ereignisbehandlungsroutinen:

• OnSendMessageButtonClicked: Diese Methode ruft auf dem HybridWebView Control die Funktion SendRawMessage auf, um Nachrichten von der App an die Webanwendung zu senden.
• OnHybridWebViewRawMessageReceived: Diese Methode verarbeitet Nachrichten, die aus der Webanwendung empfangen werden, und zeigt sie in einem einfachen Dialogfenster an.

private void OnSendMessageButtonClicked(object sender, EventArgs e)
{
  hybridWebView.SendRawMessage(messageText.Text);
}

// Nachricht aus der Webansicht empfangen und anzeigen
private async void OnHybridWebViewRawMessageReceived(object sender, HybridWebViewRawMessageReceivedEventArgs e)
{
  await DisplayAlert("Nachricht empfangen", e.Message, "OK");
}

Damit die Kommunikation zwischen der nativen App und der Webanwendung funktioniert, muss der Webanwendung zusätzlicher JavaScript-Code hinzugefügt werden. Dieser stellt sicher, dass Nachrichten empfangen und gesendet werden können. Einen vollständigen Überblick über den benötigten Code findet man in der offiziellen .NET-MAUI-Dokumentation [2]. Listing 4 zeigt einen Auszug aus der Datei hybridwebview.js, die als Kommunikationsschnittstelle dient.

window.HybridWebView = {
  "Init": function Init() {
    function DispatchHybridWebViewMessage(message) {
      const event = new CustomEvent("HybridWebViewMessageReceived", { detail: { message: message } });
      window.dispatchEvent(event);
    }

    // Weitere Implementierung
  },

  "SendRawMessage": function SendRawMessage(message) {
    // Implementierung der Methode SendRawMessage
  },
};

window.HybridWebView.Init();

Die Kommunikation innerhalb der JavaScript-Anwendung mit der .NET-MAUI-App zeigen Listing 5 und Listing 6. In Listing 5 sehen wir den Empfang von Nachrichten in JavaScript aus .NET, während Listing 6 den Versand von Nachrichten aus JavaScript an .NET zeigt.

function receiveMessageFromMaui() {
  const hybridWebView = window.HybridWebView;
  if (hybridWebView) {
    window.addEventListener("HybridWebViewMessageReceived", (message) => {
      alert("Nachricht von der App: " + message);
    });
  }
}

const message = 'Hallo von JavaScript';
const hybridWebView = window.HybridWebView;
if (hybridWebView) {
  hybridWebView.SendRawMessage(message);
}

Der Beispielcode ist bewusst einfach gehalten. Er zeigt jedoch, wie leistungsfähig und gleichzeitig einfach die bidirektionale Kommunikation zwischen JavaScript und .NET MAUI mit dem HybridWebView-Steuerelement umgesetzt werden kann. In einer echten Anwendung könnte man problemlos die gesamte Benutzeroberfläche mit HTML und JavaScript realisieren und C# zur Interaktion mit der Hardware nutzen.

Überraschender Rückenwind für .NET MAUI: Das Open-Source-Toolkit von Syncfusion

Während die Veröffentlichung der TitleBar und des HybridWebView bereits längere Zeit vor dem offiziellen .NET-MAUI-9-Release bekannt waren, sorgte die Partnerschaft mit dem Komponentenhersteller Syncfusion für die größte Überraschung in der Community. Neben der aktiven Mitarbeit an Issues im .NET-MAUI-Repository entschied sich Syncfusion, über zehn Steuerelemente unter der Open-Source-MIT-Lizenz bereitzustellen. Die Liste der neuen Steuerelemente umfasst unter anderem:

• ein Chart Control mit mehreren Diagrammtypen
• ein Kalendersteuerelement mit anpassbaren Ansichten
• ein Bottom Sheet zum Einblenden zusätzlicher Inhalte
• eine Carousel View für touchfähige Galerien
• Diverse Steuerelemente zur Texteingabe, darunter ein Numeric Entry
• Buttons und Chips
• einen Navigation Drawer (seitliches Navigationsmenü)
• ein Tab Control
• visuelle Effekte wie Shimmer und Effects View für moderne UI-Elemente
• verschiedene weitere Steuerelemente

Viele Entwickler:innen dürften sich besonders über die Chart-Steuerelemente freuen. Die Visualisierung von Daten in Diagrammen ist ein gängiges und oft unverzichtbares Feature in modernen Apps. Da .NET MAUI bisher keine nativen Steuerelemente für diesen Zweck bereitstellte, waren Entwickler:innen  bislang häufig auf kommerzielle Bibliotheken angewiesen.

Eine detaillierte Vorstellung des Toolkits hat Tam Hanna bereits in seinem Artikel „Syncfusion Toolkit für .NET MAUI“ in der Ausgabe 2.2025 des Windows Developer vorgenommen [3]. Daher wird in diesem Artikel auf eine ausführliche Betrachtung inklusive Codebeispielen verzichtet. Stattdessen möchte ich die Steuerelemente in den Abbildungen 2 und 3 in Aktion zeigen. Abbildung 2 zeigt den Einsatz des Chart Controls, während Abbildung 3 das Shimmer Control demonstriert, eine moderne Form der Ladeanimation.

Abb. 2: Dank Syncfusion kann man nun auch Diagramme in .NET-MAUI-Apps anzeigen

Abb. 3: Mit dem Syncfusion Shimmer Control kann man Ladezeiten in Apps ansprechend überbrücken

Neue Projektvorlagen: Blazor Hybrid und Multi-Project-Apps

Eine auf den ersten Blick offensichtliche Neuerung von .NET MAUI 9 betrifft die Projektvorlagen. Mit .NET MAUI 9 wurden zwei neue Vorlagen eingeführt, die Entwickler:innen beim Start neuer Projekte zur Verfügung stehen. Abbildung 4 zeigt die beiden neuen Vorlagen .NET MAUI Blazor Hybrid and Web App und .NET MAUI Multi-Project App im Dialog zur Anlage eines neuen Projekts.

Abb. 4: .NET MAUI 9 bringt zwei neue Projektvorlagen mit

Die Vorlage .NET MAUI Blazor Hybrid and Web App richtet sich speziell an Entwickler:innen, die sowohl mit Blazor als auch mit MAUI arbeiten möchten. Sie ermöglicht es, Code für Webanwendungen und native MAUI-Apps gemeinsam zu nutzen. Die Projektstruktur umfasst ein .NET-MAUI-Projekt, ein oder zwei Blazor-Projekte und eine Razor-Klassenbibliothek mit der Endung .Shared (siehe Abbildung 5).

Abb. 5: Die Struktur einer „.NET MAUI Blazor Hybrid and Web App“ bringt eine Razor-Klassenbibliothek für gemeinsam genutzten Quellcode mit

In der Shared-Bibliothek befinden sich die gemeinsam genutzten Benutzeroberflächen in Razor, wie z. B. Counter.razor, Home.razor und Weather.razor. Sowohl das .NET-MAUI- als auch das Blazor-Projekt greifen auf diese geteilten Komponenten zu, wodurch sie sowohl im Webbrowser als auch in nativen Anwendungen angezeigt werden können. Abbildung 6 zeigt die Ausgabe einer solchen Anwendung – dargestellt im Webbrowser, auf Android und als Windows-Desktop-App.

Abb. 6: Mit Blazor kommt man sowohl ins Web als auch auf den Desktop und mobile Endgeräte

Die zweite neue Vorlage, .NET MAUI Multi-Project App, orientiert sich an einer traditionelleren Struktur und erinnert an das bekannte Modell aus Xamarin.Forms. Ein Projekt wird für den plattformübergreifenden Code angelegt, während für jede Zielplattform (z. B. Android, iOS oder Windows) ein separates Projekt erstellt wird (siehe Abbildung 7).

Abb. 7: Die Struktur einer „.NET MAUI Multi-Project App“ entspricht der traditionellen Xamarin.Forms-Projektstruktur

Diese Vorlage ist besonders für Entwickler:innen interessant, die von Xamarin.Forms auf MAUI migrieren und mit der Multi-Project-Struktur vertraut sind. Darüber hinaus kann sie in Projekten hilfreich sein, bei denen eine strikte Trennung zwischen Plattform- und plattformübergreifendem Code erforderlich ist. Für die Migration bestehender Xamarin.Forms-Anwendungen kann diese Vorlage ebenfalls Vorteile bieten, da die Struktur den Übergang erleichtert.

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Best Practices frei Haus

Eine weitere Neuerung in .NET MAUI 9 ist die Option Include Sample Content, die bei der Anlage eines neuen Projekts verfügbar ist. Diese Option erlaubt es Entwickler:innen, mit einer voll funktionsfähigen Beispielanwendung zu starten, anstatt von Grund auf neu beginnen zu müssen. Die Vorlage demonstriert einige Best Practices, wie den Einsatz des MVVM-Entwurfsmusters, Datenpersistenz per SQLite sowie den Einsatz des .NET MAUI Community Toolkits und der Syncfusion-Steuerelemente. Dank der sauberen Struktur, die Abbildung 8 zeigt, kann eine mit dieser Vorlage generierte App als interessantes Lernprojekt angesehen werden. Abbildung 9 zeigt die laufende App, die sowohl den Dark als auch den Light Mode unterstützt.

Abb. 8: Wählt man bei der Projektanlage die Option „Include sample content“ erhält man eine umfangreiche Beispielanwendung

Abb. 9: Die Beispielanwendung in Aktion

Weitere Neuerungen in .NET MAUI 9

Neben den neuen Steuerelementen und Projektvorlagen bringt .NET MAUI 9 auch einige kleinere, aber dennoch praktische Verbesserungen mit sich.

Eine dieser Neuerungen sind zwei optionale Handler für iOS und Mac Catalyst, die die Performance der CollectionView und der CarouselView verbessern. Diese neuen Handler können in der Datei MauiProgram.cs registriert werden, wie Listing 7 zeigt.

#if IOS || MACCATALYST
builder.ConfigureMauiHandlers(handlers =>
{
  handlers.AddHandler<Microsoft.Maui.Controls.CollectionView, Microsoft.Maui.Controls.Handlers.Items2.CollectionViewHandler2>();
  handlers.AddHandler<Microsoft.Maui.Controls.CarouselView, Microsoft.Maui.Controls.Handlers.Items2.CarouselViewHandler2>();
});
#endif

Eine weitere Verbesserung betrifft Eingabefelder: .NET MAUI 9 bietet eine erweiterte Unterstützung für die Eingabe von Datums- und Uhrzeitwerten sowie Passwörtern über die virtuelle Bildschirmtastatur.

Darüber hinaus unterstützt die neue Version nun Android 15 (API Level 35) und führt Android Asset Packs ein. Diese Erweiterung ist vor allem für Entwickler:innen von Spielen und datenintensiven Anwendungen interessant. Während die bisherige Größenbeschränkung von Google Play für Standardpakete bei 200 MB lag, erlauben Asset Packs das Hochladen von bis zu 2 GB großen Paketen. Diese Funktionalität bietet deutlich mehr Flexibilität bei der Entwicklung und Verteilung großer Apps und ist ein bedeutender Schritt für umfangreiche und speicherintensive Anwendungen.

Fazit

.NET MAUI 9 setzt weiterhin den Schwerpunkt auf Stabilität und Fehlerbehebung – ein entscheidender Faktor, insbesondere für Unternehmen, die bestehende Xamarin.Forms-Apps zu .NET MAUI migrieren müssen.

Auch wenn Microsoft selbst in diesem Release nur wenige neue Funktionen liefert, stechen die neuen Projektvorlagen hervor, die die Entwicklung für Web- und Desktopanwendungen gleichermaßen vereinfachen. Besonders die Option Include Sample Content, die Best Practices direkt integriert, erleichtert den Einstieg und bietet eine solide Grundlage für neue Projekte. Die Integration des HybridWebView und das TitleBar-Steuerelement zeigen zudem, wie MAUI sich zunehmend als echtes Cross-Platform-Framework etabliert – nicht nur für mobile Geräte, sondern auch für den Desktop.

Durch die Partnerschaft mit Syncfusion schließt .NET MAUI zudem wichtige Lücken, die Entwickler:innen bisher mit kommerziellen Bibliotheken füllen mussten.

Insgesamt bietet .NET MAUI 9 eine stabile und vielseitige Basis, die die plattformübergreifende App-Entwicklung effizienter und attraktiver macht.

Links & Literatur

[1] https://github.com/Eilon/MauiHybridWebView

[2] https://learn.microsoft.com/de-de/dotnet/maui/user-interface/controls/hybridwebview?view=net-maui-9.0#create-a-net-maui-hybridwebview-app

[3] https://entwickler.de/dotnet/syncfusion-toolkit-for-net-maui

The post .NET MAUI 9: Entdecken Sie die neuesten Funktionen und Verbesserungen appeared first on BASTA!.

Die wahrscheinlich am häufigsten eingesetzte Methode zum Testen von verteilter und komplexer Software am Entwicklungsrechner ist Docker Compose. Hierbei werden alle benötigten Komponenten in einer YAML-Datei konfiguriert und anschließend gemeinsam gestartet. Der Vorteil ist, dass diese YAML-Datei in Git eingecheckt wird und so einfach zwischen den Entwickler:innen geteilt werden kann. Diese Datei kann auch als Dokumentation dienen, da sie die Abhängigkeiten zwischen den Anwendungen beschreibt und festhält, welche Umgebungsvariable verwendet wird und welche Ports benötigt werden. Ein Beispiel dafür ist die Konfiguration des eigenen Frontends, eines API-Backends, einer Datenbank und eines Cache. Mit dem Befehl docker-compose up können alle Anwendungen gestartet und getestet werden. Der Nachteil dieser Lösung ist allerdings, dass die Anwendungen als Docker-Container laufen und nicht in einer Entwicklungsumgebung debuggt werden können.

Aus diesem Grund hat Microsoft im Jahr 2020 Project Tye [1] vorgestellt, um die Entwicklung und die Fehlersuche in verteilten Systemen zu vereinfachen. Die Idee war gut, die ersten Versionen vielversprechend. Leider fehlte jedoch der Fokus, um die gemeldeten Probleme zu beheben. Daher verlief sich Project Tye mit der Zeit und wurde schließlich 2023 archiviert. Project Tye wirkt auf den ersten Blick wie eine gute Idee, die zu einem grandiosen Fehlschlag wurde. Allerdings hat Microsoft aus den Fehlern und Problemen gelernt und hat zeitgleich mit der Einstellung von Project Tye .NET Aspire vorgestellt.

.NET Aspire wurde erstmals im November 2023 auf der .NET Conf vorgestellt und hat seitdem erhebliches Interesse geweckt. Seit seiner offiziellen Veröffentlichung im Mai 2024 ist es zu einem zentralen Thema auf jeder Entwicklerkonferenz geworden. Microsoft zeigt kontinuierlich sein Engagement für .NET Aspire durch regelmäßige Erweiterungen und Updates, die die Plattform ständig verbessern und Fehler beheben. Diese kontinuierliche Weiterentwicklung stellt sicher, dass .NET Aspire immer auf dem neuesten Stand der Technik ist und Entwickler:innen immer bessere Werkzeuge zur Verfügung stellt.

Entwickler:innen können .NET Aspire einfach zu bestehenden Projekten hinzufügen und damit Abhängigkeiten zwischen verschiedenen Komponenten konfigurieren. Der Vorteil gegenüber anderen Lösungen, wie zum Beispiel Docker Compose, ist, dass .NET Aspire als Code konfiguriert wird und so die Verwendung von IDEs zum Debuggen erlaubt. Nachdem Aspire zu einem Projekt hinzugefügt wurde, konfiguriert es das Sammeln von Logs, Metriken und Traces und stellt zusätzlich ein Dashboard zu Verfügung. Der oder die Entwickler:in muss sich dabei um nichts kümmern, hat aber die Möglichkeit, die Konfiguration den eigenen Anforderungen anzupassen. Zusätzlich können weitere Tools, zum Beispiel PostgreSQL, RabbitMQ oder Azure Service Bus über NuGet installiert und mit wenigen Zeilen Code konfiguriert werden.

Listing 1 zeigt die Konfiguration eines Aspire-Projekts. Dieses Projekt hat Redis und PostreSQL via NuGet installiert und ein Frontend, das beide referenziert. Zusätzlich wird PostgreSQL mit der Methode WithPgAdmin() konfiguriert, wodurch Aspire einen Container mit pgAdmin startet und diesen automatisch für den Zugriff auf den PostgreSQL-Server konfiguriert.

// Create a distributed application builder given the command line arguments.
var builder = DistributedApplication.CreateBuilder(args);

// Add a Redis server to the application.
var cache = builder.AddRedis("cache");

var postgres = builder.AddPostgres("database")
  .WithPgAdmin();

// Add the frontend project to the application and configure it to use the 
// Redis server, defined as a referenced dependency.
builder.AddProject<Projects.MyFrontend>("frontend")
       .WithReference(cache)
       .WithReference(postgres)
       .WaitFor(cache);

Zusätzlich zur verbesserten lokalen Entwicklung kann Aspire verwendet werden, um das Projekt schnell und einfach auf Azure zu deployen. Wie bei der Entwicklung übernimmt Aspire dabei die gesamte Konfiguration und kann mit wenigen Befehlen deployt werden.

In den folgenden Abschnitten wird die Funktionsweise von Aspire anhand einiger praktischer Demos gezeigt.

Voraussetzungen für .NET Aspire

Um Aspire verwenden zu können, werden die folgenden Tools benötigt:

• .NET 8.0 oder .NET 9.0  SDK
• .NET Aspire SDK
• eine OCI-compliant Container-Runtime, z. B. Docker Desktop oder Podman
• eine Entwicklungsumgebung, z. B. Visual Studio ab Version 2022 17.9 oder Visual Studio Code

.NET-Aspire-Projekte sind für die Ausführung in Containern konzipiert. Sie können entweder Docker Desktop oder Podman als Containerlaufzeit verwenden. Docker Desktop ist die am häufigsten verwendete Laufzeit. Podman ist eine Open-Source-Alternative zu Docker, die ohne Daemon auskommt und OCI-Container (Open Container Initiative) erstellen und ausführen kann. Wenn sowohl Docker als auch Podman installiert sind, verwendet .NET Aspire standardmäßig Docker. .NET Aspire kann mit der Umgebungsvariable DOTNET_ASPIRE_CONTAINER_RUNTIME konfiguriert werden, um stattdessen Podman zu verwenden (Listing 2).

# Windows
[System.Environment]::SetEnvironmentVariable("DOTNET_ASPIRE_CONTAINER_RUNTIME", "podman", "User")

# Linux
export DOTNET_ASPIRE_CONTAINER_RUNTIME=podman

.NET-Aspire-Demoprojekte von Microsoft

Nach der ganzen Theorie ist es jetzt Zeit für etwas Praktisches. Microsoft hat auf GitHub [2] ein Repository mit Demoprojekten für .NET Aspire veröffentlicht. Dieses Repository enthält unter anderem Beispiele für Aspire mit Azure Functions, Node.js oder Python. Diese Beispiele befinden sich im samples-Ordner des GitHub-Repositorys. Für diesen Artikel wird der Aspire-Shop verwendet.

Microsoft hat in der Vergangenheit schon öfter einen Onlineshop für Demos verwendet. Dieser konnte zwar via Docker Compose gestartet werden, war ansonsten aber aufgrund der Vielzahl an Services und Datenbanken recht kompliziert für neue Benutzer:innen. Aspire auf der anderen Seite bietet ein Dashboard mit allen gestarteten Containern und deren Status an. Dadurch müssen Entwickler:innen nicht mehr die Dokumentation oder Docker-Compose-Dateien durchsuchen, um die Ports und Pfade für die verschiedenen Container herauszufinden.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Nach dem Öffnen der Aspire-Shop-Solution sollte das AspireShop.AppHost-Projekt als Start-up-Projekt ausgewählt sein. Falls nicht, muss es als Start-up-Projekt konfiguriert werden; anschließend kann die Anwendung gestartet werden. Daraufhin öffnet sich das Aspire-Dashboard, welches eine Übersicht über alle Ressourcen im Projekt gibt und dessen Status bzw. Endpoints anzeigt. Abbildung 1 zeigt, dass einige Anwendungen schon gestartet sind, sowie zwei davon den Status „Unhealthy“ haben bzw. zwei noch nicht gestartet sind.

Abb. 1: Das Aspire-Dashboard zeigt den Status aller Anwendungen im Projekt

Je nach Internetgeschwindigkeit sollte es beim ersten Start wenige Minuten dauern, bis alle Container heruntergeladen und gestartet sind. Dann sollte der Status für alle Container „Running“ sein. Mit Hilfe der Endpoints kann jetzt ganz einfach durch die verschiedenen Anwendungen navigiert werden. So können zum Beispiel die Endpoints für das Swagger UI des Catalog Services, pgAdmin für Postgres oder das Frontend ganz einfach aufgerufen und ausprobiert werden.

Das Dashboard macht es neuen Entwickler:innen deutlich leichter, sich in einem Projekt zurecht zu finden. Zusätzlich bietet Aspire nützliche Informationen für das Monitoring und Debugging an. Auf der linken Seite im Dashboard kann so zwischen verschiedenen Ansichten für die Konsolenausgabe aller Container, Logs, Traces und Metriken gewechselt werden; zudem kann innerhalb dieser Ansichten gefiltert bzw. sortiert werden. Abbildung 2 zeigt, dass es mit Hilfe von OpenTelemetry eine Vielzahl von Metriken für den basketservice gibt, welche sowohl grafisch als auch als Tabelle angezeigt werden können.

Abb. 2: Das Aspire-Dashboard bietet eine Vielzahl von Metriken an

Vor allem verteilte Systeme sind dafür bekannt, unübersichtlich zu sein, wie auch dafür, dass die Fehlersuche für Entwickler:innen aufwendig und kompliziert sein kann. Hier ist Aspire sehr hilfreich, weil es OpenTelemetry, Health Checks und Service Discovery automatisch hinzufügt. Wie das genau funktioniert, sehen wir uns an einem bestehenden Blazor-Projekts an.

Hinzufügen von Aspire zu einem bestehenden Projekt

Aspire kann zu einem bestehenden Projekt mit Visual Studio, Visual Studio Code, JetBrains Rider oder via .NET CLI hinzugefügt werden. Für das .NET CLI kann der Befehl dotnet new aspire-servicedefaults -n ServiceDefaults verwendet werden. Allerdings müssen dann die Referenzen zu den bestehenden Projekten manuell hinzugefügt werden und das Aspire-Projekt muss per Hand konfiguriert werden.

Aus diesem Grund wird für diesen Abschnitt Visual Studio verwendet, um .NET Aspire zu einem bestehenden Blazor-Projekt mit dem Namen BlazorWithAspire hinzuzufügen. Grundsätzlich kann Aspire aber zu jedem .NET-Projekt ab .NET 8 hinzugefügt werden. Dazu klickt man mit der rechten Maustaste auf das Blazor-Projekt und wählt Add  | .NET Aspire Orchestrator Support aus. Dies generiert zwei neue Projekte, BlazorWithAspire.AppHost und BlazorWithAspire.ServiceDefaults.

Das AppHost-Projekt konfiguriert alle Projekte in der Programm.cs-Datei, die mit Aspire gestartet werden sollen. In diesem Fall ist es nur das BlazorWithAspire-Projekt:

var builder = DistributedApplication.CreateBuilder(args);
builder.AddProject<Projects.BlazorWithAspire>("blazorwithaspire");
builder.Build().Run();

Wenn während der Entwicklung neue Projekte erstellt werden, können diese hier hinzugefügt und konfiguriert werden.

Das zweite Aspire-Projekt, ServiceDefaults, ist im Moment wahrscheinlich das interessantere Projekt, um die Funktionsweise von Aspire zu verstehen. In diesem Projekt befindet sich eine Datei, Extensions.cs, die alle Aspire-Features konfiguriert, damit diese out of the box verwendet werden können. So werden zum Beispiel Health Checks, Metriken und Logs konfiguriert. Listing 3 zeigt einen Ausschnitt aus dieser Datei, in dem diverse Features wie OpenTelemetry und Service Discovery hinzugefügt werden.

builder.ConfigureOpenTelemetry();
builder.AddDefaultHealthChecks();
builder.Services.AddServiceDiscovery();
builder.Services.ConfigureHttpClientDefaults(http =>
  {
    // Turn on resilience by default
    http.AddStandardResilienceHandler();
    // Turn on service discovery by default
    http.AddServiceDiscovery();
});

In dieser Datei wird die ganze „Magie“ von .NET Aspire konfiguriert. Wenn das AppHost-Projekt jetzt gestartet wird, sollte sich das Aspire-Dashboard mit einer Anwendung öffnen. Zusätzlich können die Logs, Metriken und Traces der Anwendung angezeigt werden. Abbildung 3 zeigt die Dauer der Requests der Blazor-App an, ohne dass die Blazor-App dafür konfiguriert werden musste.

Abb. 3: .NET Aspire zeigt die Metriken der Blazor-App

Die Demo hat bis jetzt gezeigt, dass mit .NET Aspire zusätzliche Dienste wie Logs und Metriken zur Anwendung hinzugefügt werden können, ohne diese zu verändern. Ein weiterer interessanter Aspekt der Demo ist, dass sie zeigt, wie Aspire die konfigurierten Anwendungen startet. Im Abschnitt über den Onlineshop wurde erwähnt, dass es ein paar Minuten dauern kann, bis alle Container heruntergeladen und gestartet sind. Das ist zwar korrekt, könnte aber den Eindruck erwecken, dass alle Anwendungen als Container gestartet werden – .NET Aspire startet .NET-Anwendungen allerdings nicht als Container. Das kann ganz einfach mit dem docker ps-Befehl überprüft werden. Nachdem Aspire die Demo-Blazor-Anwendungen gestartet hat, zeigt docker ps aber keinen laufenden Container an. Der Grund dafür ist, dass Microsoft das Debugging für Entwickler:innen so einfach wie möglich machen möchte und deshalb die Anwendungen ohne Container startet.

Anwendungen mit Aspire schnell auf Azure deployen

Die vorangegangenen Abschnitte haben eine Einführung in .NET Aspire gegeben und aufgezeigt, wie damit der Entwicklungsprozess vereinfacht werden kann. Aspire kann aber auch beim Deployment der gesamten Umgebung auf Azure helfen.

Dafür wird zusätzlich zu den bereits installierten Tools noch die Azure Developer CLI [3] benötigt. Mit dieser kann die Anwendung einfach in eine oder mehrere Azure-Container-Apps deployed werden. Das Developer CLI und Aspire sorgen dafür, dass alle benötigten Ressourcen erstellt und konfiguriert werden. So kann zum Beispiel, je nach Konfiguration des eigenen Projekts, ein Azure Key zum Speichern von sensitiven Daten wie Passwörtern oder Connection Strings gespeichert werden oder eine PostgresSQL-Datenbank erstellt werden. Die Entwickler:in muss sich dabei um nichts selbst kümmern.

Eine weitere Möglichkeit, .NET Aspire kennenzulernen, ist die .NET Aspire Starter App-Vorlage. Diese Vorlage erstellt ein Blazor-Frontend, ein API, optional ein Testprojekt mit .NET Aspire. Abbildung 4 zeigt, dass beim Erstellen des Projekts in Visual Studio Redis zum Projekt hinzugefügt werden kann. Aspire kümmert sich dabei um die Integration und Konfiguration von Redis.

Abb. 4: Aspire kann automatisch Redis zum Projekt hinzufügen und konfigurieren

Die Vorlage erstellt eine Blazor-Anwendung mit einem Frontend, API-Backend und Redis. Die Program.cs-Datei im AppHost-Projekt konfiguriert, dass das Frontend das API und Redis verwendet; zusätzlich wird das Frontend mit dem Parameter WithExternalHttpEndpoints() konfiguriert. Dieser Parameter ist für das Deployment nützlich, da nur das Frontend einen öffentlichen URL bekommt und das Backend und Redis nicht über das Internet erreichbar sein sollen. Listing 4 zeigt die gesamte Program.cs-Datei.

var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache");

var apiService = builder.AddProject<Projects.BlazorWithAspireForAzure_ApiService>("apiservice");

builder.AddProject<Projects.BlazorWithAspireForAzure_Web>("webfrontend")
  .WithExternalHttpEndpoints()
  .WithReference(cache)
  .WaitFor(cache)
  .WithReference(apiService)
  .WaitFor(apiService);

builder.Build().Run();

Zum Testen der Anwendung kann sie gestartet und im Frontend die verschiedenen Menüpunkte aufgerufen werden. Diese Aufrufe sieht man auch im Aspire-Dashboard im Bereich Traces. Abbildung 5 zeigt zum Beispiel, dass der weather Endpoint vom Frontend aufgerufen wurde, dieser weatherforcast auf dem API aufgerufen und dann Daten in Redis geschrieben hat.

Abb. 5: Die Trace zeigt den Request vom Frontend an das Backend und Redis

Nachdem die Anwendung getestet ist, kann sie mit dem Azure Developer CLI deployt werden. Zunächst kann mit dem Befehl azd auth login in der Kommandozeile im zuvor angelegten Projekt das Log-in durchgeführt werden; anschließend wird mit azd init der Deployment Wizard gestartet. Das Deployment für diese Demo wurde mit den folgenden Angaben konfiguriert:

• Use code in the current directory: Dieser Befehl scannt den aktuellen Ordner nach Projekten und listet diese auf.
• Confirm and continue initializing my app: Wenn das CLI das richtige Projekt gefunden hat, kann mit diesem Projekt der Wizard fortgesetzt werden.
• Aspire-Demo: Als letzter Schritt muss ein Name für die Ressource-Gruppe angegeben werden, in die die Anwendung später deployt wird. Diese Ressource-Gruppe wird beim Deployment ebenfalls erstellt.

Nachdem der Name für die Ressource-Gruppe eingegeben ist, erstellt das Developer CLI zwei Dateien: azure.yaml und next-steps.md. Die Datei azure.yaml beinhaltet den Pfad zum zuvor konfigurierten Projekt; die next-steps.md-Datei gibt eine detaillierte Anleitung, wie die Anwendung deployt werden kann und bietet zusätzlich Links zur Dokumentation für weitere Informationen an. Abbildung 6 und Abbildung 7 zeigen das Konsolenfenster, in dem die Demoanwendung mit dem Azure Developer CLI konfiguriert wurde.

Abb. 6: Das Azure Developer CLI listet das Demoprojekt auf

Abb. 7: Das Azure Developer CLI erstellt die Deployment-Dateien

Der letzte Befehl für das Deployment ist azd up. Dieser Befehl erstellt alle benötigten Ressourcen in Azure, bevor die Demoanwendung deployt wird. Mit den Befehlen azd provision und azd deploy kann das Deployment auf zwei Schritte aufgeteilt werden. Nach der Eingabe des azd provision-Befehls (und auch nach der Eingabe von azd up) muss die gewünschte Azure Subscription und Region angegeben werden. Danach erstellt das CLI die benötigten Ressourcen, wie in Abbildung 8 gezeigt. Das Developer CLI verwendet Bicep-Skripte [4] für das Deployment. Dadurch können Änderungen ganz einfach mit denselben Befehlen deployt werden, und Bicep aktualisiert nur die angepassten Ressourcen.

Abb. 8: Alle benötigten Azure-Ressourcen wurden mit dem Azure Developer CLI automatisch erstellt

Folgende Ressourcen wurden erstellt:

• Ressource-Gruppe: Diese Gruppe beinhaltet alle Ressourcen.
• Container-Registry: In diese Registry werden die Container hochgeladen, die für die Azure-Container-Apps verwendet werden.
• Log Analytics Workspace: Alle Logs und Metriken werden im Workspace gespeichert und können dort durchsucht und angezeigt werden.
• Container-Apps-Environment: Vereinfacht gesagt handelt es sich hierbei um einen Behälter, in dem eine oder mehrere Container-Apps erstellt werden können. Alle Container in dieser Umgebung können untereinander kommunizieren.
• Managed Identity (wird nicht in der Konsole in Abbildung 8 angezeigt): Die Managed Identity wird von den Container-Apps verwendet und wurde berechtigt, um die Images aus der Container-Registry herunterzuladen.

SIE LIEBEN AZURE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Nachdem die Ressourcen angelegt wurden, kann die Anwendung mit azd deploy deployt werden. Dieser Befehl scannt das Aspire-Projekt, erstellt für alle Anwendungen einen Container und lädt diese Container in die Container-Registry hoch.

Abb. 9: Die Anwendungen und das Aspire-Dashboard wurden deployed

Abbildung 9 zeigt, dass Frontend, API-Backend, Redis und Aspire-Dashboard deployt wurden. Das Backend und Redis haben ein internal in der URL, das Frontend hat das allerdings nicht. Aspire weiß aufgrund der Konfiguration der Anwendungen, welche Container über das Internet erreichbar sein sollen und welche nicht. In der Demo-App wurde nur das Frontend mit dem zuvor beschriebenen WithExternalHttpEndpoints()-Parameter konfiguriert, wodurch nur dieser Container eine öffentliche URL bekommt. Aspire deployt auch das Aspire-Dashboard, welches fast genau wie in der lokalen Umgebung genutzt werden kann. Der einzige Unterschied zwischen der lokalen und der Azure-Instanz ist, dass für das Aufrufen des Azure-Dashboards ein Log-in benötigt wird. Aspire integriert automatisch das Log-in mit Entra in das Dashboard, wodurch nur User im Azure Tenant Zugriff auf die Anwendung haben.

Abb. 10: Das Aspire-Dashboard ist in Azure deployt

Abbildung 10 zeigt das Dashboard nach dem Log-in in Azure. Was dabei auffällt, ist, dass alle Endpoints via HTTPS aufgerufen werden können. Das ist ein nützliches Feature der Azure-Container-Apps. Alle Container-Apps werden mit einem automatisch erstellten TLS-Zertifikate erstellt und verwenden HTTPS, ohne dass die Entwickler:in etwas konfigurieren muss. Abbildung 11 zeigt die zuvor erstellten Ressourcen und die Container-Apps im Azure Portal.

Abb. 11: Alle erstellten Ressourcen im Azure Portal

Im Azure Portal sieht man auch die Konfiguration der einzelnen Container-Apps. Abbildung 12 zeigt die Umgebungsvariablen des Frontends.

Abb. 12: Die Umgebungsvariablen des Frontends wurden automatisch konfiguriert

Hier sind zum Beispiel die Endpoints der Redis- und Backend-Container konfiguriert, wie auch der Connection String für Redis. Hier sieht man zudem, dass sensitive Daten, zum Beispiel der Connection String, als Secret referenziert werden.

Das letzte interessante Feature des Deployments ist das Erstellen der Container für Frontend und Backend. Etwas weiter oben wurde die Azure-Container-Registry erwähnt, welche die Container-Images für die Container-Apps beinhaltet. Während der Entwicklung oder des Deployments wurde aber kein Dockerfile oder Ähnliches konfiguriert, um die Images zu erstellen. Um die Container-Images ohne Dockerfiles zu erstellen, nutzt Aspire ein .NET-Feature, das mit .NET 8 eingeführt wurde [5]. Seit .NET 8 kann das .NET SDK Docker Images erstellen, ohne dass dafür ein Dockerfile benötigt wird. Das erlaubt das einfache und schnelle Deployment des Aspire-Projekts.

Wenn die Ressourcen nicht mehr benötigt werden, können sie mit dem Befehl azd down gelöscht werden. Das Azure Developer CLI listet alle Ressourcen auf; nachdem das Löschen bestätigt ist, wird die gesamte Ressource-Gruppe gelöscht. Das dauert normalerweise nur wenige Minuten. Abbildung 13 zeigt aber, dass es manchmal auch etwas länger dauern kann.

Abb. 13: Die gesamte Umgebung wurde gelöscht

Migration von Docker Compose zu .NET Aspire

Viele Projekte verwenden für die Konfiguration der Abhängigkeiten während der Entwicklung Docker Compose. Diese Abhängigkeiten können eine Datenbank, Redis oder eine Queue wie etwa RabbitMQ sein, welche einfach mit einem Befehl gestartet werden können. Dadurch müssen sich vor allem neue Entwickler:innen nicht um die Konfiguration aller Komponenten kümmern und können so schnell produktiv im Projekt mitarbeiten.

Da .NET Aspire deutlich mehr Funktionalität als Docker Compose mitbringt, ist es empfehlenswert, bei neuen Projekten auf Aspire anstatt Docker Compose zu setzen. Für bestehende Projekte kann sich eine Migration von Docker Compose auszahlen, da diese oft recht schnell und einfach durchgeführt werden kann. Das größte Hindernis für eine Migration ist, dass Aspire externe Komponenten via NuGet-Paket einbindet. Sollte es noch kein NuGet-Paket für das gewünschte Tool geben, kann dieses derzeit nicht mit Aspire konfiguriert werden.

Um eine Migration von Docker Compose zu .NET Aspire zu demonstrieren, wird die zuvor erstellte Anwendung verwendet und ein fiktives Beispiel erstellt, in dem diese Anwendung neben Frontend und Backend auch PostgreSQL als Datenbank, Redis als Cache und RabbitMQ als Queue verwendet. Alle externen Komponenten werden in diesem fiktiven Beispiel in Docker Compose konfiguriert und an die Container der Blazor-Anwendung angehängt.

Wie bereits zuvor beschrieben kann einem bestehenden Projekt .NET Aspire (mit einem Rechtsklick auf das Webprojekt; dann mit Add  | .NET Aspire Orchestrator Support) hinzugefügt werden. Das erstellt zwei neue Projekte: Projektname.AppHost und Projektname.ServiceDefaults. In der Program.cs-Datei des AppHost-Projekts wird Aspire konfiguriert. Diese Datei sollte in etwa wie in Listing 4 aussehen. Nun können die benötigten externen Komponenten über NuGet-Pakete installiert werden. In Visual Studio kann dazu mit der rechten Maustaste auf das AppHost-Projekt geklickt werden und unter Add | .NET Aspire package ausgewählt werden. Alternativ kann auch das NuGet-Menü geöffnet und dort nach Aspire gesucht werden. Abbildung 14 zeigt, dass es bereits eine Vielzahl NuGet-Pakete für .NET Aspire gibt und diese die unterschiedlichsten Technologien unterstützen. So gibt es zum Beispiel NuGet-Pakete für SQL Server, Azure Key Vault, MongoDB und auch für AWS.

Abb. 14: Aspire bietet eine Vielzahl von NuGet-Paketen an

Für diese Demo werden die Redis, PostgreSQL und RabbitMQ Pakete installiert. Anschließend müssen diese noch in der Program.cs-Datei im AppHost-Projekt konfiguriert werden.

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var postgres = builder.AddPostgres("database")
  .WithDataVolume()
  .WithPgAdmin();

var rabbitMq = builder.AddRabbitMQ("rabbitMq")
  .WithManagementPlugin();

var apiService = builder.AddProject<Projects.BlazorWithAspireForAzure_ApiService>("apiservice")
  .WithReference(postgres)
  .WithReference(rabbitMq);

builder.AddProject<Projects.BlazorWithAspireForAzure_Web>("webfrontend")
  .WithExternalHttpEndpoints()
  .WithReference(cache)
  .WaitFor(cache)
  .WithReference(apiService)
  .WithReference(postgres)
  .WithReference(rabbitMq)
  .WaitFor(apiService);

builder.Build().Run();

Listing 5 zeigt die vollständige Program.cs-Datei, in der Frontend und API konfiguriert sind, sowie Redis, PostgreSQL und RabbitMQ hinzugefügt wurden. Redis wird mit der Methode AddRedis hinzugefügt und in einer Variable gespeichert. Diese Variable wird im Frontend referenziert, damit das Frontend auf Redis zugreifen kann; zusätzlich wartet das Frontend, bis Redis verfügbar ist.

Als nächstes wird PostgreSQL mit der Methode AddPostgres erstellt. Diese Methode verwendet die Erweiterungen WithDataVolume() und WithPgAdmin(). Mit dem Volume kann die Datenbank persistiert werden und bleibt dadurch beim Neustart der Container bestehen. Die PgAdmin-Methode konfiguriert das Management-Tool pgAdmin, damit die PostgreSQL-Datenbank mit einem UI verwaltet werden kann.

Zuletzt wird RabbitMQ mit der Methode AddRabbitMQ hinzugefügt und im Frontend sowie im API referenziert. Damit können beide Anwendungen auf RabbitMQ zugreifen und Nachrichten verschicken und empfangen. RabbitMQ bietet auch die Erweiterungsmethode, WithManagementPlugin(), wodurch automatisch das Management-UI von RabbitMQ konfiguriert wird und auch im Aspire-Dashboard angezeigt wird.

Wenn die AppHost-Anwendung jetzt gestartet wird, sollten nach dem Herunterladen der Container alle Anwendungen laufen. Abbildung 15 zeigt das Aspire-Dashboard mit dem Frontend und dem API sowie allen zuvor konfigurierten Tools inklusiver der Management-UIs.

Abb. 15: Das Aspire-Dashboard mit allen konfigurierten Tools

Das RabbitMQ-Management-UI fehlt in dieser Auflistung, weil es ein Teil von RabbitMQ ist und daher unter dem URL für RabbitMQ aufgerufen werden kann. Beim ersten Aufruf des Management-UIs werden Benutzername und Passwort benötigt. Diese können aus den Umgebungsvariablen des RabbitMQ-Containers ausgelesen werden. Es ist generell zu empfehlen, sich durch die Umgebungsvariablen der verschiedenen Anwendungen zu klicken, um einen besseren Einblick in die Konfiguration zu bekommen.

.NET Aspire kann aber nicht nur durch NuGet-Pakete erweitert werden, es kann auch durch die Implementierung der Aspire-Features erweitert werden. Die Konfiguration dazu befindet sich im ServiceDefaults-Projekt. Dort kann zum Beispiel das Logging oder das Tracing um weitere Datenquellen erweitert werden. In .NET wird mit RabbitMQ oft MassTransit [5] als Tracing-Tool verwendet. Dieses kann einfach als neue Quelle im Tracing hinzugefügt werden, wodurch alle MassTransit-Traces ebenfalls im Aspire-Dashboard angezeigt werden können. Die Implementierungsdetails dazu würden hier allerdings den Rahmen sprengen.

Fazit

.NET Aspire ist ein neues Tool von Microsoft, das Entwickler:innen bei der Entwicklung und Fehlersuche in komplexen Systemen unterstützen soll. Dazu bringt es viele nützliche Features wie Logging, Tracing und ein Dashboard mit, das ohne Konfiguration der Entwickler:innen funktionieren. Bei Bedarf kann das Verhalten dieser Tools aber auch an die eigenen Anforderungen angepasst werden. Zusätzlich kann gemeinsam mit dem Azure Developer CLI ein Aspire-Projekt mit wenigen Befehlen in die Cloud deployt werden.

Obwohl .NET Aspire erst vor einigen Monaten erschienen ist, ist es bereits so umfangreich, dass dieser Artikel nur einen kleinen Einblick in den vollen Funktionsumfang geben konnte. Die Zukunft sieht ebenfalls positiv aus, da laufend neue Features hinzukommen und Microsoft seinen Fokus auf das Projekt gelegt hat.

Links & Literatur

[1] https://devblogs.microsoft.com/dotnet/introducing-project-tye/

[2] https://github.com/dotnet/aspire-samples

[3] https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/install-azd

[4] https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep

[5] https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container

[6] https://masstransit.io

The post Meistern Sie .NET Aspire: Effektive Tools für Entwickler appeared first on BASTA!.

1. Benutzerführung und Intuitivität: Ein gut strukturiertes Layout leitet Benutzer:innen intuitiv durch die App. Durch die gezielte Platzierung von Navigationselementen, Buttons und Inhalten können Benutzer:innen mühelos und ohne Verwirrung navigieren, was die Verweildauer und Zufriedenheit steigert.
2. Responsivität und Zugänglichkeit: Web-Apps müssen auf verschiedenen Geräten und Bildschirmgrößen funktionieren. Ein responsives Layout, das sich dynamisch anpasst, stellt sicher, dass die App sowohl auf mobilen Geräten als auch auf großen Bildschirmen gut aussieht und einfach zu bedienen ist. Zudem trägt ein zugängliches Layout dazu bei, dass auch Nutzende mit Einschränkungen ein uneingeschränktes Erlebnis genießen können.
3. Leistung und Ladezeiten: Effiziente Layoutstrukturen sind optimiert für schnelle Ladezeiten und Performance. Eine schlanke, gut strukturierte Layoutarchitektur reduziert den Ressourcenverbrauch und beschleunigt das Rendering – das sind wichtige Faktoren für die Benutzerzufriedenheit, insbesondere in mobilen Umgebungen.
4. Konsistenz und Wiederverwendbarkeit: Ein konsistentes Layoutdesign fördert die Wiedererkennung und erleichtert die Entwicklung. In Blazor können Layoutkomponenten modular aufgebaut und wiederverwendet werden, was nicht nur die Entwicklungszeit verkürzt, sondern auch für ein einheitliches Erscheinungsbild in der gesamten Anwendung sorgt.
5. Flexibilität und Skalierbarkeit: Die Anforderungen an eine Web-App ändern sich oft im Laufe der Zeit. Ein flexibles Layoutdesign erleichtert es, Änderungen oder Erweiterungen vorzunehmen, ohne die gesamte Struktur zu überarbeiten. Durch den modularen Aufbau in Blazor können Layouts leicht angepasst und skaliert werden, um neue Funktionen oder Inhalte zu integrieren.

In diesem Artikel geht es um die technische Umsetzung von Layouts in Web-Apps mit Hilfe des Blazor Frameworks.

Layoutoptionen

Die verschiedenen Layoutoptionen bieten Nutzer:innen eine flexible und effiziente Möglichkeit, die Struktur und Benutzerführung von Webapplikationen gezielt zu gestalten. Eine erste Übersicht ist in Tabelle 1 zu sehen. 

Tabelle 1: Layoutoptionen in der Web-App

Layouts in Blazor

Layouts ermöglichen es, konsistente Strukturen für Seiten zu definieren und gemeinsame Elemente wie Navigation, Kopf- und Fußzeilen zentral zu verwalten. Ein Layout in Blazor ist eine spezielle Razor-Komponente, die als Vorlage für andere Komponenten dient. Diese Layoutkomponenten erben von der Klasse LayoutComponentBase und definieren eine Body-Eigenschaft, die einen Platzhalter für den Inhalt der untergeordneten Komponenten darstellt. Als erstes analysieren wir dazu den Quellcode einer Blazor-App (Web-App), die wir auf der Basis des gleichnamigen Templates generieren. Verantwortlich ist die Datei (Komponente) MainLayout.razor, die man im Ordner Components/Layout findet (Listing 1, Abb. 1).

@inherits LayoutComponentBase
<div class="page">
  <div class="sidebar">
    <NavMenu />
  </div>

  <main>
    <div class="top-row px-4">
      <a href="https://learn.microsoft.com/aspnet/core/" target="_blank">About</a>
    </div>

    <article class="content px-4">
      @Body
    </article>
  </main>
</div>

<div id="blazor-error-ui">
  An unhandled error has occurred.
  <a href="" class="reload">Reload</a>
  <a class="dismiss">🗙</a>
</div>

Abb. 1: Layout (Seitennavigation mit Menü) in einer Blazor-App (Template)

Sehen wir uns diese Komponente zunächst etwas genauer an:

• Vererbung von LayoutComponentBase: Die Layoutkomponente erbt von der Basisklasse LayoutComponentBase, die in Blazor speziell für Layouts verwendet wird. Diese Basisklasse stellt die Body-Eigenschaft bereit, die als Platzhalter für den Inhalt der untergeordneten Komponente dient, die dieses Layout verwendet.
• HTML-Grundstruktur: Das Haupt-<div> mit der CSS-Klasse “page” umfasst das Layout und bildet den äußeren Rahmen der Benutzeroberfläche.

• Sidebar: Der Bereich <div class=”sidebar”> enthält die Komponente <NavMenu />, die typischerweise als Navigationsmenü fungiert. Die Sidebar bleibt innerhalb des Layouts fest verankert und bietet Nutzer:innen eine konsistente Navigation durch die Applikation.

• Hauptinhalt (main): Innerhalb des <main>-Elements gibt es zwei zentrale Bereiche: Das Element mit der Klassenzuweisung “top-row” am Anfang des Hauptinhaltsbereichs enthält einen Link zur ASP.NET-Core-Dokumentation und wird durch eine CSS-Klasse (“px-4”) „gepolstert“, was den Inhalt innen um vier Einheiten Abstand versetzt. Dieser Bereich könnte für weitere Links oder Informationen genutzt werden. Der Artikelbereich mit der Klasse “content px-4” enthält die @Body-Direktive. Diese Direktive stellt den Bereich dar, in dem der spezifische Inhalt der untergeordneten Komponente gerendert wird, die das Layout verwendet. Hier werden also die Hauptinhalte der jeweiligen Seite angezeigt, die von der Sidebar unabhängig sind.

• Fehleranzeige (blazor-error-ui): Am Ende des Layouts befindet sich ein <div> mit der ID “blazor-error-ui”, das nur sichtbar wird, wenn ein unerwarteter Fehler auftritt. Dieser Bereich enthält: 
  • eine Fehlermeldung („An unhandled error has occurred.“) 
  • einen Reload-Link, der die Seite neu lädt
  • ein Schließen-Symbol (🗙) zum Ausblenden der Fehlermeldung

Dieses Layout bietet eine klare Struktur und ermöglicht eine flexible Gestaltung, da verschiedene Seiten das gleiche Layout nutzen können. Die Navigation und die Fehlerverarbeitung werden über die gesamte Anwendung hinweg vereinheitlicht.

SIE WOLLEN MEHR INPUT ZUM THEMA WEB DEVELOPMENT?

Entdecken Sie den BASTA! Web Development Track

Mehr erfahren

Viele Blazor-Entwickler:innen sind höchstwahrscheinlich über die Programmiersprache C# zur Webentwicklung mit Blazor gestoßen. Daher lohnt sich ein vertiefender Blick auf die Möglichkeiten des semantischen HTML, denn es bietet einen klaren Vorteil für die Strukturierung und Benutzerfreundlichkeit von Webanwendungen und wir nutzen diese HTML-Elemente in Blazor-Anwendungen. Webprofis können diesen Abschnitt getrost überspringen.

Exkurs: Semantisches HTML – Struktur und Bedeutung

In HTML5 ist die semantische Strukturierung ein wichtiger Aspekt, um die Benutzerfreundlichkeit, Zugänglichkeit und Übersichtlichkeit von Webseiten zu verbessern. Semantisches HTML bedeutet, dass Inhalte so strukturiert und mit Tags ausgezeichnet werden, dass ihre Funktion und Bedeutung im Kontext der Webseite klar erkennbar sind. Dies hilft nicht nur Entwickler:innen und Nutzer:innen, sondern auch Suchmaschinen und Screenreadern, den Inhalt korrekt zu interpretieren. Ein HTML-Dokument sollte nicht lediglich nacheinander mit Inhalten gefüllt werden, sondern eine klare Struktur und Hierarchie aufweisen. Mit den HTML-Tags lassen sich Webseiten logisch gliedern und erleichtern es Nutzer:innen, sich auf der Seite zurechtzufinden. Die wichtigsten HTML-Tags zur Strukturierung sind die folgenden:

• <body>: Der <body>-Tag stellt den darstellbaren Inhaltsbereich des HTML-Dokuments dar. Alle Inhalte der Seite, die sichtbar sein sollen, werden innerhalb dieses Tags organisiert.
• <nav>: Das <nav>-Element dient der Kennzeichnung von Navigationselementen einer Seite. Es enthält oft Links und Menüs zur Hauptnavigation der Seite. Da Seiten mehrere Navigationselemente enthalten können, sollte <nav> gezielt für die Hauptnavigation eingesetzt werden.
• <section>: Mit <section> können Seiten in zusammenhängende inhaltliche Abschnitte aufgeteilt werden. Ein typisches Beispiel sind Abschnitte für „News“ oder „Services“. Verschachtelte Sections sind möglich und helfen, die Gliederung der Seite zu verfeinern.
• <article>: Das <article>-Tag dient der Kennzeichnung in sich geschlossener Inhalte, die auch eigenständig bestehen könnten, wie Blogartikel oder Kommentare. Oft werden <section>- und <article>-Tags kombiniert, um die Seite hierarchisch zu gliedern.
• <aside>: Das <aside>-Tag wird verwendet, um zusätzliche Informationen wie Seitenleisten oder ergänzende Inhalte anzuzeigen. Diese Inhalte sind oft mit dem Hauptinhalt verwandt, aber nicht zwingend erforderlich.
• Überschriftenelemente (<h1> bis <h6>): HTML unterstützt die semantische Gliederung von Überschriften von <h1> bis <h6>. Innerhalb der Strukturtags wie <section>, <article>, <aside> und <nav> beginnt die Zählung der Überschriftenebenen neu.
• <header>: Das <header>-Tag kennzeichnet den Kopfbereich einer Seite oder eines Abschnitts und kann Überschriften, Logos oder Navigationslinks enthalten.
• <footer>: Im <footer>-Tag werden Informationen für den Fußbereich der Seite gesammelt. Typische Inhalte sind Urheberrechtshinweise und Kontaktinformationen.
• <address>: Das <address>-Tag gibt Kontaktinformationen zum Autor des Inhalts an und wird oft im <footer> verwendet. In Browsern wird es meist kursiv dargestellt.
• <main>: Mit <main> wird der zentrale Inhalt der Seite ausgezeichnet. Dieses Element sollte nur einmal pro Dokument vorkommen und ersetzt <div id=”main”>, um den Hauptinhalt der Seite semantisch zu kennzeichnen.

Die Verwendung dieser HTML5-Elemente zur Strukturierung verleiht Webseiten eine klare und bedeutungsgerechte Gliederung, was mehrere Vorteile mit sich bringt: Screenreader und andere Assistenztechnologien können die Struktur besser interpretieren, was sehbehinderten Nutzer:innen zugutekommt. Suchmaschinen verstehen durch semantische Tags die Bedeutung und Struktur des Inhalts besser, was die Indexierung und Auffindbarkeit der Seite verbessern kann. Klare Strukturen erleichtern die Wartung und Erweiterung des Codes, da die Bedeutung der einzelnen Bereiche sofort ersichtlich ist. Ein Beispiel für eine HTML5-Struktur mit semantischen Tags finden Sie in Listing 2 und Abb. 2.

<!DOCTYPE html>
<head>
  …
  <link rel="stylesheet" type="text/css" href="css/style.css">
</head>
<body>
  <header>
    <h1>Die Überschrift</h1>
  </header>
  <nav>
    <a href="#">Link</a>
    <a href="#">Link</a>
    <a href="#">Link</a>
  </nav>
  <main>
    <div class="column side">
      <p>Der linke Bereich der Seite</p>
      <p>
        Lorem ipsum ….
      </p>
    </div>
    <div class="column middle">
      <p>Der mittlere Bereich der Seite</p>
      <p>
        Lorem ipsum ….
      </p>
    </div>
    <div class="column side">
      <p>Der rechte Bereich der Seite</p>
      <p>
        Lorem ipsum ….
      </p>
    </div>
  </main>
  <footer>
    Hier kommt zum Beispiel das Impressum.
  </footer>
</body>
</html>

Abb. 2: Typisches Layout einer Web-App, realisiert mit semantischem HTML

Wenn Sie diese Elemente in einem HTML5-Dokument verwenden, können Sie die inhaltliche Struktur des Dokumentes festlegen. Beachten Sie jedoch zwingend: Der Browser wird das eine oder andere Element bereits in irgendeiner Form angepasst darstellen, zum Beispiel werden Inhalte in <address> kursiv ausgegeben. Die eigentliche Festlegung des Layouts und des Designs erfolgt jedoch in CSS, in dem man dann die Tagelemente konkret anspricht und diese mit dem entsprechenden CSS-Styling und Design versieht. Kommen wir jetzt wieder zurück zu Blazor.

Nav-Komponente

Innerhalb der Layoutkomponente haben wir die Navigation (<Nav/>-Komponente) integriert, die im Blazor-Kontext des Templates als Sidebar oder Top-Navigationsleiste dient (Listing 3). Diese Navigationsleiste ermöglicht eine strukturierte und konsistente Navigation durch die Hauptbereiche der Anwendung.

<div class="top-row ps-3 navbar navbar-dark">
  <div class="container-fluid">
    <a class="navbar-brand" href="">BlazorApp1</a>
  </div>
</div>

<input type="checkbox" title="Navigation menu" class="navbar-toggler" />

<div class="nav-scrollable" onclick="document.querySelector('.navbar-toggler').click()">
  <nav class="flex-column">
    <div class="nav-item px-3">
      <NavLink class="nav-link" href="" Match="NavLinkMatch.All">
        <span class="bi bi-house-door-fill-nav-menu" aria-hidden="true"></span> Home
      </NavLink>
    </div>
    <div class="nav-item px-3">
      <NavLink class="nav-link" href="counter">
        <span class="bi bi-plus-square-fill-nav-menu" aria-hidden="true"></span> Counter
      </NavLink>
    </div>
    <div class="nav-item px-3">
      <NavLink class="nav-link" href="weather">
        <span class="bi bi-list-nested-nav-menu" aria-hidden="true"></span> Weather
      </NavLink>
    </div>
  </nav>
</div>

Schauen wir uns den Aufbau und das Zusammenspiel der verschiedenen Teile der Navigation an. Der Navigationsbereich enthält mehrere Elemente, die zusammen eine responsive und funktionale Sidebar erzeugen:

<div class="top-row ps-3 navbar navbar-dark">
  <div class="container-fluid">
    <a class="navbar-brand" href="proxy.php?url=">BlazorApp1</a>
  </div>
</div>

Dieser Abschnitt definiert den obersten Bereich der Navigation. Er enthält die “navbar-brand”-CSS-Klasse, die als Logo oder Markennamen dient (“BlazorApp1”). Das “navbar”– und “navbar-dark”-Klassenset bringt den Stil der Bootstrap-Navigationsleiste ein und sorgt für ein abgedunkeltes Farbschema. Mit folgendem Beispiel wird ein checkbox-Element definiert, das als Hamburgermenü fungiert:

<input type="checkbox" title="Navigation menu" class="navbar-toggler" />

Beim Anklicken, beispielsweise auf Mobilgeräten, wird das Menü ein- und ausgeblendet. Das title-Attribut verleiht dem Toggle-Button eine beschreibende Bezeichnung, die für Screenreader und eine universelle Zugänglichkeit wichtig ist. Kommen wir zum Nav-Container (scrollbarer Bereich):

<div class="nav-scrollable" onclick="document.querySelector('.navbar-toggler').click()">
  <nav class="flex-column">

Der Bereich nav-scrollable ist ein Container für die Navigation, der vertikales Scrollen unterstützt. Durch das onclick-Event im div wird das Menü ein- oder ausgeblendet, wenn Benutzer.innen auf den Bereich klicken. Das ermöglicht eine einfache Bedienung der Sidebar. Die einzelnen Navigationselemente werden durch <NavLink>-Komponenten definiert, die von Blazor bereitgestellt werden. Jedes <NavLink> ist mit einer Route der Anwendung verknüpft und wechselt den Zustand basierend auf dem aktuellen URL. Der Code:

<div class="nav-item px-3">
  <NavLink class="nav-link" href="proxy.php?url=" Match="NavLinkMatch.All">
    <span class="bi bi-house-door-fill-nav-menu" aria-hidden="true"></span> Home
  </NavLink>
</div>

Die Klasse “nav-item” sorgt für einheitliche Abstände, während die Klasse “px-3” für ein horizontal gepolstertes Layout sorgt. Die “nav-link”-Klasse ist eine Standardklasse für Links in Bootstrap und wird hier verwendet, um den Navigationselementen ein einheitliches Styling zu verleihen. Jedes <NavLink>-Element enthält ein span-Element mit einer Bootstrap-Icon-Klasse (“bi bi-house-door-fill-nav-menu”). Das ermöglicht die Darstellung eines Icons neben dem Text. Das aria-hidden=”true”-Attribut stellt sicher, dass das Icon für Screenreader ignoriert wird, da es nur eine dekorative Funktion hat. Kommen wir als letztes zu den Seitenverlinkungen (href-Attribute). Die einzelnen href-Attribute definieren die Routen in der Blazor-Anwendung, zum Beispiel: `/` (Startseite), `/counter` (Counter-Seite) oder `/weather` (Weather-Seite). Jedes dieser Elemente wird durch ein Icon und eine Beschriftung ergänzt, um die Navigation für Benutzer:innen intuitiv zu gestalten. Die Hauptvorteile dieses Vorgehens sind:

• Responsivität: Die Kombination der Klassen “navbar-toggler” und “nav-scrollable” sorgt dafür, dass die Sidebar auf verschiedenen Geräten unterschiedlich dargestellt wird. Auf großen Bildschirmen bleibt die Sidebar sichtbar, während sie auf kleineren Bildschirmen durch das Hamburgermenü ein- und ausgeblendet werden kann.
• Interaktive Navigation mit <NavLink/>-Komponente: Blazor stellt sicher, dass die <NavLink/>-Komponente automatisch den Zustand „aktiv“ annimmt, wenn Benutzer:innen sich auf der entsprechenden Seite befinden. Das bietet visuelles Feedback und vereinfacht die Orientierung innerhalb der Anwendung.
• Trennung von Inhalt und Layout: Die Icons, Links und Navigationsstruktur sind klar in HTML5-CSS-Klassen organisiert, was die Benutzeroberfläche einfach anpassbar macht. CSS kann verwendet werden, um das Layout und Styling der Sidebar weiter zu individualisieren.

Zusammengefasst bietet dieses Layout eine gut strukturierte Navigation, die sich dynamisch anpasst, nutzerfreundlich ist und eine konsistente Navigation über die gesamte Blazor-App hinweg ermöglicht.

CSS-Definition des Layouts

Das Styling der Layoutkomponente erfolgt durch eine zugeordnete CSS-Datei, in der die visuelle Gestaltung der Navigation und des allgemeinen Layouts definiert wird. Diese CSS-Datei enthält die Stile für die verschiedenen Bereiche der Layoutkomponente, wie die Sidebar, das Hamburgermenü, den Hauptinhalt und den Footer. In der App auf der Basis des allgemeinen Templates wird die Definition in der Datei MainLayout.razor.css (Listing 4) vorgenommen.

.page {
  position: relative;
  display: flex;
  flex-direction: column;
}

main {
  flex: 1;
}

.sidebar {
  background-image: linear-gradient(180deg, rgb(5, 39, 103) 0%, #3a0647 70%);
}
…
#blazor-error-ui {
  background: lightyellow;
  bottom: 0;
  box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
  display: none;
  left: 0;
  padding: 0.6rem 1.25rem 0.7rem 1.25rem;
  position: fixed;
  width: 100%;
  z-index: 1000;
}

Zunächst erfolgt die Definition des grundlegenden Layoutcontainers:

.page {
  position: relative;
  display: flex;
  flex-direction: column;
}

Diese Klasse bildet den Hauptcontainer des Layouts und nutzt das Flexbox-Element aus CSS als Layoutmethode. Durch flex-direction: column werden die Elemente in .page vertikal angeordnet. Das position: relative stellt sicher, dass die Elemente innerhalb des Containers relativ zu .page positioniert werden können. Durch

main {
  flex: 1;
}

wird der Hauptinhalt so gestaltet, dass er den verbleibenden verfügbaren Platz im Container .page einnimmt. Dadurch passt sich der main-Bereich dynamisch an die Größe des Containers an und lässt Platz für andere fixierte oder flexible Elemente wie die Sidebar und den Header.

.sidebar {
  background-image: linear-gradient(180deg, rgb(5, 39, 103) 0%, #3a0647 70%);
}

Die Sidebar erhält durch einen linearen Farbverlauf (Gradient) eine attraktive Hintergrundfarbe, die von einem dunklen Blau (rgb(5, 39, 103)) oben in ein tiefes Violett (#3a0647) unten übergeht. Dieses visuelle Design hilft, die Sidebar als festen Bereich vom restlichen Inhalt abzuheben und eine ansprechende, moderne Optik zu erzeugen. Als letztes wird eine mögliche Fehlereinblendung der Blazor-App mit einem Layout versehen (Listing 5).

#blazor-error-ui {
  background: lightyellow;
  bottom: 0;
  box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
  display: none;
  left: 0;
  padding: 0.6rem 1.25rem 0.7rem 1.25rem;
  position: fixed;
  width: 100%;
  z-index: 1000;
}

• #blazor-error-ui: Dieser Bereich wird als Fehleranzeige verwendet, die standardmäßig ausgeblendet ist (display: none). Wenn ein Fehler auftritt, wird #blazor-error-ui sichtbar gemacht, sodass Nutzer:innen auf das Problem hingewiesen werden.
• Stil: Mittels background: lightyellow wird die hellgelbe Hintergrundfarbe definiert, die visuell eine Warnung oder einen Fehler symbolisiert; mit position: fixed platziert man das Element fest am unteren Rand des Bildschirms, unabhängig vom Seiteninhalt, sodass es stets sichtbar bleibt, wenn es eingeblendet ist; z-index: 1000 stellt sicher, dass die Fehleranzeige über anderen Inhalten liegt und mittels padding und box-shadow werden die Innenabstände und der Schatten der Fehleranzeige definiert. Es entsteht ein sauberes, abgesetztes Design, das ins Auge fällt und benutzerfreundlich bleibt.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Diese CSS-Definitionen (hier nur in Auszügen dargestellt und erläutert) legen die Grundstruktur und das Design der Blazor-Anwendung fest. Durch Flexbox und responsives Design wird ein flexibles Layout gewährleistet. Die Sidebar hebt sich durch ihren Farbverlauf ab, und die Fehleranzeige wird bei Bedarf hervorgehoben dargestellt. Studieren Sie die vollständige CSS-Datei in einer neuen Blazor-App, die sie auf einfache Art und Weise mit Hilfe des Assistenten in Visual Studio generieren lassen können.

Nutzung des Layouts in einer Komponente

In Blazor können Layouts auf verschiedene Arten auf Razor-Komponenten angewendet werden. Es bestehen die folgenden Optionen, um ein Layout für eine oder mehrere Komponenten festzulegen.

Nutzung eines Layouts durch die @layout-Direktive: Die einfachste Möglichkeit, einer Razor-Komponente ein Layout zuzuweisen, ist die Verwendung der @layout-Direktive direkt in der Komponente. Diese Methode ermöglicht eine individuelle Layoutzuweisung, die spezifisch für eine einzelne Komponente gilt. Ein einfaches Beispiel:

@page "/about"
@layout MainLayout
<h2>Über uns</h2>
<p>Willkommen auf der Über-uns-Seite.</p>

In diesem Beispiel wird der Komponente das Layout MainLayout zugewiesen, indem die @layout-Direktive verwendet wird. Der Inhalt der Razor-Komponente (hier: „Über uns“ und „Willkommen auf der Über-uns-Seite“) wird an der Stelle von @Body in MainLayout gerendert.

Nutzung eines Standard-Layouts für die gesamte Anwendung: Um ein Standardlayout für alle Razor-Komponenten festzulegen, können Sie das Layout in der <RouteView/>-Komponente der <Router/>-Komponente festlegen. Verwenden Sie den DefaultLayout-Parameter, um den Layouttyp festzulegen, üblicherweise in der Datei Routes.razor:

<Router AppAssembly="typeof(Program).Assembly">
  <Found Context="routeData">
    <RouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)" />
    <FocusOnNavigate RouteData="routeData" Selector="h1" />
  </Found>
</Router>

In diesem Beispiel wird MainLayout als Standardlayout festgelegt. Dadurch wird MainLayout automatisch auf alle Razor-Komponenten angewendet, die keine spezifische @layout-Direktive haben.

Nutzung eines Layouts für mehrere Komponenten eines Ordners: Für Razor-Komponenten innerhalb eines bestimmten Ordners kann ein Layout durch eine _Imports.razor-Datei festgelegt werden. Diese Datei wird auf alle Razor-Komponenten im gleichen Ordner und in dessen Unterordnern angewendet, sodass das Layout automatisch übernommen wird. Ein weiteres Beispiel: In der Datei _Imports.razor notieren wir folgende Anweisung:

@layout MainLayout

In diesem Fall wird MainLayout als Layout für alle Razor-Komponenten innerhalb des gleichen Ordners wie die _Imports.razor-Datei und in den Unterordnern verwendet. Diese Methode ist besonders nützlich, wenn Sie unterschiedliche Layouts für verschiedene Teile Ihrer Anwendung benötigen, beispielsweise ein Adminlayout für alle Komponenten im Admin-Ordner und ein Standardlayout für andere Bereiche.

Fassen wir zusammen: Die @layout-Direktive dient der Zuweisung eines Layouts in einer spezifischen Komponente; das Standardlayout definiert das Layout für die gesamte Anwendung und mittels der _Imports.razor-Datei legen wir das Layout für mehrere Komponenten in einem bestimmten Ordner fest. Diese verschiedenen Methoden ermöglichen es Ihnen, Layouts flexibel und übersichtlich in einer Blazor-Anwendung anzuwenden und zu organisieren.

Layoutmodifikation – klassisches Menü

Wenn Sie das Layout einer Blazor-Anwendung anpassen möchten, dann müssen Sie die Layoutkomponente modifizieren und beispielsweise eine Menüstruktur hinzufügen. Hier wird der Code so angepasst, dass eine Navigationsleiste erstellt wird, die als Hauptmenü dient. Die Modifikation des Standardlayouts erfolgt durch die Definition von Header, Navigation und Inhaltsbereichen. Der Quellcode in Listing 6 beschreibt eine typische Menüstruktur.

@inherits LayoutComponentBase
Layout1
<div class="header-nav">
  <nav class="navbar navbar-expand-lg bg-body-tertiary">
    <div class="container-fluid">
      <a class="navbar-brand" href="#">MyCompany</a>
      <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarNavAltMarkup" aria-controls="navbarNavAltMarkup" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>
      <div class="collapse navbar-collapse" id="navbarNavAltMarkup">
        <div class="navbar-nav">
          <NavLink class="nav-link active" href="/" Match="NavLinkMatch.All">Home</NavLink>
          <NavLink href="/weather" class="nav-link">Wetter</NavLink>
          <NavLink href="/counter" class="nav-link">Counter</NavLink>
        </div>
      </div>
    </div>
  </nav>
</div>
<div class="content px-4">
  @Body
</div>

Es folgt eine kompakte Erklärung der Komponenten und Modifikationen gegenüber der Ausgangssituation:

• Vererbung von LayoutComponentBase: Durch @inherits LayoutComponentBase wird festgelegt, dass die Komponente als Layout verwendet werden kann. Die @Body-Direktive wird verwendet, um den Inhalt der untergeordneten Komponenten an der gewünschten Stelle im Layout einzufügen.
• Header und Navigation: Der Header enthält die Hauptnavigation in Form einer <navbar/>-Komponente. Die Klasse “navbar navbar-expand-lg” sorgt dafür, dass die Navigationsleiste auf großen Bildschirmen horizontal dargestellt wird und auf kleineren Bildschirmen als zusammenklappbares (responsive) Menü erscheint. Die “bg-body-tertiary”-Klasse definiert den Hintergrundstil, und “container-fluid” sorgt dafür, dass die Inhalte der Navigation die volle Breite des Containers einnehmen.
• Markenname (MyCompany): Das Element <a class=”navbar-brand” href=”#”>MyCompany</a>` definiert den Markennamen oder das Logo in der Navigationsleiste.
• Hamburgermenü (für mobile Geräte): Der Button mit der Klasse “navbar-toggler” sorgt dafür, dass die Navigation auf kleineren Bildschirmen ein- und ausgeklappt werden kann.

• Navigationselemente (NavLink): Die “navbar-nav”-Klasse gruppiert alle Navigationslinks in der Navbar. Die <NavLink/>-Komponenten erzeugen Links, die je nach Route aktiviert werden. NavLink mit href=”/” navigiert zur Startseite und hat Match=”NavLinkMatch.All”, sodass es als aktiv markiert wird, wenn sich Benutzer:innen auf der Startseite befinden. Weitere Navigationselemente, wie /weather für die Wetterseite und /counter für die Counter-Seite, werden hinzugefügt, um eine einfache Benutzerführung zu gewährleisten.

• Inhaltsbereich (@Body): Der @Body-Platzhalter im <div class=”content px-4″>-Container definiert den Bereich, in dem die Inhalte der jeweiligen Seite gerendert werden. Die Klasse “px-4” fügt horizontale Innenabstände hinzu, um den Inhalt nicht direkt am Rand anzuzeigen und die Lesbarkeit zu verbessern.

Mit dieser Anpassung wird das Standardlayout um eine intuitive Menüstruktur erweitert (Abb. 3). Die Navigation ist klar strukturiert und passt sich automatisch an die Bildschirmgröße an, was das Layout flexibel und benutzerfreundlich macht.

Abb. 3: Layout einer Blazor-App mittels Menünavigation

Layoutmodifikation – Tabnavigation

Wenn Sie das Layout einer Blazor-Anwendung zu einer Tabnavigation anpassen möchten, dann müssen Sie das Standardlayout modifizieren und eine Struktur erstellen, die auf einer Navigation mit Tabs basiert. Eine solche Navigation zeigt die wichtigsten Seiten der Anwendung in Form von Registerkarten (Tabs) an, die den Benutzer:innen eine einfache und schnelle Navigation zwischen den Seiten ermöglichen. Das Quellcodebeispiel finden Sie in Listing 7 und das Ergebnis in Abbildung 4.

@inherits LayoutComponentBase
Layout2
<div class="header-nav">
  <nav class="navbar navbar-expand-lg bg-body-tertiary">
    <div class="container-fluid">
      <a class="navbar-brand" href="#">MyCompany</a>
      <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarNavAltMarkup" aria-controls="navbarNavAltMarkup" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>
      <ul class="nav nav-tabs">
        <li class="nav-item">
          <NavLink class="nav-link active" href="/" Match="NavLinkMatch.All">Home</NavLink>
        </li>
        <li class="nav-item">
          <NavLink href="/weather" class="nav-link">Wetter</NavLink>
        </li>
        <li class="nav-item">
          <NavLink href="/counter" class="nav-link">Counter</NavLink>
        </li>
      </ul>
    </div>
  </nav>
</div>
<div class="content px-4">
  @Body
</div>

Abb. 4: Layout einer Blazor-App mittels Tabnavigation

Die Anpassungen im Quellcode sind ähnlich, wie bei dem eben beschriebenen Beispiel. Um die Tabnavigation zu erreichen sind die entsprechenden Klassen aus Bootstrap für die Tabs zu nutzen.

Verschachtelte Layouts

In Blazor können Layouts ineinander geschachtelt werden, um eine hierarchische Struktur für die Benutzeroberfläche zu schaffen. Das bedeutet, dass ein Layout in einem anderen Layout eingebettet wird. Das ist besonders nützlich, wenn unterschiedliche Bereiche der Anwendung konsistente Elemente haben, aber einige Elemente eine spezifische Struktur benötigen. Dazu ein einfaches Beispiel: Stellen wir uns eine Anwendung vor, die ein Hauptlayout mit einer globalen Navigation und ein weiteres untergeordnetes Layout für einen bestimmten Bereich (z. B. Adminbereich) verwendet. Der Adminbereich hat eine zusätzliche Navigation und spezielle Formatierungen, die sich vom Hauptlayout abheben. Im Hauptlayout wird die globale Navigation und der allgemeine Inhaltsbereich definiert. Dieses Layout verwendet MainLayout als übergeordnetes Layout und fügt zusätzliche Strukturen, wie eine adminspezifische Navigation, hinzu. Nun kann eine Seite das Adminlayout als Layout verwenden. Durch diese Struktur wird eine übersichtliche und flexible Gestaltung möglich, die Bereiche mit spezifischen Anforderungen konsistent in das Hauptlayout integriert. Ein Beispiel finden Sie unter [1].

Fazit

Layouts spielen in Blazor-Anwendungen eine entscheidende Rolle, da sie die Grundlage für eine konsistente und benutzerfreundliche Benutzeroberfläche bilden. Sie ermöglichen eine klare Strukturierung der Seiteninhalte, fördern die Wiederverwendbarkeit und erleichtern die Wartung der Anwendung. Mit der Verwendung von Layouts in Blazor lassen sich Komponenten wie Header, Navigation und Footer zentral verwalten und für mehrere Seiten anwenden. Durch die verschiedenen Layoutoptionen wie Master-Detail, Sidebar, Tabnavigation und Fullscreen können Entwickler:innen das Layout flexibel an die Anforderungen der Anwendung und die Bedürfnisse der Nutzer:innen anpassen. Die Möglichkeit, Layouts ineinander zu verschachteln, bietet zusätzlichen Spielraum für komplexere Anwendungen, indem sie hierarchische Strukturen erlaubt. Zusammengefasst sind Layouts ein unverzichtbares Werkzeug für jede Blazor-Anwendung, da sie sowohl die technische Effizienz als auch die Benutzerfreundlichkeit erheblich steigern.

Web: https://larinet.com, https://www.tech-punkt.com

Links & Literatur

[1] https://learn.microsoft.com/de-de/aspnet/core/blazor/components/layouts?view=aspnetcore-8.0

The post Technische Umsetzung von Layouts in Blazor appeared first on BASTA!.

Unterstützte Projekttypen und Upgrade-Pfade

Der .NET-Upgrade-Assistent unterstützt eine Vielzahl von Projekttypen, die für die Migration auf moderne .NET-Versionen geeignet sind. Zu den unterstützten Projekten gehören [1]:

• ASP.NET
• Azure-Funktionen
• Windows Presentation Foundation (WPF) und Windows Forms
• Klassenbibliotheken und Konsolen-Apps
• .NET Native UWP
• Xamarin.Forms und .NET MAUI

Die unterstützten Upgrade-Pfade umfassen:

• .NET Framework zu .NET
• .NET Core zu .NET
• UWP zu WinUI 3
• Ältere .NET-Versionen auf die neueste Version
• Azure Functions v1-v3 auf v4 (isoliert)
• Xamarin.Forms zu .NET MAUI (Hinweis: für XAML-Dateitransformationen wird nur das Upgrade von Namespaces unterstützt)

Dabei ist aus Praxiserfahrungen festzustellen, dass diese Projekttypen und die zugehörigen Upgrade-Pfade mit einem unterschiedlichen Grad, einer verschiedenen Detaillierung und damit letztendlich auch mit wechselndem Erfolg unterstützt werden.

Installation

Die Installation des .NET-Upgrade-Assistenten kann auf zwei Arten erfolgen: als Visual-Studio-Erweiterung (Extension) oder als globales .NET-Tool. Die Extension finden Sie unter der Bezeichnung Upgrade Assistant. Der Assistent kann direkt aus Visual Studio über das Kontextmenü im Projektmappen-Explorer aufgerufen werden. Um es als globales .NET-Tool zu installieren sind die folgenden Schritte notwendig:

• NET SDK überprüfen: Stellen Sie sicher, dass das .NET SDK auf Ihrem Computer installiert ist. Sie können das überprüfen, indem Sie in der Konsole den Befehl dotnet –version ausführen.
• Upgrade Assistant installieren: Öffnen Sie eine Konsole (Command Prompt, PowerShell) und führen Sie den folgenden Befehl aus dotnet tool install -g upgrade-assistant.
• Update: Da der .NET-Upgrade-Assistent als .NET-Tool installiert ist, kann er mittels dotnet tool update -g upgrade-assistant aktualisiert werden.
• Migrieren: Um ein Projekt zu aktualisieren, können Sie den Upgrade-Assistenten wie folgt verwenden: upgrade-assistant upgrade <Projektdatei oder Lösung>.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Arbeitsweise und Tests

Wir demonstrieren das Handling mit dem .NET-Upgrade-Assistenten anhand einiger Projekte. Unser erstes Projekt ist eine ältere Windows-Forms-Applikation („Bibliothek“) auf der Basis des .NET Framework 4.7.2. Diese enthält lediglich ein Projekt und keine Abhängigkeiten von externen Bibliotheken. Die Benutzeroberfläche enthält nur wenige Komponenten, Herzstück ist ein DataGrid. Die Businesslogik ist im Code-Behind implementiert. Das Ziel ist eine Migration nach .NET 8, um die Applikation weiterentwickeln zu können. Starten wir mit einer ersten Analyse: Wir öffnen das Projekt in der aktuellen Version von Visual Studio und starten auf Ebene der Projektmappe (Kontextmenü im Projektmappen-Explorer) den .NET-Upgrade-Assistenten (Abb. 1).

Abb. 1: Start des .NET-Upgrade-Assistenten aus Visual Studio

Wir starten einen Report und müssen in den nachfolgenden Schritten das betreffende Projekt, das Ziel (hier .NET 8) und den Umfang der späteren Migration auswählen (Abb. 2).

Abb. 2: Konfigurieren der Migration im .NET-Upgrade-Assistenten

Das Ergebnis (Abb. 3) ist ein Report über die Einschätzung des Vorhabens und der notwendigen Schritte.

Abb. 3: Analyseergebnis der geplanten Migration

Die Hinweise stimmen uns optimistisch. Auf Projektebene starten wir danach den .NET-Upgrade-Assistenten neu und führen die konkrete Migration durch. Dabei haben wir u. a. die Wahl, ob wir die Migration innerhalb des Projekts durchführen möchten (in-place project upgrade) oder ob das migrierte Projekt als neues Projekt angelegt werden soll (side-by side project upgrade). Die eigentliche Migration des Projektes erfolgt ohne unser Zutun und konnte erfolgreich abgeschlossen werden. Die Windows-Forms-Applikation wurde nach .NET 8 portiert und kann auch gestartet und ausgeführt werden (Abb. 4).

Abb. 4: Der .NET-Upgrade-Assistent zeigt die erfolgreiche Migration

Das hat sehr gut funktioniert. Wie bereits dargestellt, handelt es sich um ein Projekt mit einem begrenzten Funktionsumfang und wenig Komplexität.

Unser zweiter Test ist schon anspruchsvoller. Es geht um eine Xamarin.Forms-Applikation für Android und iOS. Diese soll nach .NET MAUI migriert werden. Wir laden auch dieses Projekt in Visual Studio. Als Erstes werden wir aufgefordert, die fehlenden Komponenten für die Entwicklung von Xamarin.Forms-Projekte in Visual Studio nachzuladen. Diese wurden schon mit den Updates von Visual Studio entfernt, da auf dem Entwicklungsrechner in letzter Zeit nur noch .NET-MAUI-Projekte entwickelt wurden. Das Projekt weist auch Abhängigkeiten zu einigen externen Bibliotheken auf. Die Analyse der bevorstehenden Migration ergibt ein deutlich gemischteres Bild. Es werden Fehler und Schwierigkeiten bei der Migration erwartet und der Gesamtaufwand wird deutlich größer (24 Story Points) eingeschätzt (Abb. 5).

Abb. 5: Analyse des Xamarin-Projekts durch den .NET-Upgrade-Assistenten

Im nächsten Schritt starten wir die automatische Migration der Xamarin.Forms-App. Es muss jedes Xamarin.Forms-Projekt eigenständig über den .NET-Upgrade-Assistenten migriert werden. Die Migration des plattformneutralen Projektes konnte ohne Fehlermeldungen abgeschlossen werden. Die Migration des Android-Projekts dauerte einige Minuten und auch hier werden keine schwerwiegenden Fehler gemeldet. Als Letztes wird versucht, das iOS-Projekt zu migrieren. Wir bekommen Hinweise, dass ein Plug-in in iOS (zum Einblenden der Tastatur ist es in .NET MAUI nicht mehr erforderlich) nicht in .NET MAUI unterstützt wird. Ansonsten sieht das Ergebnis des Migrationsreports gut aus. Die App lässt sich dennoch nicht unmittelbar fehlerfrei kompilieren. Es werden Mehrdeutigkeiten von Klassen gemeldet. Das rührt daher, dass .NET MAUI auch neue Klassen einführt, die es in Xamarin nicht gab. Hier steht einige manuelle Nacharbeit auf der Agenda. Die Migration von Xamarin auf .NET MAUI ist deutlich komplexer als ein Update der .NET-Version. Dennoch liefert der .NET-Upgrade-Assistent wichtige Hinweise für eine Migration und nimmt auch bereits einige Arbeitsschritte vor.

Unser letztes Experiment versucht, eine Migration einer App für die UWP, bestehend aus mehreren Teilprojekten und der Nutzung von externen Bibliotheken. Starten wir auch hier mit einer Analyse der geplanten Migration: Das Ziel der Migration ist es, die App von der UWP (WinUI 2.*) nach WinUI 3 zu bekommen. Es deuten sich Probleme bei der Nutzung von Drittanbieterbibliotheken an. Die Analyse dauert mehrere Minuten und das Ergebnis enthält Hinweise zu erwarteten Aufgaben der Migration und möglichen Probleme. Hier wird beispielsweise bemängelt, dass eine externe Bibliothek für Interaktion mit dem Cloudspeicherdienst Dropbox nicht mit den neuen .NET-Versionen kompatibel ist. Wir wissen jedoch aus der Praxis, dass diese Bibliothek sowohl mit der UWP als auch mit WinUI 3 funktioniert. Gleiches gilt auch für andere gemeldete voraussichtliche Probleme. Der geschätzte riesige Migrationsaufwand (> 1 600 Story Points), primär durch das mögliche Neuschreiben der Bibliotheken, hat sich in der Praxis nicht so herausgestellt. Die App konnte mit einem deutlich geringeren Aufwand von der UWP nach WinUI 3 migriert werden. Das bedeutet, dass die Schätzung des .NET-Upgrade-Assistenten nur eine grobe Einschätzung des Aufwandes ist, sie kann auch komplett falsch sein. Wertvoller sind die Hinweise zu den konkreten Migrationsschritten.

Stärken, Schwächen und Einschätzung

Der .NET-Upgrade-Assistent wird in der Entwicklercommunity als ein nützliches Werkzeug zur Modernisierung von .NET-Anwendungen angesehen, insbesondere für Projekte, die auf älteren .NET-Framework- oder .NET-Core-Versionen basieren. Das Tool ist wertvoll, weil es den Migrationsprozess durch Automatisierung und eine geführte Schritt-für-Schritt-Anleitung erheblich vereinfacht. Das hilft, typische Fehler zu vermeiden und den Prozess effizienter zu gestalten, insbesondere bei weniger komplexen Projekten. Man kann folgende Stärken ausmachen:

• Automatisierung: Das Tool automatisiert viele Aufgaben, die sonst manuell erledigt werden müssten, wie z. B. die Aktualisierung von Projektdateien und die Verwaltung von Abhängigkeiten. Das reduziert den Arbeitsaufwand und minimiert das Risiko von Fehlern.
• Vielfältige Unterstützung: Der Assistent unterstützt eine breite Palette von Projekttypen, darunter ASP.NET, WPF, Windows Forms und Xamarin.Forms und bietet auch Migrationspfade zu .NET MAUI und Azure Functions.
• Geführter Prozess: Entwickler:innen wird ein strukturierter Migrationspfad geboten, der sie durch jeden Schritt des Prozesses führt. Das Tool hebt potenzielle Probleme hervor und bietet Lösungen an, was besonders für weniger erfahrene Entwickler:innen hilfreich ist.

Das Tool ist primär eine Hilfestellung, d. h., es hat Schwächen und Einschränkungen:

• Komplexe Projekte: Bei sehr großen und komplexen Projekten kann das Tool an seine Grenzen stoßen und erfordert meist manuelle Nacharbeiten, da es nicht immer alle Probleme erkennt oder die optimalen Lösungen vorschlägt.
• Manuelle Eingriffe: Trotz der Automatisierung bleibt bei der Migration noch immer viel manuelle Arbeit erforderlich, insbesondere wenn es Änderungen an den Architekturentscheidungen gibt oder veraltete Bibliotheken nicht automatisch aktualisiert werden können.

Das Tool wird bisher kontinuierlich verbessert und unterstützt inzwischen auch neuere Technologien wie .NET MAUI und Azure Functions. Diese Erweiterungen und die Verbesserung der Fehlerbehandlung tragen dazu bei, die Qualität der automatischen Upgrades weiter zu erhöhen.

Migrationsplanung

Von einfachen Anpassungsmaßnahmen (Upgrade-Pfaden) abgesehen, beispielsweise eine Umstellung von einer älteren auf eine aktuelle .NET-Version, benötigt man eine gute Planung der Durchführung einer Migration. Wir beschreiben nachfolgend drei typische Migrationspfade im .NET-Umfeld. Die Migrationsplanung für .NET-Anwendungen umfasst typischerweise die Schritte (grober Ablauf) gemäß Tabelle 1.

Tabelle 1: Schrittfolge bei der Migration von .NET-basierten Anwendungen

Die Migration einer .NET-Anwendung ist ein anspruchsvoller Prozess, der eine sorgfältige Planung und Durchführung erfordert. Mit einer strukturierten Herangehensweise und der Nutzung des .NET-Upgrade-Assistenten kann der Übergang jedoch risikoarm gestaltet werden. 

Migration von Xamarin.Forms nach .NET MAUI

Xamarin.Forms ist eine bewährte Plattform zur Erstellung plattformübergreifender mobiler Anwendungen mit einer gemeinsamen Codebasis für Android, iOS und UWP. Mit der Einführung von .NET MAUI (Multi-Platform-App-UI) hat Microsoft eine Weiterentwicklung und Erweiterung von Xamarin.Forms bereitgestellt, die zusätzlich die Entwicklung für macOS und Windows unterstützt und eine konsolidierte Entwicklungsplattform innerhalb von .NET darstellt. Sollen bestehende Xamarin.Forms-Apps weiter angepasst und entwickelt werden, sind diese zu .NET MAUI zu migrieren. Der typische Migrationspfad sieht wie folgt aus (Meilensteine):

• Schritt 1 – Aktualisieren: Aktualisieren Sie das Xamarin.Forms-Projekt auf die neueste Version, um sicherzustellen, dass alle Abhängigkeiten aktuell sind.
• Schritt 2 – Konvertieren: Konvertieren Sie das Projekt in ein .NET-MAUI-Projekt, was die Anpassung der Projektdateien (.csproj) erfordert.
• Schritt 3 – Prüfen: Überprüfen und aktualisieren Sie die XAML-Dateien und den Code auf Kompatibilität mit .NET MAUI. Das schließt auch die Migration von benutzerdefinierten Renderern und Abhängigkeiten ein.
• Schritt 4 – Tests: Führen Sie umfassende Tests durch, um sicherzustellen, dass die Anwendung auf allen Zielplattformen ordnungsgemäß funktioniert.
• Schritt 5 – Anpassungen: Durchführen von notwendigen Anpassungen, beispielsweise Bibliotheken, die unter neueren .NET-MAUI-Versionen nicht mehr unterstützt werden.

Neben der Möglichkeit das Projekt weiter entwickeln zu können, ergeben sich weitere Vorteile, beispielsweise eine vereinfachte Projektstruktur, eine bessere Entwicklungsunterstützung, erweiterte Plattformunterstützung (einschließlich Desktopplattformen) und eine verbesserte Performance und API-Konsistenz innerhalb des .NET-Ökosystems.

Migration von WPF zu WinUI 3

Windows Presentation Foundation (WPF) ist ein bewährtes Framework zur Entwicklung von Desktopanwendungen unter Windows. Es bietet eine flexible und leistungsstarke Plattform für die Gestaltung von Benutzeroberflächen. WinUI 3 hingegen ist das neueste UI-Framework von Microsoft, das moderne Windows-10- und Windows-11-Anwendungen mit einer modernen Benutzeroberflächentechnologie ermöglicht. Die Migration von WPF zu WinUI 3 kann eine sinnvolle Option sein, wenn Sie eine modernere, zukunftssichere Oberfläche für Ihre Anwendung entwickeln möchten. Ein typischer Migrationspfad kann wie folgt aussehen:

• Schritt 1 – Bewertung der Anwendung: Beginnen Sie mit einer gründlichen Analyse der bestehenden WPF-Anwendung, um zu verstehen, welche Teile problemlos migriert werden können und welche möglicherweise neu entwickelt werden müssen. Überprüfen Sie, welche externen Bibliotheken und Abhängigkeiten verwendet werden und ob diese in WinUI 3 unterstützt werden oder ersetzt werden müssen.
• Schritt 2 – Erstellen eines neuen WinUI-3-Projekts: Erstellen Sie ein neues WinUI-3-Projekt in Visual Studio. Dies stellt die Grundlage für die Migration Ihrer bestehenden WPF-Komponenten dar. Die Geschäftslogik (Backend-Code) aus der WPF-Anwendung kann in den meisten Fällen direkt übernommen werden, da WinUI 3 auf derselben .NET-Plattform basiert. Der Fokus liegt daher auf der Migration der Benutzeroberfläche.
• Schritt 3 – Migration der Benutzeroberfläche: WPF und WinUI 3 verwenden beide XAML zur Definition der Benutzeroberfläche, aber es gibt Unterschiede in den verfügbaren Steuerelementen und den unterstützten Features. Die XAML-Dateien müssen angepasst werden, um mit den WinUI-3-Komponenten kompatibel zu sein. Einige WPF-spezifische Funktionen wie bestimmte Steuerelemente oder Datenbindungskonzepte müssen durch die entsprechenden WinUI-3-Features ersetzt werden. Hier kann es notwendig sein, benutzerdefinierte Steuerelemente oder Workarounds zu implementieren.
• Schritt 4 – Testen und Optimieren: Testen Sie die migrierte Anwendung umfassend, um sicherzustellen, dass alle UI-Komponenten wie erwartet funktionieren. Achten Sie dabei besonders auf die Performance und das Verhalten der Benutzeroberfläche. Nehmen Sie nach Bedarf Optimierungen vor, insbesondere in Bezug auf die Nutzung neuerer WinUI-3-Features, die in WPF nicht verfügbar waren.
• Schritt 5 – Bereitstellung: Bereiten Sie die migrierte Anwendung für die Bereitstellung vor. WinUI 3 ermöglicht es, die Anwendung sowohl über den Microsoft Store als auch als klassische Desktopanwendung zu verteilen.

Welche Vorteile bietet eine Migration zu WinUI 3? WinUI 3 unterstützt das Fluent-Design-System, das moderne und ansprechende Benutzeroberflächen ermöglicht. Ebenso ist WinUI 3 die Basis für zukünftige Windows-Entwicklungen, was die Anwendung langfristig wartbar und kompatibel mit neuen Windows-Versionen macht. Es gibt eine bessere Unterstützung und Integration mit den neuesten Windows APIs, was die Nutzung neuerer Betriebssystemfeatures erleichtert. Bei größeren Projekten kann man jedoch von einem umfangreicheren Anpassungsbedarf ausgehen. Die Migration der Benutzeroberfläche kann erheblichen Anpassungsaufwand erfordern, insbesondere bei komplexen WPF-Anwendungen. Einige WPF-Features haben keine direkten Entsprechungen in WinUI 3, was möglicherweise Neuentwicklungen erforderlich macht. Zusammengefasst kann man sagen: Die Migration von WPF zu WinUI 3 ist ein strategischer Schritt, der insbesondere dann sinnvoll ist, wenn eine langfristige Modernisierung und Integration mit den neuesten Windows-Technologien angestrebt wird.

Anmerkung/Hinweis: Microsoft hat erkannt, dass WPF weiterhin eine große Bedeutung für bestehende Projekte (und vielleicht auch noch für neue Projekte) hat. Es sind daher auch Anpassungen und Aktualisierungen geplant. Die Roadmap [2] zu WPF sieht dazu beispielsweise wie folgt aus: „Im letzten Jahr haben wir uns bemüht, die Testinfrastruktur zu verbessern, Community-PRs zusammenzuführen, um seit langem bestehende Probleme zu beheben, neue Steuerelemente hinzuzufügen (OpenFolderDialog) und neue Funktionen zu ermöglichen (Hardwarebeschleunigung für RDP-Verbindungen). Die Bemühungen, unsere Tests als Open Source bereitzustellen und den Testprozess durch CI/CD-Pipelines zu automatisieren, Komponententests hinzuzufügen, persistente Probleme zu beheben und neuere Steuerelemente hinzuzufügen, führten dazu, dass WPF auf .NET 8 integriert wurde“. Ebenso werden die folgenden Features, beispielsweise mit .NET in Aussicht gestellt:

• Integration von Win-11-Features wie Andocklayout, abgerundete Ecken für Steuerelemente und neueres Farbschema
• Nullability Annotations zur Verbesserung der Codequalität
• Verbesserungen der Barrierefreiheit für WPF-Steuerelemente
• Optimierung von WPF für verbesserte Unterstützung auf allen Geräten

Daraus kann man schlussfolgern, dass WPF kurzfristig wohl nicht abgekündigt wird und daher eine Migration nach WinUI 3 aus heutiger Sicht nicht zwingend ist. Wichtiger ist es jedoch bestehende WPF-Anwendungen auf der Basis des .NET Frameworks (bis Version 4.8*) nach .NET zu portieren – womit wir direkt bei der Beschreibung des nächsten Migrationspfads sind.

Migration von .NET Framework zu .NET

Das .NET Framework ist eine ältere, aber weit verbreitete Plattform für die Entwicklung von Windows-Anwendungen. Es wurde bekanntermaßen durch .NET (früher .NET Core) abgelöst. Sollen bestehende Applikationen dauerhaft weiterentwickelt werden, muss man diese nach .NET migrieren. Die Schritte des typischen Migrationspfades sind:

• Schritt 1 – Analyse: Nutzen Sie den .NET-Upgrade-Assistenten, um die Kompatibilität Ihrer Anwendung zu prüfen und potenzielle Probleme zu identifizieren.
• Schritt 2 – Aktualisieren: Aktualisieren Sie NuGet-Pakete und Abhängigkeiten, um die Kompatibilität mit .NET sicherzustellen.
• Schritt 3 – Konvertieren: Konvertieren Sie das Projekt in ein SDK-Format und passen Sie die Projektdateien entsprechend an.
• Schritt 4 – Migrieren: Migrieren Sie schrittweise den Code, indem Sie veraltete APIs ersetzen und plattformübergreifende Features nutzen.
• Schritt 5 – Testen: Führen Sie umfassende Tests durch, um sicherzustellen, dass die Anwendung unter .NET korrekt funktioniert.

Durch die Migration – welche nicht immer einfach möglich ist – erreichen wir folgende Vorteile: eine plattformübergreifende Unterstützung (Windows, Linux, macOS), eine verbesserte Performance und Ressourcennutzung, den Zugang zu den neuesten .NET-Features und -Verbesserungen und eine langfristige Wartbarkeit der Applikation. Einen Überblick zu den aktuellen .NET-Versionen und deren Vorversionen gibt Tabelle 2. .NET 9 wird voraussichtlich im November 2024 erscheinen und .NET 10 ist für 2025 geplant.

Tabelle 2: .NET-Versionen (LTS = Long Term Support, STS = Standard Term Support)

Fazit und Ausblick

Insgesamt bietet der NET-Upgrade-Assistent eine solide Grundlage für die Modernisierung von .NET-Anwendungen, besonders für kleinere bis mittelgroße Projekte. Bei größeren Projekten kann es ein Hilfsmittel sein, um den Anpassungsbedarf der Migration abzuschätzen. Hier muss i. d. R. eine umfassende Planung je nach Ausgangspunkt und Ziel des Upgrades durchgeführt werden. Schnelle und unkomplizierte Hilfe kann es für das eine oder andere .NET-Projekt bereitstellen, wenn man dieses beispielsweise im Zuge des laufenden Entwicklungsprojektes auf die aktuelle .NET-Version bringen möchte. Die Migration per Mausklick ist auch im .NET-Umfeld nur in Einzelfällen machbar.

Web: https://larinet.com, https://www.tech-punkt.com.

Links & Literatur

[1] https://learn.microsoft.com/de-de/dotnet/core/porting/upgrade-assistant-overview?WT.mc_id=dotnet-35129-website

[2] https://github.com/dotnet/wpf/blob/main/roadmap.md

The post Der .NET-Upgrade-Assistent: Alles, was Sie zur Anwendungsmigration wissen müssen appeared first on BASTA!.

1. Von Sprache zu Software: GitHub Copilot Workspaces
   Was bedeutet es, wenn Software durch Sprache entsteht? Mit “GitHub Copilot Workspaces” geben unsere Speaker einen Ausblick auf die nächste Generation der KI-gestützten Entwicklerwerkzeuge und wie sie deinen Entwicklungsprozess optimieren können.
2. Smarter coden mit KI: Claude-Dev in VS Code
   Coding ist nur ein Teil der täglichen Arbeit eines Entwicklers. Mit Claude-Dev, vollständig in Visual Studio Code integriert, macht das Programmieren einfach mehr Spaß – und du sparst wertvolle Zeit bei repetitiven Aufgaben.
3. Azure AI: Das Schweizer Taschenmesser für KI-Entwickler
   Solide KI-Lösungen zu entwickeln erfordert mehr als nur ein Tool. Azure AI bietet ein umfassendes Set an Technologien, das alle Aspekte der KI-Entwicklung abdeckt – von der Modellauswahl bis zum Scripting und darüber hinaus.

Warum du diese Keynote nicht verpassen solltest

Diese Keynote ist ein Muss für jeden, der sich für die Zukunft der Softwareentwicklung interessiert. Die gezeigten Tools und Techniken eröffnen neue Möglichkeiten, wie Entwickler ihre Arbeit effizienter gestalten können. Egal, ob du bereits mit KI arbeitest oder gerade erst einsteigst – diese Keynote liefert dir wertvolle Insights und praktische Tipps für deinen Alltag als Software-Entwickler.

Jetzt die gesamte Keynote ansehen und mehr erfahren!

The post Die Zukunft des Software Developments: KI in der Praxis appeared first on BASTA!.

Was ändert sich?

Die Sicherheitsbranche ist ein sich ständig weiterentwickelndes Feld, das andauernd nach neuen und effektiveren Methoden sucht, um die Sicherheit von Systemen und Daten zu gewährleisten. Als Microsoft am 1. April 2024 Microsoft Copilot for Security für den Markt freigab, hielt die künstliche Intelligenz Einzug in die Sicherheitsbranche. Der Einfluss ist signifikant – hier ein paar der wichtigsten Auswirkungen:

• Produktivitätssteigerung: Studien zeigen, dass Sicherheitsexperten bei allen Aufgaben bis zu 22 Prozent schneller und neue Sicherheitsmitarbeiter bis zu 44 Prozent genauer sind.
• Effizienzsteigerung: Microsoft Copilot for Security hilft Sicherheitsteams, ihre Effizienz zu steigern, indem es ihnen ermöglicht, innerhalb von Minuten statt Stunden oder Tagen auf Vorfälle zu reagieren.
• Lern- und Karrierewachstum: Copilot unterstützt das Lernen und die berufliche Entwicklung von Sicherheitsteams. Es hilft Nachwuchsanalyst:innen beim Aufbau von Wissen und Fähigkeiten und spart gleichzeitig den leitenden Mitarbeitenden wertvolle Zeit.
• Benutzerakzeptanz: Mehr als 93 Prozent der Benutzer:innen wollten Copilot erneut verwenden.
• AI als Force Multiplier: Künstliche Intelligenz wird schnell zu einem Force Multiplier, der bedeutende Möglichkeiten für Sicherheitsteams bietet, die Produktivität zu steigern, Zeit zu sparen, Ressourcen aufzurüsten und mehr.

Insgesamt trägt Microsoft Copilot for Security dazu bei, die Sicherheitsbranche zu transformieren, indem es die Effizienz und Genauigkeit von Sicherheitsteams verbessert und gleichzeitig das Lernen und die berufliche Entwicklung fördert.

Wie kann ich AI Awareness schaffen?

Diese Frage ist leider nicht so einfach zu beantworten – dennoch gibt es ein paar Leitsätze, die hier einen Ansatz zeigen können, wie sich AI-Awareness schaffen lässt:

1. Bildung und Schulung: Schulungen für Mitarbeiter:innen über die Grundlagen der KI und ihre Anwendung in der Sicherheitsbranche stellen ein essenzielles Fundament dar. Dabei werden sowohl theoretisches Wissen als auch praktische Anwendungen vermittelt.
2. Workshops und Seminare: Ein wertvolles Mittel gegen Ängste oder Unsicherheit bietet die Durchführung von Workshops und Seminaren. Das trägt zusätzlich dazu bei, Akzeptanz aufzubauen und das Vertrauen in die Technologie zu stärken.
3. Ressourcen zur Verfügung stellen: Wer sich in die Cloud begibt, steht oft vor der Herausforderung, wie man Know-how aufbauen kann. Ein wesentlicher Punkt hierbei ist die Bereitstellung von Ressourcen. Das ist bereits in der Grundarchitektur des Enterprise-Scale Framework verankert und findet sich in den Sandboxing Landing Zones wieder.
4. Kontinuierliche Unterstützung: Es ist ebenso wichtig, dass Unternehmen kontinuierliche Unterstützung bieten, um sicherzustellen, dass Mitarbeiter:innen bei der Nutzung von KI in der Sicherheitsbranche erfolgreich sind.
5. Förderung einer Kultur der Akzeptanz: Unternehmen sollten eine Kultur fördern, die die Akzeptanz und Nutzung von KI fördert.

Alles in allem muss grundlegende Akzeptanz und eine Hands-on-Experience geschaffen werden, um im weiteren Schritt die AI auch in interne Systeme einfließen zu lassen. Dieser Schritt ist essenziell und einer der wichtigsten auf der AI Journey.

Copilot for Security Standalone vs. Embedded?

In der Standalone Experience von Copilot for Security wird eine eigenständige Anwendung genutzt – Benutzer:innen greifen direkt auf die Copilot-Plattform zu, um Sicherheitsanalysen durchzuführen. Die Embedded-Version von Copilot for Security ist in den Microsoft-Produkten integriert. Das bedeutet, dass die Funktionen von Copilot direkt in folgenden Produkte genutzt werden können:

• Microsoft Defender XDR
• Microsoft Purview
• Microsoft Sentinel
• Microsoft Entra
• Microsoft InTune
• Microsoft Defender for Cloud

Diese Integration ermöglicht es Benutzer:innen, die Vorteile von Copilot zu nutzen, ohne die gewohnte Arbeitsumgebung verlassen zu müssen.

Wie funktioniert Copilot for Security?

Copilot for Security nutzt das fortschrittliche GPT4-Modell von OpenAI in Kombination mit einem speziellen Sicherheitsmodell, das von Microsoft entwickelt wurde. Dieses Modell wird durch die umfassende Sicherheitsexpertise und globale Bedrohungsintelligenz von Microsoft Security angetrieben. Durch die Integration von weiteren Microsoft Services und Third-party Services werden die Effektivität und Effizienz von Sicherheitsexperten erhöht.

Funktionen wie die Skriptanalyse ermöglichen es Kunden beispielsweise, Hunderte von Codezeilen zu analysieren und diese in natürlicher Sprache in Minuten zu interpretieren. Der Prozess ist grundsätzlich sehr einfach ausgelegt und basiert auf einigen Charakteristika (Abb. 1).

Abb. 1: Der Prozess für Copilot for Security [1]

1. Einen Prompt in die Prompt Bar eingeben. Das ist die Interaktion des Mitarbeitenden mit dem Copilot.
2. Der Copilot for Security sendet diese Information an das Backend. Hier wird auch die initiale Datenverarbeitung durchgeführt, die anschließend einen Plan aufgrund der verfügbaren Möglichkeiten (Skills) erstellt.
3. Sobald ein Plan definiert und erstellt ist, führt Copilot diesen Plan aus, um den erforderlichen Datenkontext zum Beantworten des Prompts zu erhalten.
4. Während der Ausführung des Plans analysiert Copilot alle Daten und Muster, um intelligente Erkenntnisse zu liefern.
5. Copilot kombiniert alle Daten und Kontexte und nutzt die Leistungsfähigkeit seines erweiterten LLM (Large Language Model), um eine Antwort in verständlicher Sprache zu verfassen.
6. Bevor die Antwort an Benutzer:innen zurückgesendet werden kann, formatiert und überprüft Copilot die Antwort im Rahmen des Engagements von Microsoft für verantwortungsvolle AI. Dies beruht auf folgenden Prinzipien:
   • Fairness
   • Zuverlässigkeit und Sicherheit
   • Datenschutz und -Sicherheit
   • Inklusion
   • Transparenz
   • Verantwortlichkeit
7. Zuletzt wird die verifizierte Antwort an die Benutzer:innen zurückgesendet, die damit weiterarbeiten können.

Datenschutz und -sicherheit

Im sechsten Punkt wurde das Thema verantwortungsvolle AI und das Engagement von Microsoft kurz angeschnitten. Ich möchte hier auf den Punkt Datenschutz und -sicherheit etwas genauer eingehen.

Ein wesentlicher und wichtiger Aspekt hierbei ist „Deine Daten sind deine Daten, die durch umfassende Compliance- und Sicherheitskontrollen gesichert sind“. Ihre Daten werden auch nicht für das Trainieren von AI-Modellen verwendet. Um die Daten ausschließlich der Organisation zur Verfügung zu stellen, werden folgende Maßnahmen angewendet:

• Verschlüsselung: Daten werden sowohl im Ruhezustand als auch während der Übertragung verschlüsselt, um unbefugten Zugriff zu verhindern.
• Zugriffskontrollen: Nur autorisierte Personen haben Zugriff auf sensible Informationen. Das wird durch rollenbasierte Zugriffskontrollen und die Zuweisung von Berechtigungen gewährleistet.
• Datenfreigabeeinstellungen: Die Freigabe von Kundendaten ist standardmäßig aktiviert, kann jedoch von den Copilot-Besitzenden während der ersten Nutzung und jederzeit danach angepasst werden.
• Regelmäßige Überwachung und Protokollierung: Systemgenerierte Protokolle werden kontinuierlich erstellt, um die Systemaktivität zu überwachen und sicherzustellen, dass die Systeme wie erwartet funktionieren.
• Einhaltung von Datenschutzbestimmungen: Microsoft Copilot for Security erfüllt die bestehenden Datenschutz-, Sicherheits- und Complianceverpflichtungen, einschließlich der Datenschutz-Grundverordnung (DSGVO) und der EU-Datenrichtlinie.

Analyst:innen können keine Daten und Informationen einsehen, auf die sie keinen Zugriff haben. Wenn beispielsweise ein Securityanalyst Informationen von Microsoft Sentinel benötigt, muss er auch die notwendigen Berechtigungen dafür haben, um die Daten zu erhalten.

Hier eine Auflistung der Microsoft-Hauptdatenquellen (Skills), die an Copilot for Security angebunden bzw. aktiviert werden können:

• Microsoft Defender XDR
• Microsoft Sentinel
• Microsoft InTune
• Microsoft Defender Threat Intelligence
• Microsoft Entra
• Microsoft Purview
• Microsoft Defender External Attack Surface Management
• Microsoft Defender for Cloud

Des Weiteren kann Copilot for Security um Third-party-Plug-ins und Custom-Integrationen erweitert werden.

Schlussfolgerung

Zusammengefasst handelt es sich bei Copilot for Security um eine Revolution im Securitybereich, die unter Berücksichtigung und Sicherstellung von umfangreichen Compliance- und Sicherheitsmaßnahmen jedem zur Verfügung steht. Diese Funktionalität basiert auf dem aktuellen Entwicklungsstand der künstlichen Intelligenz und wird in den hoch skalierbaren Cloud-Datacenters von Microsoft betrieben.

Aus Sicht von Konsumenten wird sich die Erkennung von Angriffen erheblich verbessern und auch die Incident Response beschleunigen, was heutzutage ein absolutes Muss darstellt.

Links & Literatur

[1] learn.microsoft.com

The post Microsoft Copilot for Security appeared first on BASTA!.

Introduction

bUnit ist eine Bibliothek, die das Testen von Blazor-Komponenten vereinfacht. Dabei stellt bUnit Klassen und Methoden bereit, die das Interagieren von Blazor-Komponenten (oft „component under test“, kurz „cut“ genannt) ermöglicht und vereinfacht. Dabei ist bUnit, im Gegensatz zu xUnit, nUnit oder MSTest kein eigener Test-Runner, der Tests ausführt, sondern sitzt auf diesen auf und erweitert sie um die Möglichkeit, Blazor-Komponenten zu testen.

„Hallo Welt“

Wer schon einmal mit Blazor gearbeitet hat, kennt das klassische „Hallo Welt“-Beispiel, in dem ein Counter hochgezählt wird. Wir erweitern dieses kleine Beispiel (Listing 1) um zwei weitere Sachen:

1. Unsere Komponente soll den initialen Wert als Parameter übergeben bekommen.
2. Das Inkrementieren erfolgt über einen Service, der per Dependency Injection in die Komponente injiziert wird.

Wie sieht nun ein Test für diese Komponente aus (Listing 2)?

Listing 1

@page "/counter"
@inject IIncrementService IncrementService

<h1>Counter</h1>
<p>Current count: @InitialCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
[Parameter]
public int InitialCount { get; set; }

private void IncrementCount()
{
InitialCount = IncrementService.Increment(InitialCount);
}
}

Listing 2

@using Bunit
@inherits TestContext

@code {
[Fact]
public void IncrementCounterWhenButtonClicked()
{
// Wir haben, wie im produktiven System, einen "DI" Container, den wir befüllen können
// Dies ermöglich uns, den Service zu mocken und zu injizieren
// Services.AddScoped<IIncrementService, FakeIncrementService>();
// Dank des Razor-Formats können wir die Komponente direkt erzeugen und Parameter einfach zuweisen
var cut = Render<Counter>(@<Counter InitialCount="3">)

// Wir nutzen CSS-Selektoren und "Klicken" auf den Button
cut.Find("button").Click();

// Wieder benutzen wir CSS-Selektoren und prüfen ob der Text stimmt
cut.Find("p").MarkupMatches("<p>Current count: 4</p>");
}

private class FakeIncrementService : IIncrementService
{
public int Increment(int count) => count + 1;
}
}

Was besonders auffällt, ist, dass der Testcode sehr nah am eigentlichen Blazor-Code liegt. Das liegt daran, dass bUnit-Tests im Razor-Format unterstützt. Die Dokumentation zeigt auf, wie das möglich ist [1]. Natürlich ist es möglich, auch klassische Tests zu schreiben, jedoch ist der Razor-Ansatz sehr angenehm und macht das Testen von Blazor-Komponenten sehr eingängig. Die Unterschiede werden ebenfalls in [2] aufgezeigt.

Entwickler:innen, die sich schon mit Ende-zu-Ende-Tests auseinandergesetzt haben, wird auffallen, dass die Selektion von Elementen sehr ähnlich ist (via CSS-Selektoren). Das ist kein Zufall, denn bUnit verwendet AngleSharp [3], um die Komponenten zu analysieren und zu selektieren.

Im gegebenen Test wird ein FakeIncrementService erstellt und in den DI-Container injiziert. Das ermöglicht es, den Service zu mocken und somit die Businesslogik der Komponente zu testen. Das ist ein sehr einfaches Beispiel, zeigt aber sehr gut, wie einfach bUnit das Testen von Blazor-Komponenten macht. Durch den Razor-Ansatz sind das Erstellen und Zeichnen der Counter-Komponente wie im produktiven Code möglich. Das Übergeben der InitialCount-Parameter geschieht direkt im HTML-Code im Test.

Danach wird via Find ein Button gesucht. Im gegebenen Beispiel gibt es nur einen, welcher zurückgegeben wird – anschließend wird dank der Click Methode das onclick Event ausgelöst.

Der Unterschied zu Ende-zu-Ende-Tests, oder: Was bUnit nicht ist

Ende-zu-Ende-Tests sind Tests, welche die gesamte Applikation testen. Dabei wird die Applikation gestartet und die Tests interagieren mit der Applikation, wie Benutzer:innen es tun würde. bUnit hingegen zielt darauf ab, eine einzelne Komponente (oder auch mehrere) zu testen. Dabei wird die Komponente isoliert getestet und nicht die gesamte Applikation. Das bringt einige Vorteile mit sich:

• Schneller: Da nur eine Komponente getestet wird, sind die Tests schneller als Ende-zu-Ende-Tests. Es muss auch viel weniger aufgebaut werden, da nur die Komponente und nicht die gesamte Applikation gestartet wird.
• Stabiler: Da die Komponente isoliert getestet wird, hat sie weniger Abhängigkeiten zur Umwelt und ist somit stabiler.

Wichtig zu verstehen ist, dass bUnit keinen Ersatz für Ende-zu-Ende-Tests darstellt, sondern eine Ergänzung. Zum Beispiel laufen Tests im Gegensatz zu Ende-zu-Ende-Tests nicht im Browser. Das birgt auch einige Nachteile:

• JavaScript-Interaktion: JavaScript wird nicht ausgeführt. Das bedeutet, dass JavaScript-Interaktionen nicht getestet werden können (aber bUnit bietet die Möglichkeit, JavaScript zu emulieren, später dazu mehr).
• Styling: Da die Komponenten nicht im Browser gerendert werden und CSS-Klassen nicht „angewendet“ werden, können zum Beispiel keine Browser-spezifischen Styles getestet werden.
• Navigation: Da die Komponenten nicht im Browser gerendert werden (und damit kein Router involviert ist), können nicht einfach Links angeklickt und zu anderen Seiten navigiert werden.

Wenn Ihnen diese Punkte wichtig sind, sind Testing-Frameworks wie Playwright oder Cypress die bessere Wahl.

Was sollte mit bUnit getestet werden?

Es ist wichtig, zu verstehen, dass bUnit kein Browser oder komplettes End-to-End-Test-Framework ist. Es ist darauf ausgelegt, einzelne Komponenten und deren Businesslogik zu testen. Hier eine sehr vereinfachte Komponente: Sie hat ein Anchor-Element, das auf eine andere interne Seite verweist: <a href=”/bestellung/1″>Zur Bestellung</a>. Ein Test könnte dann so aussehen wie in Listing 3.

Listing 3

@using Bunit
@inherits TestContext

@code {
[Fact]
public void ShouldNavigateToUrl()
{
var cut = Render(@<MyComponent />);
cut.Find("a").Click();

// Den NavigationManager aus dem Container holen
var navigationManager = Services.GetRequiredService<NavigationManager>();
navigationManager.Uri.Should().Be("/bestellung/1");
}
}

Wir klicken auf den Link und prüfen, ob der URL stimmt. Obwohl der Test zuerst sinnvoll erscheint, ist er es nicht, aus zwei Gründen. Zuerst ist es wesentlich, zu verstehen, dass Click nicht wirklich auf ein HTML-Element klickt, sondern das @onclick Event ausführt. Im gegebenen Beispiel gibt es aber gar kein @onclick Event. Das bedeutet, dass der Test immer fehlschlagen wird, da der Link nicht auf das @onclick Event reagiert. Der zweite Grund ist, dass der Test nur 3rd-Party-Code testet. Unit-Tests, die das Hauptanwendungsgebiet für bUnit sind, sollten immer nur die eigene Businesslogik testen. Das Klicken auf einen Link ist aber nicht Bestandteil der eigenen Businesslogik, sondern das Resultat aus der Kombination von Blazor und dem Browser.

Stubbing und Faking von Komponenten

Genau deshalb bringt bUnit auch die Fähigkeit mit, Komponenten komplett zu ersetzen. Das bedeutet, dass wir beliebige Komponenten durch eigene Komponenten ersetzen können oder einfach durch leeres Markup (auch Shallow Rendering genannt). Das macht immer dann Sinn, wenn eine Komponente viele Abhängigkeiten hat, die nicht relevant für den Test sind. Doch was ist Faking beziehungsweise Stubbing? Faking ist das Ersetzen von Komponenten durch eigene Komponenten, die wir kontrollieren können. Stubbing ist das Ersetzen von Komponenten durch leeres Markup. Ein Beispiel, in dem ein Button einer 3rd-Party-Bibliothek verwendet wird, finden Sie in Listing 4.

Listing 4

@page "/counter"
<h1>Counter</h1>
<p>Current count: @InitialCount</p>

<ThirdPartyButton Click="Increment">Click me</ThirdPartyButton>

@code {
[Parameter]
public int InitialCount { get; set; }

private void Increment()
{
InitialCount++;
}
}

Wie sieht nun ein Test dafür aus? Wie bewegen wir den ThirdPartyButton dazu, dass er das Increment Event auslöst? Das ist gar nicht so einfach, da wir nicht wissen, wie der ThirdPartyButton implementiert ist. Ein Weg besteht darin, herauszufinden, dass der ThirdPartyButton intern auch nur ein button-Element ist und wir dieses Element direkt ansprechen können (Listing 5).

Listing 5

@inherits TestContext

@code {
[Fact]
public void IncrementCounterWhenButtonClicked()
{
var cut = Render(@<Counter InitialCount="3" />);

cut.Find("button").Click();

cut.Find("p").MarkupMatches("<p>Current count: 4</p>");
}
}

Schön, der Test wird grün, es verstreicht ein wenig Zeit und nun nutzt der ThirdPartyButton ein div-Element. Resultat: Der Test wird rot. Das ist ein Problem, weil wir nicht die Implementation der Komponente testen wollen, sondern nur die Businesslogik. Hier kommt das Faking ins Spiel (Listing 6). Dafür bietet bUnit die Möglichkeit, Komponenten zu ersetzen. Das bedeutet, dass wir den ThirdPartyButton durch eine eigene Komponente ersetzen, die wir kontrollieren und mittels der wir auch einfach das Click Event auslösen können.

Listing 6

@using Bunit
@inherits TestContext

@code {
[Fact]
public void IncrementCounterWhenButtonClicked()
{
// Dies ersetzt alle Vorkommen von "ThirdPartyButton" durch "FakeThirdPartyButton"
ComponentFactories.Add<FakeThirdPartyButton, ThirdPartyButton>();
var cut = Render(@<Counter InitialCount="3" />);

// Wir lösen das Click Event aus
cut.FindComponent<FakeThirdPartyButton>().Instance.ClickButton();

cut.Find("p").MarkupMatches("<p>Current count: 4</p>");
}

private class FakeThirdPartyButton : ComponentBase
{
[Parameter]
public EventCallback Click { get; set; }

public Task ClickButton() => Click.InvokeAsync();
}
}

Das ist ein sehr einfaches Beispiel, zeigt aber sehr gut, wie mächtig das Ersetzen von Komponenten sein kann. In der offiziellen Dokumentation finden sich mehr Details über Stubbing und Faking von Komponenten [4]. bUnit geht sogar ein Schritt weiter und bietet extra Pakete an, die automatisch Stubs generieren können. Mehr dazu kann auf der offiziellen Website gefunden werden [5].

Natürlich kann das Stubbing auch dafür genutzt werden, um das Set-up von Komponenten zu vereinfachen, zum Beispiel eine Komponente, die gewisse Dienste injiziert bekommt, um zu funktionieren. Wenn diese Komponente für den Test nicht wichtig ist, ergibt es Sinn, sie zu ersetzen, um die Stabilität des Tests zu erhöhen und Abhängigkeiten zu reduzieren.

JavaScript-Interaktion

Auch wenn Stubbing oder Faking die Möglichkeit bietet, gewisse Sachen zu vereinfachen, kann es sein, dass die eigene Integration mit JavaScript getestet werden muss. bUnit führt zwar JavaScript nicht direkt aus, bringt aber eine eigene Laufzeit mit, welche es einfach macht, zu prüfen, ob JavaScript aufgerufen wurde (oder nicht). Dieses Verhalten ist automatisch angeschaltet. Dabei wird zwischen strict und loose unterschieden. strict bedeutet, dass, wenn bUnit einen JavaScript-Aufruf entdeckt, welcher nicht erwartet wurde, der Test fehlschlägt. loose hingegen ignoriert solche Aufrufe. Der Standardwert ist strict – im Falle von Werten, die von der Interoperabilitätsschicht von Blazor zurückgegeben werden, gibt loose den Standardwert des Datentyps zurück (zum Beispiel 0 für int). Eine ausführliche Dokumentation kann unter [6] gefunden werden.

Wo geht die Reise hin?

bUnit ist seit fünf Jahren versehen mit der Version 1, sprich seit fünf Jahren ist bUnit mehr oder weniger API-stabil und unterstützt .NET Core 3.1 bis .NET 9. Das ist unabhängig davon, dass manche von diesen Versionen schon nicht mehr offiziell von Microsoft selbst unterstützt werden. Mit so einer langen Laufzeit für eine Version gibt es natürlich Sachen, die eventuell gar nicht mehr so gebraucht werden oder die man heute anders machen würde und genau das ist die Idee für die nächste Version, die sich gerade in der Vorabphase befindet.

Das generelle Thema für Version 2 sind Aufräumarbeiten, ein verbessertes API und einige neue Funktionalitäten und Bugfixes, die größere Änderungen erforderten. Generell wurde viel alter Ballast abgeräumt. Darunter zählen zum Beispiel, dass nur noch .NET 8 und kommende Versionen unterstützt werden.

Viele Abstraktionen (Klassen wie Interfaces) waren für den Fall gedacht, dass es neben Blazor für das Web auch noch andere Modi gibt, die nicht HTML-basiert sind (zum Beispiel Blazor Mobile Bindings [7], die vor ein paar Jahren als Experiment angekündigt wurden). Diese Abstraktionen werden entfernt bzw. zusammengeführt, um ein einheitlicheres Bild zu geben.

Vereinheitlichung des API

Das neue Release soll ein einfacheres API bieten – zum Beispiel kannte Version 1 der Bibliothek Funktionen wie Render, SetParametersAndRender und RenderComponent. Diese Funktionen werden in der neuen Version zu einer einzigen Funktion zusammengefasst: Render. Des Weiteren wurden viele Funktionen und Klassen auf konsistente Weise umbenannt und die meisten Typen starten mit Bunit als Präfix. Zum Beispiel wird aus TestContext dann BunitContext oder aus FakeNavigationManager wird BunitNavigationManager. Es soll einfacher werden, neue Dinge zu entdecken und zu verwenden.

Rauf und runter im Komponentenbaum

In Version 1 war es ohne weiteres möglich, Kindkomponenten der aktuellen Komponente zu finden (FindComponent), sprich es gab eine Möglichkeit, hinunterzugehen. In Version 2 soll es auch möglich sein, von einer Kindkomponente zur Elternkomponente zu gehen. Technisch gesehen war es in Version 1 so, dass jede Komponente das generierte Markup von sich (cut.Markup) und allen Kindelementen hatte. Dabei war die Komponente selbst immer das Root-Element in dem Baum. Das führt dazu, dass Kindelemente natürlich auch nur sich selbst als Root-Element und damit keine Beziehung mehr zum Elternelement haben. Das führte zu Fehlern, die sehr unverständlich für User:innen waren, zum Beispiel beim Zusammenspiel zweier Komponenten, wobei die Elternkomponente ein form-Element ist, das aus dem Kindelement submittet wird (Listing 7).

Listing 7

<form @onsubmit="SubmitForm">
<ChildComponent />
</form>

@code {
private void SubmitForm() { ... }
}

Hier die Kindskomponente: <button type=”submit”>Abschicken</button>. Im Browser würde das Drücken auf Abschicken das Formular senden. Wie der Test hier aussieht, zeigt Listing 8.

Listing 8

var cut = Render(@<ParentComponent />);
// Wir suchen die "ChildComponent"
var childComponent = cut.FindComponent<ChildComponent>();

// Ausführen des Submit Events
childComponent.Find("button").Submit();

// Prüfen, ob der Submit Event ausgelöst wurde

…

Der Test scheint logisch und korrekt zu sein, aber er wird fehlschlagen. Der Grund ist, dass die childComponent nur das button-Element kennt. Dieses Hindernis wird mit Version 2 überarbeitet und funktioniert dann ohne Probleme. Insgesamt versucht bUnit nicht, sich in Version 2 neu zu erfinden, sondern viele Sachen zu vereinfachen, alte Sachen wegzulassen und den Weg zu ebnen, um in Zukunft einfacher neue Features hinzuzufügen.

Weitere Informationen

bUnit ist eine sehr mächtige Bibliothek, die das Testen von Blazor-Komponenten sehr einfach macht. Die offizielle Website bietet eine sehr gute Dokumentation und viele Beispiele, die das Verständnis erleichtern. Die Website ist unter [8] zu finden. Wenn man sich für die Entwicklung von bUnit interessiert, kann man gerne auf der offiziellen GitHub-Seite vorbeischauen [9]. Natürlich sind Bug-Reports, Featureverbesserung und Fragen immer willkommen.

Links & Literatur

[1] https://bunit.dev/docs/getting-started/create-test-project.html?tabs=xunit

[2] https://bunit.dev/docs/getting-started/writing-tests.html?tabs=xunit#write-tests-in-cs-or-razor-files

[3] https://anglesharp.github.io

[4] https://bunit.dev/docs/test-doubles/index.html

[5] https://bunit.dev/docs/extensions/bunit-generators.html

[6| https://bunit.dev/docs/test-doubles/emulating-ijsruntime.html

[7] https://learn.microsoft.com/en-us/mobile-blazor-bindings/

[8] https://bunit.dev

[9] https://github.com/bUnit-dev/bUnit

The post Effizientes Unit-Testen von Blazor-Komponenten mit bUnit appeared first on BASTA!.

Zoneless

Auch wenn der Ansatz im Regelfall gut funktioniert, führt er doch immer wieder zu Problemen. Beispielsweise lassen sich Bugs in diesem Bereich nur schwer diagnostizieren, und da nicht jeder Event Handler zwingend gebundene Daten ändert, läuft die Change Detection mitunter zu häufig. Entwickelt man wiederverwendbare Web Components, die Implementierungsdetails wie die Nutzung von Angular verstecken, muss der Konsument diese trotzdem mit einer bestimmten zone.js-Version einsetzen.

Ab Version 18 unterstützt das Framework nun auch einen Datenbindungsmodus, der ohne zone.js auskommt. Er ist vorerst experimentell, damit das Angular-Team zur neuen Vorgehensweise Feedback sammeln kann. Um diesen Modus zu aktivieren, ist die Funktion provideExperimentalZonelessChangeDetection beim Bootstrapping der Anwendung zu nutzen:

export const appConfig: ApplicationConfig = {
  providers: [
    provideExperimentalZonelessChangeDetection(),
    […]
  ]
}

Da zone.js die Change Detection nicht mehr triggert, braucht Angular andere Auslöser. Dabei handelt es sich um jene, die auch im Datenbindungsmodus OnPush zum Einsatz kommen:

• Ein mit der async Pipe gebundenes Observable veröffentlicht einen neuen Wert.
• Ein gebundenes Signal veröffentlicht einen neuen Wert.
• Die Objektreferenz eines Inputs ändert sich.
• Ein UI Event mit gebundenem Event Handler tritt auf (z. B. click).
• Die Anwendung triggert die Change Detection manuell.

Das bedeutet, dass jene, die in der Vergangenheit bereits konsequent auf OnPush gesetzt haben, nun relativ problemlos auf Zoneless wechseln können. In Fällen, in denen das nicht einfach möglich ist, kann die Anwendung ohne Bedenken zone.js-basiert bleiben. Das Angular-Team geht davon aus, dass nicht jede bestehende Anwendung auf Zoneless umgestellt wird und unterstützt deswegen zone.js weiterhin.

Für neue Anwendungen bietet sich jedoch das Arbeiten ohne zone.js an, sobald dieser neue Modus nicht mehr experimentell ist. Die geplanten Signal Components werden künftig Zoneless-Anwendungen einfacher machen, da sie durch den konsequenten Einsatz von Signals die Voraussetzungen dafür automatisch erfüllen.

Nach einer Umstellung auf Zoneless lässt sich auch der Verweis auf zone.js aus der angular.json entfernen. Durch den Wegfall dieser Bibliothek werden die Bundles im Production Mode um ca. 11 KB kleiner.

Coalescing Zone

Für neue Anwendungen nutzt das Angular CLI nach wie vor zone.js. Neu ist, dass es nun Code generiert, der standardmäßig Event Coalescing aktiviert:

export const appConfig: ApplicationConfig = {
  providers: [
    provideZoneChangeDetection({ eventCoalescing: true }),
    […]
  ]
};

Event Coalescing bedeutet, dass zone.js für unmittelbar aufeinanderfolgende Events nur ein einziges Mal tätig wird. Als Beispiel nennt das Angular-Team mehrere Click Handler, die aufgrund von Event Bubbling hintereinander angestoßen werden.

Neuerungen bei Router Redirects

Möchte ein Guard eine Umleitung auf eine andere Route veranlassen, liefert er den UrlTree dieser Route zurück. Im Gegensatz zur Methode navigate erlaubt dieser Ansatz jedoch nicht die Angabe von Optionen zur detaillierten Steuerung des Routerverhaltens. Beispielsweise kann die Anwendung nicht festlegen, ob der aktuelle Eintrag in der Browser-History zu überschreiben ist oder ob Parameter, die nicht in dem URL aufscheinen sollen, zu übergeben sind.

Um diese Möglichkeit zu nutzen, kann ein Guard nun auch ein RedirectCommand zurückliefern. Dieses RedirectCommand nimmt neben dem UrlTree ein Objekt vom Typ NavigationBehaviorOptions entgegen, welches das gewünschte Verhalten steuert (Listing 1).

Listing 1

export function isAuth(destination: ActivatedRouteSnapshot) {
  const router = inject(Router);
  const auth = inject(AuthService);

  if (auth.isAuth()) {
    return true;
  }

  const afterLoginRedirect = destination.url.join('/');
  const urlTree = router.parseUrl('/login');

  return new RedirectCommand(urlTree, {
    skipLocationChange: true,
    state: {
      needsLogin: true,
      afterLoginRedirect: afterLoginRedirect
    } as RedirectToLoginState,
  });
}

export const routes: Routes = [
  {
    path: '',
    redirectTo: 'products',
    pathMatch: 'full'
  },
  {
    path: 'products',
    component: ProductListComponent,
  },
  {
    path: 'login',
    component: LoginComponent,
  },
  {
    path: 'products/:id'
    component: ProductDetailComponent,
    canActivate: [isAuth]
  },
  {
    path: 'error',
    component: ErrorComponent
  }
];

Die Eigenschaft skipLocationChange gibt an, dass der Routenwechsel nicht in der Browser-History aufscheinen soll, und beim angegeben State handelt es sich um Werte, die an die zu aktivierende Komponente zu übergeben sind, jedoch nicht in dem URL aufscheinen sollen. Weitere Eigenschaften, die NavigationBehaviorOptions bietet, finden sich unter [2].

Der Vollständigkeit halber zeigt Listing 2 die adressierte Komponente, die die übergebenen Daten ausliest.

Listing 2

@Component({ … })
export class LoginComponent {
  router = inject(Router);
  auth = inject(AuthService);

  state: RedirectToLoginState | undefined;

  constructor() {
    const nav = this.router.getCurrentNavigation();

    if (nav?.extras.state) {
      this.state = nav?.extras.state as RedirectToLoginState;
    }
  }

  logout() {
    this.auth.logout();
  }

  login() {
    this.auth.login('John');
    if (this.state?.afterLoginRedirect) {
      this.router.navigateByUrl(this.state?.afterLoginRedirect);
    }
  }

}

Der Einsatz eines RedirectCommands wird nun auch durch das optionale Feature withNavigationErrorHandler unterstützt. Dieses Feature, das das Festlegen eines Handlers zur Behandlung von Routerfehlern erlaubt, kann nun damit das Verhalten des Routers steuern (Listing 3).

Listing 3

export function handleNavError(error: NavigationError) {
  console.log('error', error);

  const router = inject(Router);
  const urlTree = router.parseUrl('/error')
  return new RedirectCommand(urlTree, {
    state: {
      error
    }
  })
}

export const appConfig: ApplicationConfig = {
  providers: [
    […]
    provideRouter(
      routes,
      withComponentInputBinding(),
      withViewTransitions(),
      withNavigationErrorHandler(handleNavError),
    ),
  ]
};

Eine weitere Neuerung in Sachen Redirects betrifft die Eigenschaft redirectTo in der Routerkonfiguration. Bis jetzt konnte man auf den Namen einer anderen Route verweisen. Nun nimmt diese Eigenschaft auch eine Funktion auf, die sich programmatisch um die Weiterleitung kümmert (Listing 4).

Listing 4

export const routes: Routes = [
  {
    path: '',
    redirectTo: () => {
      const router = inject(Router);
      // return 'products' // Alternative
      return router.parseUrl('/products');
    },
    pathMatch: 'full'
  },
  […],
];

Der Rückgabewert dieser Funktion ist entweder ein UrlTree oder ein String mit dem Pfad der gewünschten Route.

Standardinhalte für Content Projection

Das Element ng-content, das Angular als Ziel für die Content Projection nutzt, kann nun einen Standardinhalt aufweisen. Diesen Inhalt zeigt Angular an, wenn der Aufrufer keinen anderen Inhalt übergibt:

<div class="pl-10 mb-20">
  <ng-content>
    <b>Book today to get 5% discount!</b>
  </ng-content>
</div>

Standardinhalte für Content Projection

Das AbstractControl, das u. a. als Basisklasse für FormControl und FormGroup fungiert, weist nun eine Eigenschaft events auf. Dieses Observable informiert über zahlreiche Zustandsänderungen (Listing 5).

Listing 5

export class ProductDetailComponent implements OnChanges {

  […]

  formControl = new FormControl<number>(1);

  […]

  constructor() {
    this.formControl.events.subscribe(e => {
      console.log('e', e);
    });
  }

  […]

}

Die einzelnen Events veröffentlicht es als Objekte vom Typ ControlEvent. Bei ControlEvent handelt es sich um eine abstrakte Basisklasse mit den folgenden Ausprägungen:

• FormResetEvent
• FormSubmittedEvent
• PristineChangeEvent
• StatusChangeEvent
• TouchedChangeEvent
• ValueChangeEvent

Event Replay für SSR

Durch den Einsatz von Server-side Rendering bekommen Aufrufer:innen rascher die angeforderte Seite angezeigt. Danach beginnt der Browser mit dem Laden der JavaScript Bundles, die die Seite erst interaktiv machen. Dieser Vorgang wird auch Hydration genannt. Abbildung 1 veranschaulicht das: FMP steht für „First Meaningful Paint“ und TTI für „Time to Interactive“.

Abb. 1: Uncanny Valley bei SSR

Besondere Beachtung erfordert die Zeitspanne zwischen FMP und TTI, auch bekannt als „Uncanny Valley“. Benutzer:innen bekommen hier die Seite bereits angezeigt, das JavaScript, das auf Benutzerinteraktionen reagiert, ist jedoch noch nicht geladen. Klicks und andere Interaktionen laufen also ins Leere.

Um das zu verhindern, bietet Angular nun Event Replay, das die Interaktionen im Uncanny Valley aufzeichnet und danach wiedergibt. Möglich wird das durch ein minimales Skript, das der Browser initial gemeinsam mit der vorgerenderten Seite lädt.

Event Replay kommt als optionales Feature für provideClientHydration und wird mit der Funktion withEventReplay eingebunden (Listing 6).

Listing 6

export const appConfig: ApplicationConfig = {
  providers: [
    […],
    provideClientHydration(
      withEventReplay()
    )
  ]
};

Die Implementierung von Event Replay hat sich bei Google schon länger bewährt. Sie stammt aus dem Google-internen Framework Wiz [3], das für seine Fähigkeiten im Bereich SSR und Hydration bekannt ist und deswegen für performancekritische öffentliche Lösungen zum Einsatz kommt.

Auf der diesjährigen ng-conf hat das Angular-Team bekannt gegeben, dass künftig die Angular- und Wiz-Teams verstärkt zusammenarbeiten werden. In einem ersten Schritt nutzt das Wiz-Team die aus Angular stammenden Signals während Angular die erprobten Möglichkeiten zu Event Replay vom Wiz-Team übernommen hat.

Automatischer TransferState für HTTP-Anfragen

Beim Einsatz von SSR cacht der HttpClient schon länger die Ergebnisse serverseitig durchgeführter HTTP-Anfragen, sodass die Anfragen im Browser nicht nochmal ausgeführt werden müssen. Dazu kommt ein Interceptor zum Einsatz, der sich auf das TransferState API stützt. Dieses API bettet die gecachten Daten im Markup der vorgerenderten Seite ein und im Browser greift u. a. der HttpClient darauf zu.

Nun berücksichtigt diese Implementierung auch, dass serverseitig andere URLs als im Browser zum Einsatz kommen können. Dazu lässt sich ein Objekt konfigurieren, das interne, serverseitige URLs auf die URLs für den Einsatz im Browser abbildet. Listing 7 veranschaulicht die Konfiguration dieses Objekts mit einem Beispiel, das aus dem Change-Log [4] übernommen wurde.

Listing 7

// in app.server.config.ts
{
  provide: HTTP_TRANSFER_CACHE_ORIGIN_MAP,
  useValue: {
    'http://internal-domain:80': 'https://external-domain:443'
  }
}

// Alternative usage with dynamic values
// (depending on stage or prod environments)
{
  provide: HTTP_TRANSFER_CACHE_ORIGIN_MAP,
  useFactory: () => {
    const config = inject(ConfigService);
    return {
      [config.internalOrigin]: [config.externalOrigin],
    };
  }
}

Außerdem platziert der HttpClient nun die Resultate serverseitiger HTTP-Anfragen, die einen Authorization- oder Proxy-Authorization-Header enthalten, nicht mehr automatisch im TransferState. Wer solche Resultate auch künftig cachen möchte, nutzt die neue Eigenschaft includeRequestsWithAuthHeaders:

withHttpTransferCache({
  includeRequestsWithAuthHeaders: true,
})

DevTools und Hydration

Die Angular DevTools zeigen nun auf Wunsch an, welche Komponenten bereits hydriert wurden. Dazu ist rechts unten die Option Show hydration overlays zu aktivieren (Abb. 2).

Abb. 2: Die DevTools zeigen nun an, welche Komponenten bereits hydriert wurden

Diese Option versieht alle hydrierten Komponenten mit einem blau-transparenten Overlay und zeigt rechts oben zusätzlich ein Wassertropfenicon an.

Migration auf den neuen ApplicationBuilder

Der neue ApplicationBuilder wurde bereits mit Angular 17 eingeführt und automatisch für neue Angular-Anwendungen eingerichtet. Da er auf modernen Technologien wie esbuild basiert, ist er um einiges schneller als der ursprüngliche, webpack-basierte Builder, den Angular nach wie vor unterstützt. Bei ersten Tests konnte ich eine Beschleunigung um den Faktor 3 bis 4 feststellen. Außerdem kommt der ApplicationBuilder mit einer komfortablen Unterstützung für SSR.

Beim Update auf Angular 18 schlägt das CLI nun vor, auch bestehende Anwendungen auf den ApplicationBuilder umzustellen (Abb. 3).

Abb. 3: Das Update auf Version 18 bietet die Migration auf den neuen ApplicationBuilder an

Da das CLI-Team viel Aufwand in Featureparität zwischen der klassischen und der neuen Implementierung investiert hat, sollte diese Umstellung in den meisten Fällen gut funktionieren und die Build-Zeiten drastisch beschleunigen. Auf jeden Fall sollten aber nach der Umstellung die Anwendung sowie der Build auf Funktionstüchtigkeit geprüft werden.

Weitere Neuerungen

Neben den bereits beschriebenen Neuerungen gibt es noch einige kleinere Updates und Verbesserungen:

• @defer funktioniert auch in npm Packages.
• Ein neues Token HOST_TAG_NAME zeigt auf den Tagnamen der aktuellen Komponente.
• Angular I18N spielt nun mit Hydration zusammen.
• Die Module HttpClientModule, HttpClientXsrfModule und HttpClientJsonpModule, sowie das HttpClientTestingModule sind nun deprecated. Als Ersatz kommen die entsprechenden Standalone APIs wie provideHttpClient zum Einsatz. Ein Schematic kümmert sich automatisch um diese Umstellung beim Update auf Angular 18.
• Für neue Projekte richtet nun das CLI einen public-Ordner anstatt eines assets-Ordners ein. Damit möchte sich das Angular-Team an eine allgemeine Gepflogenheit in der Welt der Webentwicklung annähern.
• Für Zoneless-Anwendungen wandelt das CLI async und await nicht mehr in Promises um. Beim Einsatz von zone.js ist das notwendig, da sich Promises monkey-patchen lassen.
• Der ApplicationBuilder cacht nun Zwischenergebnisse. Damit lassen sich die folgenden Builds drastisch beschleunigen.

Zusammenfassung

Nach mehreren Releases mit vielen neuen Features steht bei Angular 18 vor allem das Abrunden von Ecken im Vordergrund. Es gibt neue Möglichkeiten für Router Redirects, Standardwerte für Content Projection, Event Replay und Verbesserungen bei der Nutzung des TransferState für HTTP-Anfragen. Daneben wurden zahlreiche Bugs behandelt und die Performance des neuen ApplicationBuilder durch Caching verbessert. Außerdem gibt es einen Ausblick auf Zoneless Angular.

Links & Literatur

[1] https://github.com/manfredsteyer/hero-shop.git

[2] https://angular.dev/api/router/NavigationBehaviorOptions

[3] https://blog.angular.dev/angular-and-wiz-are-better-together-91e633d8cd5a

[4] https://github.com/angular/angular/pull/55274

The post Kolumne: Enterprise Angular appeared first on BASTA!.

Als Arbeitsumgebung kommt wie immer eine Windows-10-Zweischirmworkstation zum Einsatz; die hier benutzte Version von Visual Studio Community 2022 identifizierte sich als 17.10.0.P2.

Zu guter Letzt sei noch darauf hingewiesen, dass Visual Studio selbstständig über Neuerungen informiert. Wer im Benutzerinterface die Option Hilfe | Neuigkeiten anklickt, findet eine kompakte Liste neuer Funktionen, die Microsoft als besonders wichtig erachtet (Abb. 1).

Abb. 1: Visual Studio zeigte sich durchaus auskunftsfreudig

Wie immer gilt übrigens, dass die produktive Nutzung von Preview-Releases von Microsoft nicht gerne gesehen wird. Im Unternehmen des Autors ist sie allerdings seit Jahren gelebte Praxis; außerdem ist der Visual Studio Installer immer bereit, eine normale und eine Vorschau-Variante des Produkts nebeneinander auf dem gleichen Terminal zu installieren.

AI-Unterstützung mit und ohne Abonnement

Eins der beeindruckendsten Features von Visual Studio 2022 war die wesentliche Verbesserung von IntelliSense: Insbesondere auf Systemen mit sehr hoher Einkernleistung und schneller Internetverbindung ist die IDE stellenweise zum Finden von geradezu genialen Auto-Completition-Vorschlägen befähigt.

Aufgrund des Kaufs von GitHub hat Microsoft seit einiger Zeit Zugriff auf ein gigantisches Archiv von Quellcode, der seit einiger Zeit zur Realisierung einer als GitHub Copilot bezeichneten Funktion herangezogen wird. Angemerkt sei, dass es sich dabei um ein kostenpflichtiges Feature handelt – Abbildung 2 zeigt die unter [2] bereitstehende Preisliste.

Abb. 2: Microsoft lässt sich die Nutzung von AI-Funktionen in Visual Studio vergolden

Wer sich ein diesbezügliches Abonnement leistet und die Umbenennen-Refactoring-Funktion heranzieht, findet bei installierter GitHub-Copilot-Chat-Erweiterung eine zusätzliche Schaltfläche vor. Deren Anklicken nutzt dann den AI-Assistenten zur Generierung eines vernünftig erscheinenden Namens für das neue Element.

Eine ähnliche Komfortfunktion findet sich auch im Git-Commit-Fenster. Die insbesondere im universitären Umfeld oft für Ärger sorgenden Commits generiert ein mit einer Copilot-Subskription ausgestattetes VS ebenfalls automatisch.

Abb. 3: Visual Studio generiert auf Wunsch automatische Messages

Abb. 4: Die automatisch generierte Commit-Message

Allgemein gilt dabei übrigens, dass das Aufscheinen des mit zwei Sternen dekorierten Bleistiftsymbols auf das Verfügbarsein von AI-Funktionen hinweist: Microsoft dürfte Copilot in immer mehr Bereiche erweitern, um Entwickler:innen das Erzeugen von unnötigen oder nur als Dokumentation dienenden Strings zu ersparen und so Lebenszeit zurückzugeben.

Hervorzuheben ist außerdem, dass die Funktion „Explain Commit“ von GitHub Copilot auch nachträglich verwendet werden kann. Visual Studio analysiert in diesem Fall die im Versionskontrollsystem befindlichen Informationen und generiert einen menschenlesbaren Bericht über die (wahrscheinlich) durchgeführten Änderungen an der Codebasis.

Angemerkt sei, dass man im Hause Microsoft langfristig noch weitere Funktionen für Copilot avisiert. Unter [3] findet sich beispielsweise eine Passage, in der Microsoft die automatische Analyse von Unit-Test-Fehlschlägen verspricht (Abb. 5)

Abb. 5: Ein hochgestecktes Versprechen – fraglich, ob Microsoft es auch umsetzen kann

Intelligente Suche nach Code

Ein alter Kalauer besagt, dass die Unübersichtlichkeit einer Codebasis kubisch oder sogar exponentiell mit ihrer Größe wächst. Auf jeden Fall gilt, dass vernünftige Such- und Navigationsverfahren eins der besten Verkaufsargumente für integrierte Entwicklungsumgebungen darstellen.

Neben der durch Drücken von STRG + SHIFT + F aktivierbaren stupiden Textsuche stellt Microsoft seit einiger Zeit auch einen alternativen Suchassistenten zur Verfügung, der bei der Bewertung der gefundenen Ergebnisse Informationen über die jeweiligen Codedateien miteinbezieht. Diese auch als Codesuche bezeichnete Funktion lässt sich durch Drücken von STRG +T aktivieren, und erscheint ebenfalls in einem Pop-up-Fenster. Neu ist hier die Möglichkeit, die Textfunktion durch Drücken des Knopfes zu aktivieren (Abb. 6).

Abb. 6: Die Codesuche bekommt in Visual Studio 17.9 ein Sonderregime eingeschrieben

Sollte diese Funktion auf Ihrer Installation noch nicht zur Verfügung stehen, so lässt sich in den Einstellungen unter Tools | Options | Environment | Preview Features | Plain text search in die All-in-One Search aktivieren. Zu beachten ist außerdem, dass die Aktivierung des Sonderregimes zu einer wesentlichen Vertiefung der Ergebnisse führt – die Codesuche kann in diesem Fall beispielsweise auch Kommentare nach Treffern durchforsten.

Erweiterungen im Text-Rendering zwecks höherer Übersichtlichkeit

Farbliches Hervorheben ist einer der schnellsten Wege, um textuelle Informationen für das menschliche Gehirn besser erfassbar zu machen (das dürfte spätestens seit Tim van Beverens Klassiker „Runter kommen sie immer“ im allgemeinen Wissensschatz der GUI-Designer und Elektroniker verankert sein).

Seit Visual Studio 2019 pflegt die Community dabei einen Feature-Request, der eine eher kleine Erweiterung der Textdarstellung von Visual Studio zum Ziel hat. Spezifisch wünscht man sich die Möglichkeit, Kommentare und ähnliche Elemente nicht nur in einer anderen Schriftart oder Farbe, sondern auch kursiv, fett und/oder unterstrichen darstellen zu lassen.

In den Einstellungen findet sich unter Tools | Options | Environment | Fonts and Colors nun das in Abbildung 7 gezeigte Einstellungsfenster: Wer die Checkbox Kursiv (bzw. in der englischen Version Italic) aktiviert, bekommt den jeweiligen Text fortan kursiv angezeigt.

Abb. 7: Kleine Erweiterungen erhöhen die Übersichtlichkeit

Eine weitere Komfortfunktion ermöglicht das direkte Anzeigen von Bildvorschauen. Wo Sie den Cursor über ein Codeelement legen, das ein Bild anzeigt, erscheint das in Abbildung 8 gezeigte Pop-up. Im Interesse der Übersichtlichkeit beschneidet Microsoft die Breite und Höhe des Thumbnails dabei auf 500 Pixel; zum Zeitpunkt der Erstellung dieses Artikels gibt es noch keine Informationen darüber, welche Arten von Bilddaten der in Visual Studio integrierte Parser auswerten kann.

Abb. 8: Der Vorschauassistent informiert über den Bildinhalt

Verbesserte Erweiterungshandhabung in Visual Studio

Start-ups, die ihren Nutzer:innen kein Visual-Studio-Code-Plug-in anbieten, haben bei der Akquise von „other people’s money“ im Allgemeinen ihre liebe Not. Visual Studio bietet seit längerer Zeit einen Erweiterungsmanager an, der in der Vergangenheit allerdings vergleichsweise staubig wirkte und von der immensen Macht der Funktion ablenkte.

Der in 17.8 erstmals eingeführte neue Extension-Manager ist nun final und erleichtert die Verwaltung von Visual-Studio-Erweiterungen an mehrerlei Stelle. Abbildung 9 zeigt dabei einen Überblick des neuen Designs.

Abb. 9: Der Erweiterungsmanager präsentiert sich neuerdings sehr aufgeräumt

VisualStudio.Extensibility

Neben dem neuen Design ist auch das Filtersteuerelement zu beachten. Klickt man das Trichtersymbol an, so reagiert Visual Studio mit der Einblendung von Comboboxen unter dem Eingabefeld. Diese ermöglichen danach das Einschränken der angezeigten Erweiterungen, um nur bestimmte Expansions zuzulassen – die Abbildung entstand durch Selektion auf Steuerelemente auf Basis der Silverlight-Technologie.

Im Hintergrund führte Microsoft Retoolings im Bereich der Erweiterungsinfrastruktur durch. Man mag es nach dem Debakel um den Home Screen des Pocket PC kaum glauben, allerdings führte Visual Studio Erweiterungen bisher im eigentlichen Prozess der integrierten Entwicklungsumgebung aus.

Mit dem unter [4] im Detail dokumentierten Paket VisualStudio.Extensibility versucht Microsoft nun einen radikalen Neuanfang. Es handelt sich dabei um einen neuen Weg zur Programmierung von Plug-ins für Visual Studio, die dank einer Client-Server-Architektur außerhalb des VS-Prozesses leben. Neben der Möglichkeit zur beliebigen Parallelisierung dürfte das naturgemäß auch mit einer Steigerung der Stabilität einhergehen; Erweiterungen sollten nicht mehr in der Lage seien, Visual Studio als Ganzes zum Absturz zu bringen.

In Version 17.9 erfährt dieses neue Interface mehrere Nutzwertsteigerungen: Erstens ist es ab sofort erlaubt, auf Basis der neuen Technologie erzeugten Erweiterungen zwecks Verbreitung in den Visual Studio Marketplace hochzuladen.

Eine zweite Ergänzung, die logisch aus dem externen Hosting der Erweiterungsprozesse folgt, ist ihre vereinfachte Installation. Der bisher notwendige Neustart von Visual Studio entfällt bei Nutzung von auf VisualStudio.Extensibility basierenden Erweiterungen, weil diese einfach ihren externen Prozess starten und Verbindung mit dem von der integrierten Entwicklungsumgebung zur Verfügung gestellten Interface aufnehmen.

Zu guter Letzt gibt es einige Erweiterungen im Bereich der für Plug-ins auslösbaren Aktionen. Abbildung 10 informiert beispielsweise darüber, dass es fortan durch nach folgendem Schema aufgebauten Code erlaubt ist, eine Rekompilation eines in der Solution befindlichen Projekts zu befehligen:

var result = await this.Extensibility.Workspaces().QueryProjectsAsync(

  project => project.Where(p => p.Name == projectName),

  cancellationToken);

await result.First().BuildAsync(cancellationToken);

Abb. 10: Erweiterungen dürfen nun Projektereignisse auslösen

Handhabung des Speicherbedarfs und Performanceprobleme des Emulators

Apropos Visual Studio Installer: Wer auf einer Workstation mit wenig Speicherplatz entwickelt, ist gut beraten, die Checkbox empfohlene Komponenten beim Update hinzufügen zu deaktivieren (Abb. 11).

Microsoft nimmt sich in Visual Studio  7.10 bzw. im dazugehörigen Visual Studio Installer das Recht heraus, Workstations automatisch mit in Redmond als empfehlenswert empfundenen Komponenten auszustatten – dass diese mitunter viel Speicherplatz verbrauchen, sei angemerkt.

Abb. 11: Wer Speicher sparen möchte, sollte diese Option berücksichtigen

Ein weiteres dauerndes Ärgernis betrifft die Hardwarebeschleunigung für den Android-Emulator: Ist sie deaktiviert, so artet das virtualisierte Testen von Applikationen in nervtötende Warterei aus. Visual Studio ist in aktuellen Versionen zur Erkennung von Performanceproblemen befähigt, und führt Entwickler:innen so zum Ziel.

Erleichterte Verwaltung der Optionen

Neben dem Streamlining im Erweiterungsmanager möchte Microsoft Entwickler:innen auch dabei helfen, die (immer mächtiger werdende) Flut an Settings in der Visual-Studio-Arbeitsoberfläche angenehmer zu verwalten. So ist ein Redesign des beispielsweise in Abbildung 12 gezeigten Einstellungsdialogs avisiert – als Inspirationsquelle dürfte, wie in der Vergangenheit so oft, Visual Studio Code gedient haben.

Vor der praktischen Besprechung dieses Features sei allerdings angemerkt, dass es sich dabei derzeit um eine frühe Preview handelt. Für Sie als Entwickler:in wirkt sich das unter anderem insofern aus, als Microsoft in der Dokumentation an mehrerlei Stelle darauf hinweist, dass der Gutteil der Features derzeit nur in altem Dialog zur Verfügung steht. Wer verzweifelt nach einer Einstellung sucht und diese nicht findet, ist gut beraten, der älteren Variante eine zweite Chance zu geben.

Zum Zeitpunkt der Drucklegung lässt sich die Variante des zu verwendenden Options-Dialogs unter Extras | Optionen Experience auswählen – Abbildung 12 zeigt die etwas holprige Übersetzung aus dem Hause Microsoft.

Abb. 12: An dieser Stelle ist etwas Nachbesserung vernünftig

Wer die aktualisierte Variante des Einstellungsdialogs zu verwenden gedenkt, sollte im ersten Schritt die Option Vorschau auswählen. Die integrierte Entwicklungsumgebung reagiert darauf mit der Einblendung eines Nachfragedialogs, der um die Autorisierung eines Neustarts bittet – aufgrund der doch erheblichen Änderungen ist Microsoft derzeit nicht in der Lage, die Umstellung in einer laufenden Instanz von Visual Studio durchzuführen.

Im nächsten Schritt lässt sich der Options-Dialog öffnen, was zum Aufscheinen des in Abbildung 13 gezeigten Fensters führt.

Abb. 13: Visual Studio Code sendet Grüße an die Vollversion

Die oben links eingeblendete Textbox erlaubt dann das Eingeben von Strings, die Visual Studio zur Einschränkung der angezeigten Optionsvielfalt heranzieht.

Interessant ist allerdings auch, dass Visual Studio bei Cursorberührung ein Zahnrad mit zusätzlichen Einstellungen zur jeweiligen Option anbietet. Wer dieses anklickt, bekommt ein Menü mit zwei Optionen eingeblendet: Neben einem bequemen Weg zum Wiederherstellen der von Microsoft vorgegebenen Standardeinstellungen ist es hier auch möglich, Feedback an Microsoft zu schicken. Besonders wünscht man sich in Redmond dabei Hinweise dazu, wie sich die Beschreibung der jeweiligen Funktion entwickler- bzw. benutzerfreundlicher gestalten lassen würde.

Vereinheitlichungen und QOL-Verbesserungen für GUI-Entwickler

Im Umfeld des Autors gibt es einige Beratungsunternehmen, die den Umstieg auf Visual Studio 2022 verweigert haben – Ursache dafür ist die schlechtere Integration des Windows-Forms-Designers in die neue Variante der IDE. Ursache dafür ist, dass Visual Studio 2022 im Interesse der besseren Performance als 64-Bit-Applikation vorliegt und dementsprechend naturgemäß mit dem 32-Bit-Forms-Designer nur wenig anzufangen weiß.

Microsoft begegnet diesem Problem seit einiger Zeit mit einem externen Windows-Forms-Designer, der sein nützliches Tun abseits des Hauptprozesses bewerkstelligt. In der aktuellen Version nahm Microsoft Verbesserungen vor, um dem laut Dokumentation nach wie vor weit von Featureparität entfernten Editor eine höhere Performance zu ermöglichen.

Neuerung Nummer zwei betrifft eine als „Live Property Explorer“ bezeichnete Funktion: Dieses bei der Arbeit mit gewöhnlichen XAML-Dateien liebgewonnene Feature steht ab sofort auch dann zur Verfügung, wenn das vorliegende Programm auf Basis des neuen MAUI-GUI-Stacks entsteht.

Während dem Debuggen einer MAUI-Applikation lässt sich das Werkzeug durch Drücken von Debug | Windows | Live Property Explorer aktivieren. Es verhält sich dann im Allgemeinen so, wie man es als Entwickler:in von der gewöhnlichen Version der IDE erwarten würde.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Auf Jagd nach Featureparität für ARM

Dass Aktualisierungen von Visual Studio seit jeher mit einem wahren Sperrfeuer von Updates der zugrunde liegenden Komponenten einhergehen, wird erwartet – die Installation von Visual Studio setzt nun beispielsweise das .NET Framework in Version 4.7 voraus. Besonders interessant ist in diesem Zusammenhang aber die (an sich seit einiger Zeit zur Verfügung stehenden) Variante der integrierten Entwicklungsumgebung für Workstations, die auf ARM-Prozessoren basieren.

Bisher waren Nutzer:innen dieser neuartigen Variante des Produkts von der Verwendung der als SQL Server Developer Tools (SSDT) bezeichneten Komponente für die SQL-Datenbankanalyse ausgeschlossen – ein Problem, das Microsoft nun behoben hat. In der Dokumentation weisen die Redmonder allerdings darauf hin, derzeit noch keine vollständige Featureparität erreicht zu haben – einige fortgeschrittene Features stehen also nach wie vor nur auf X64-Stationen zur Verfügung.

Allgemeine Verbesserungen der Lebensqualität für C++ und C#

Wer viele Codedateien gleichzeitig geöffnet hält, lernt irgendwann das Scrollen durch die Tab-Liste. Microsoft verbessert diesen Teil des Systems insofern, als es nun auf Wunsch auch möglich ist, mehrere Zeilen mit Tab-Headern auf dem Bildschirm zu halten.

Nutzer:innen der Spiele-Engine Unreal bekommen eine Erweiterung von IntelliSense serviert: Die Codevervollständigung interagiert nun auch mit per Unreal-Header-Tool generierten Dateien, was die Reichhaltigkeit der angezeigten Auto-Completion-Vorschläge erhöht.

Mindestens ebenso hilfreich ist die Möglichkeit, die von Visual Studio als Standard verwendete CMake-Version durch eine hauseigene Variante zu ersetzen. Hierzu findet sich unter Tools | Options | CMake | General ein Einstellungsfenster, in dem sich der von der Toolchain verwendete Pfad zur CMake-EXE austauschen oder anpassen lässt.

Besondere Erwähnung verdient auch die Fähigkeit der IDE, Structs dynamisch (also ohne Rekompilation) in Form eines Speicherlayouts anzuzeigen (Abb. 14).

Abb. 14: Visual Studio zeigt die Struktur des Speicherlayouts an

Aufseiten der C#-Entwicklung gibt es Snippetsupport für Razor: Dabei handelt es sich um ein an die in Palm OS implementierten Shortcuts erinnerndes Feature, das das Einpflegen von hauseigenen Codestücken optimiert.

Außerdem steht mit Blazor Scaffolding ein vergleichsweise umfangreicher Codegenerator zur Verfügung. Er erzeugt auf Data Binding basierende Views automatisiert, was bei Einarbeitung und Umstieg Zeit spart.

Integration ins Microsoft-Ökosystem

Im Rahmen der Ankündigung von Visual Studio 17.10 Preview 1 betonte Microsoft mehrfach die neuen Möglichkeiten des Teams SDK: Wir haben es in unserem oben erwähnten Artikel [1] im Detail beschrieben, weshalb an dieser Stelle nur ein knapper Verweis ausreichen muss.

Interessant ist, dass Microsoft die Hoffnung auf das Verkaufen der kostenpflichtigen Versionen Visual Studio Professional und Visual Studio Enterprise auch nach dem durchschlagenden Erfolg der kostenfreien Community-Variante nicht komplett aufgegeben hat.

Der beste Beleg für diese Annahme ist das unter [5] bereitstehende und in Abbildung 15 gezeigte Portal. Besitzer:innen kostenpflichtiger Varianten bekommen von Microsoft dort einen kompakten Überblick über alles, was sie an Side Benefits im Rahmen ihres Abonnements angeboten bekommen.

Abb. 15: Der Microsoft-Weihnachtsmann bringt Geschenke

Fazit

Microsofts Entscheidung, mit Visual Studio und Visual Studio Code interne Konkurrenz zu erzeugen, trägt für die Entwicklerschaft reiche Dividende. Die Preview-Versionen von Visual Studio greifen Entwickler:innen an mehrerlei Stelle unter die Arme, ohne dabei lästig zu werden. Die Empfehlung des Autors für das neueste Produkt aus Redmond sei deshalb jederzeit gegeben.

Links & Literatur

[1] https://entwickler.de/reader/reading/windows-developer/4.2023/65722e67d1045fe264c26ad9?searchterm=visual%20studio

[2] https://github.com/features/copilot?utm_source=vscom&utm_medium=hero&utm_campaign=cta-get#pricing

[3] https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-roadmap

[4] https://learn.microsoft.com/de-de/visualstudio/extensibility/visualstudio.extensibility/visualstudio-extensibility?view=vs-2022

[5] https://my.visualstudio.com

The post Neuerungen in Visual Studio appeared first on BASTA!.

.NET 9.0 Preview 1 ist am 13. Februar 2024 erschienen und am 12. März 2024 folgte Preview 2. Die Vorschauversionen stehen zum Download unter [1] bereit.

An der Grundstruktur (drei Runtimes, ein SDK) hat sich nichts geändert (Abb. 1) und auch die unterstützten Plattformen sind gleichgeblieben. Laut Abbildung 1 sind weiterhin die Sprachversionen C# 12.0, F# 8.0 und Visual Basic .NET 16.9 enthalten – neue Sprachfeatures gibt es demnach bisher noch nicht.

Abb. 1: .NET-9.0-Downloads

Neuerungen im .NET 9.0 SDK

Das Befehlszeilenwerkzeug dotnet test konnte bisher automatisierte Tests für ein Projekt mit mehreren .NET-Versionen nacheinander ausführen (z. B. <TargetFrameworks>net8.0;net9.0</TargetFrameworks> in der Projektdatei des Testprojekts). Eine neue Funktion in .NET 9.0 Preview 2 ist, dass diese Ausführung für verschiedene .NET-Versionen nun parallel erfolgt (Abb. 2). Außerdem nutzt dotnet test den Terminal Logger, der in .NET 8.0 eingeführt wurde und eine übersichtlichere Darstellung bietet. Das hat insbesondere positive Auswirkungen auf die Anzeige der Testergebnisse sowohl während als auch nach der Testausführung (Abb. 3). Bei Bedarf kann die Parallelisierung verhindert werden, indem man die MSBuild-Eigenschaft TestTfmsInParallel auf false setzt.

Abb. 2: Parallele Testausführung für mehrere .NET-Versionen

Abb. 3: Übersichtlichere Testergebnisse

Nutzer:innen von .NET-SDK-basierten Tools haben nun die Möglichkeit, mit der Option —allow-roll-forward ein Werkzeug auf einer neueren .NET-Hauptversion laufen zu lassen, falls die .NET-Laufzeitumgebung, für die das Werkzeug eigentlich kompiliert wurde, nicht auf dem lokalen System verfügbar ist. Diese neue Option kann sowohl bei der Installation mit dotnet tool install als auch beim Ausführen mit dotnet tool run verwendet werden. Es muss jedoch darauf hingewiesen werden, dass aufgrund von Breaking Changes zwischen .NET-Hauptversionen keine Garantie besteht, dass das Werkzeug ordnungsgemäß auf einer neueren .NET-Laufzeitumgebung funktioniert.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Neuerungen in der .NET-Klassenbibliothek

In der Basisklassenbibliothek wurden neue LINQ-Operatoren CountBy() und Index() hinzugefügt. CountBy() vermeidet den bisher notwendigen Einsatz von GroupBy() in Fällen, in denen nach Häufigkeit gruppiert werden soll (Listing 1). Index() liefert für ein IEnumerable<T> ein Tupel mit dem Wert und dem laufenden Index (0 bis n) zurück (Listing 2). Abbildung 4 zeigt die Ausgabe, bei der die Zusatzbibliothek SpectreConsole für die Balkenausgabe zum Einsatz kommt [2].

Listing 1: Ermitteln der häufigsten Vorname mit CountBy()

#region ---------------- Demodaten erstellen
  int count = 10000;
  CUI.H3($"Generiere {count} Demodaten...");
  Randomizer.Seed = new Random(42); // für gleichbleibende Testdaten!
  var personFaker = new AutoFaker<Person>("de")
    .RuleFor(fake => fake.ID, fake => fake.Random.Int(0))
    .RuleFor(fake => fake.Givenname, fake => fake.Name.FirstName())
    .RuleFor(fake => fake.Surname, fake => fake.Name.LastName())
    .RuleFor(fake => fake.Birthday, fake => fake.Date.Past(100).Date);
  List<Person> personSet = new();
  for (int i = 0; i < count; i++)
  {
    var p = personFaker.Generate();
    personSet.Add(p);
  }
  Console.WriteLine("Anzahl Personen: " + personSet.Count);
#endregion

#region ---------------- Auswertung
  CUI.H3("Auswertung:");
  // bisherige Implementierung mit GroupBy() + Select()
  var groups1 = personSet
    .GroupBy(info => info.Givenname) // Gruppieren nach GivenName
    .Select(group => new // Zählen
    {
      Key = group.Key,
      Value = group.Count()
    });

  Console.WriteLine("10 häufigste Vornamen im Datenbestand:");
  var groups1top10 = groups1.OrderByDescending(x => x.Value).Take(10);
  // Ausgabe mit SpectreConsole
  AnsiConsole.Write(new BarChart()
    .Width(60)
    .AddItems(groups1top10, (item) => new BarChartItem(
      item.Key, item.Value, Color.Yellow)));

  // Neue Implementierung mit CountBy()
  var groups2 = personSet
    .CountBy(x => x.Givenname); // Gruppieren nach Häufigkeit des GivenName

  Console.WriteLine("10 häufigste Vornamen im Datenbestand:");
  var groups2top10 = groups2.OrderByDescending(x => x.Value).Take(10);
  // Ausgabe mit SpectreConsole
  AnsiConsole.Write(new BarChart()
    .Width(60)
    .AddItems(groups2top10, (item) => new BarChartItem(
      item.Key, item.Value, Color.Yellow)));

#endregion

Abb. 4: Ausgabe von Listing 1

Listing 2: Einsatz der neuen Methode Index()

Console.WriteLine("10 häufigste Vornamen im Datenbestand:");
// bisher schon möglich:
foreach ((int index, KeyValuePair<string, int> group) in groups2top10.Select((wort, index) => (index, wort)))
{
  CUI.LI($"Platz {index + 1}: Vorname {group.Key} kommt {group.Value} vor.");
}

Console.WriteLine("10 häufigste Vornamen im Datenbestand:");
// neu ab .NET 9.0:
foreach ((int index, KeyValuePair<string, int> group) in groups2top10.Index())
{
  CUI.LI($"Platz {index + 1}: Vorname {group.Key} kommt {group.Value} vor.");
}

Die PriorityQueue-Klasse, die in .NET 6.0 eingeführt wurde, verfügt nun über eine Remove()-Methode, mit der Elemente entfernt werden können, auch wenn sie nicht an der Reihe sind. Remove() erweitert als Parameter das zu entfernende Element. Remove() liefert drei Werte zurück: Als Rückgabewert einen Boolean-Wert, der anzeigt, ob das Element vorhanden war und entfernt werden konnte. Im zweiten und dritten Methodenparameter kommt via out das entfernte Element sowie seine Priorität zurück.

Listing 3: Einsatz der Methode Remove in der Klasse PriorityQueue

public class FCL_Collections
{
  public void Run()
  {
    CUI.H2(nameof(FCL_Collections));

    var q = new PriorityQueue<string, int>();
    q.Enqueue("www.dotnet-doktor.de", 20);
    q.Enqueue("www.dotnet8.de", 2);
    q.Enqueue("www.IT-Visions.de", 10);
    q.Enqueue("www.dotnet-lexikon.de", 30);
    q.Enqueue("www.dotnet9.de", 1);

    Console.WriteLine(q.Count);

    CUI.H3("Entferne vorhandenes Element");
    bool b1 = q.Remove("www.dotnet8.de", out string e1, out int priority1);
    if (b1) Console.WriteLine($"Element {e1} mit Priorität {priority1} wurde entfernt!");
    else Console.WriteLine("Element nicht gefunden");

    CUI.H3("Versuch, nicht vorhandenes Element zu entfernen");
    bool b2 = q.Remove("www.dotnet7.de", out string e2, out int priority2);
    if (b2) Console.WriteLine($"Element {e2} mit Priorität {priority2} wurde entfernt!");
    else Console.WriteLine("Element nicht gefunden");

    CUI.H3($"Alle Elemente {q.Count} auflisten"); // 4
    var count = q.Count;
    for (int i = 0; i < count; i++)
    {
      var current = q.Dequeue();
      Console.WriteLine(i + ": " + current);
    }
    Console.WriteLine($"Verbliebene Elemente: {q.Count}"); // 0
  }
}

Mit .NET 9.0 ist es nun auch wieder möglich, zur Laufzeit erzeugte Assemblies im Dateisystem zu persistieren, indem die Methode Save() in der Klasse AssemblyBuilder verwendet wird (Listing 4). Diese Funktion war bereits im klassischen .NET Framework verfügbar (siehe Dokumentation zu Save() unter [3]). Im modernen .NET konnten zur Laufzeit erzeugte Assemblies bisher nur im RAM gehalten werden.

Listing 4: Speichern einer dynamisch erzeugten Assembly im Dateisystem

public void CreateAndSaveAssembly()
{
  CUI.H2(nameof(CreateAndSaveAssembly));

  string assemblyPath = Path.Combine(System.AppContext.BaseDirectory, "Math.dll");

  AssemblyBuilder ab = AssemblyBuilder.DefinePersistedAssembly(new AssemblyName("Math"), typeof(object).Assembly);
  TypeBuilder tb = ab.DefineDynamicModule("MathModule").DefineType("MathUtil", TypeAttributes.Public | TypeAttributes.Class);

  MethodBuilder mb = tb.DefineMethod("Sum", MethodAttributes.Public | MethodAttributes.Static, typeof(int), [typeof(int), typeof(int)]);
  ILGenerator il = mb.GetILGenerator();
  il.Emit(OpCodes.Ldarg_0);
  il.Emit(OpCodes.Ldarg_1);
  il.Emit(OpCodes.Add);
  il.Emit(OpCodes.Ret);

  tb.CreateType();
  Console.WriteLine("Speichere Assembly unter: " + assemblyPath);
  ab.Save(assemblyPath); // Speichern ins Dateisystem oder einen Stream
}

Die .NET-Debugger in Visual Studio und Visual Studio Code zeigen nun die Inhalte von Dictionary-Klassen während des Debuggings deutlich übersichtlicher an (Abb. 5).

Abb. 5: Verbesserte Debugger-Ansicht von Dictionary-Klassen in .NET 9.0 [4]

Microsoft liefert ab .NET 9.0 eine Implementierung des KECCAK Message Authentication Code (KMAC) des US-amerikanischen National Institute of Standards and Technology (NIST) für kryptographische Funktionen [5].

Verbesserungen in System.Text.Json 9.0

Die Version 9.0 der JSON-Bibliothek System.Text.Json ermöglicht es, die Einrückung in der JSON-Zeichenkette über die JsonSerializerOptions anzupassen. Hierfür wurden zwei neue Einstellungen eingeführt: IndentCharacter und IndentSize. Listing 5 zeigt ein Beispiel. Als IndentCharacter werden aber nur ein Leerzeichen ‘ ‘ oder ein Tabulator ‘\t’ unterstützt.

Durch die Verwendung von JsonSerializerOptions.Web (Listing 5) können Entwickler:innen nun auf schnelle Weise dieselben Einstellungen für die JSON-Serialisierung und -Deserialisierung wählen, die standardmäßig im ASP.NET-Core-Web-API verwendet werden.

Listing 5: Setzen von IndentCharacter und IndentSize für die JSON-Serialisierung mit System.Text.Json

internal class FCL9_JSON
{
  public void Run()
  {
    CUI.H2(nameof(FCL9_JSON));

    CUI.H3("IndentCharacter und IndentSize")

    var consultant = new Consultant() { ID = 42, FullName = "Holger Schwichtenberg", Salutation = "Dr.", PersonalWebsite = "www.dotnet-doktor.de" };

    var options = new JsonSerializerOptions
    {
      WriteIndented = true,
      IndentCharacter = ' ',
      IndentSize = 2,
    };
    var json1 = JsonSerializer.Serialize(consultant, options);

    Console.WriteLine(json1);
    //liefert:
    //{
    //  "Languages": [],
    //  "PersonalWebsite": "www.dotnet-doktor.de",
    //  "ID": 42,
    //  "FullName": "Holger Schwichtenberg",
    //  "Salutation": "Dr.",
    //  "Address": null
    //}

    CUI.H3("JsonSerializerOptions.Web");
    var json2 = JsonSerializer.Serialize(consultant, JsonSerializerOptions.Web);
    Console.WriteLine(json2);
    //liefert:
    //{"languages":[],"personalWebsite":"www.dotnet-doktor.de","id":42,"fullName":"Holger Schwichtenberg","salutation":"Dr.","address":null}
  }
}

Verbesserungen in Entity Framework Core 9.0

Der Object-relational Mapper Entity Framework Core hat in Preview 1 und 2 bereits eine Reihe kleinerer Verbesserungen implementiert. Verbesserung in der Modellerstellung sind:

• Bei Schlüssel- und Indexspalten können nun für den Microsoft SQL Server Angaben zum Füllfaktor gemacht werden. Der Füllfaktor bestimmt den Prozentsatz des Platzes auf eine Seite in der Datenbankdatei, der mit Daten gefüllt werden soll, wobei der Rest auf jeder Seite als freier Platz für zukünftiges Wachstum reserviert wird. Der Füllfaktor kann nun in Entity Framework Core 9.0 via HasFillFactor() für einfache und zusammengesetzte Schlüsselspalten und Indexe gesetzt werden (Listing 6).
• Bei der Erstellung von Autowerten mit Sequenzen kann nun das Caching via UseCache() und UseNoCache() konfiguriert werden, z. B.

modelBuilder.HasSequence<int>("NameDerSequence")
  .HasMin(10).HasMax(255000)
  .IsCyclic()
  .StartsAt(11).IncrementsBy(2)
  .UseCache(3);

• Die Umwandlung einer normalen Tabelle in eine temporäre Tabelle ist nun mit einer stark verkürzten Befehlsfolge in den Schemamigrationen möglich. Siehe dazu [6].

Listing 6: Einsatz von HasFillFactor()

modelBuilder.Entity<User>()
  .HasKey(e => e.Id)
  .HasFillFactor(80);

modelBuilder.Entity<User>()
  .HasAlternateKey(e => new { e.Region, e.Ssn })
  .HasFillFactor(80);

modelBuilder.Entity<User>()
  .HasIndex(e => new { e.Name })
  .HasFillFactor(80);

modelBuilder.Entity<User>()
  .HasIndex(e => new { e.Region, e.Tag })
  .HasFillFactor(80);

Verbesserung bei der Übersetzung von LINQ in SQL sind:

• Bei der Übersetzung von LINQ zu SQL fasst Entity Framework Core 9.0 nun die SQL-Befehle von verschachtelten LINQ-Abfragen zusammen (Listing 6, 7 und 8).
• Entwicklerinnen und Entwickler können nun mit den .NET-Funktionen EF.Parameter() und EF.Constant() erzwingen, dass bei der Übersetzung von LINQ-Abfragen nach SQL ein Wert in der SQL-Abfrage als Parameter bzw. als Konstante übergeben wird. Bisher lag die Entscheidung für die Parametrisierung allein beim ORM. Nun ist sie beeinflussbar, um die Nutzung des Query-Cache des Datenbankmanagementsystems zu optimieren. EF.Constant() ist auch als ein Nachtrag zu .NET 8.0 verfügbar, der in Version 8.0.2 erschienen ist. Das ist ungewöhnlich, da Microsoft behauptet, beim modernen .NET dem Semantic Versioning zu folgen, welches bei neuen Funktionen eine Änderung der Versionsnummer an der zweiten Stelle vorsieht.
• Bei der Übersetzung von Abfragen, die sich auf JSON-Spalten beziehen, werden nun bei OPENJSON…WITH nur noch die Teile der JSON-Zeichenkette ausgewertet, die für die Bedingung oder das Resultset notwendig sind.
• Falls das Zieldatenbanksystem ein Microsoft SQL Server der neusten Version 2022 ist, verwendet Entity Framework Core 9.0 nun die neu eingeführten T-SQL-Funktionen LEAST() und GREATEST() bei der Übersetzung von Min() und Math.Max().
• Die Methode ExecuteUpdate() bietet nun eine verkürzte Syntax in Verbindung mit komplexen Typen:

var newAddress = new Address("www.IT-Visions.de", 45257, "Essen");
await context.Stores
  .Where(e => e.Region == "Germany")
  .ExecuteUpdateAsync(s => s.SetProperty(b => b.ShippingAddress, newAddress));

• Analog zur bereits in Entity Framework Core 2.0 eingeführten Materialisierungsmethode ToHashSet() bietet der ORM nun ein asynchrones Pendant: ToHashSetAsync().

Weitere Verbesserungen in Entity Framework Core 9.0 sind:

• Die Entity-Framework-Core-Kommandozeilenwerkzeuge sollen nun weniger häufig eine Neukompilierung des Projekts erfordern.
• Die Erstellung von Konventionen für die Modellerstellung hat Microsoft verschlankt, hierfür gibt es ein umfangreiches Beispiel in der Dokumentation [7].
• In der „What’s new“-Dokumentation findet man darüber hinaus einen Hinweis auf eine neue Überladung der Methode Parse() in der Klasse HierarchyId, die in Entity Framework Core 8.0 eingeführt wurde. Eine HierarchyId-Instanz soll man nicht nur wie bisher aus einer Zeichenkette (z. B. /4/1/3/1/2/), sondern auch typsicherer auf Basis einer anderen HierarchyId erstellen können, z. B.:

var daisy = await context.Halflings.SingleAsync(e => e.Name == "Daisy");
var child1 = new Halfling(HierarchyId.Parse(daisy.PathFromPatriarch, 1), "Toast");
var child2 = new Halfling(HierarchyId.Parse(daisy.PathFromPatriarch, 2), "Wills");
var child1b = new Halfling(HierarchyId.Parse(daisy.PathFromPatriarch, 1, 5), "Toast");

• Allerdings funktioniert das in Entity Framework Core 9.0 Preview 2 noch nicht, sondern kommt dann voraussichtlich in Preview 3.

Listing 7: Verschachtelte LINQ-Abfragen

var dotnetPosts = context
  .Posts
  .Where(p => p.Title.Contains(".NET"));

var results = dotnetPosts
  .Where(p => p.Id > 2)
  .Select(p => new { Post = p, TotalCount = dotnetPosts.Count() })
  .Skip(2).Take(10)
  .ToArray();

Listing 8: Übersetzung der LINQ-Abfragen in Listing 1 in zwei SQL-Abfragen in Entity Framework Core 8.0

SELECT COUNT(*)
FROM [Posts] AS [p]
WHERE [p].[Title] LIKE N'%.NET%'

SELECT [p].[Id], [p].[Archived], [p].[AuthorId], [p].[BlogId], [p].[Content], [p].[Discriminator], [p].[PublishedOn], [p].[Title], [p].[PromoText], [p].[Metadata]
FROM [Posts] AS [p]
WHERE [p].[Title] LIKE N'%.NET%' AND [p].[Id] > 2
ORDER BY (SELECT 1)
OFFSET @__p_1 ROWS FETCH NEXT @__p_2 ROWS ONLY

Listing 9: Übersetzung der LINQ-Abfragen in Listing 1 in eine einzige SQL-Abfrage in Entity Framework Core 9.0

SELECT [p].[Id], [p].[Archived], [p].[AuthorId], [p].[BlogId], [p].[Content], [p].[Discriminator], [p].[PublishedOn], [p].[Title], [p].[PromoText], [p].[Metadata], (
  SELECT COUNT(*)
  FROM [Posts] AS [p0]
  WHERE [p0].[Title] LIKE N'%.NET%')
FROM [Posts] AS [p]
WHERE [p].[Title] LIKE N'%.NET%' AND [p].[Id] > 2
ORDER BY (SELECT 1)
OFFSET @__p_0 ROWS FETCH NEXT @__p_1 ROWS ONLY

Einige der Neuerungen in Entity Framework Core 9.0 Preview 1 und 2 stammen nicht von Microsoft-Entwickler:innen, sondern aus der Community, so zum Beispiel die Verbesserungen für Sequenzen, HasFillFactor(), ToHashSetAsync() und die weniger häufigen Kompilierungsvorgänge bei den Kommandozeilenwerkzeugen.

Verbesserungen für Blazor 9.0

In Webanwendung auf Basis von Blazor ist es jetzt möglich, Dependency Injection auch über den Konstruktor in einer Code-Behind-Datei in der Razor Component durchzuführen. Wie Listing 10 zeigt, können auch die in C# 12.0 eingeführten Primärkonstruktoren dafür verwendet werden.

Listing 10: Konstruktorinjektion in einer Code-Behind-Datei einer Blazor-Komponente

public partial class Counter(NavigationManager navigationManager, IJSRuntime js)
{
  private void NavigateHome() => navigationManager.NavigateTo("/");
  private string GetBlazorType
  {
    get
    {
      if (js.GetType().Name.Contains("Remote")) return "Blazor Server";
      if (js.GetType().Name.Contains("WebAssembly")) return "Blazor WebAssembly";
      return "Blazor Hybrid " + js.GetType().Name;
    }
  }
}

Bisher war es in Razor Components nur möglich, Dienste entweder durch @inject im Razor-Template oder durch die Annotation [Inject] auf einer Eigenschaft im Code zu injizieren.

Beim Interactive Server-side Rendering (alias Blazor Server) ist nun standardmäßig die Komprimierung in BlazorPack-Daten in der WebSockets-Verbindung aktiviert. Entwickler:innen können das jedoch bei Bedarf deaktivieren, indem sie DisableWebSocketCompression = true im Parameterobjekt von AddInteractiveServerRenderMode() setzen:

app.MapRazorComponents<App>()

  .AddInteractiveServerRenderMode(o => o.DisableWebSocketCompression = true);

Microsoft setzt nun standardmäßig die Content Security Policy (CSP) auf frame-ancestor: ‘self’. Das kann jedoch durch die Verwendung von ContentSecurityFrameAncestorsPolicy geändert werden:

app.MapRazorComponents<App>()
  .AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy="'none'");

Weitere Neuerungen in ASP.NET Core 9.0a

In ASP.NET Core 9.0 SignalR ist Polymorphism für die Parameter von Operationen in ASP.NET-Core-SignalR-Hubs möglich, indem man die in System.Text.Json-Version 7.0 eingeführten Annotationen [JsonPolymorphicAttribute] und [JsonDerivedTypeAttribute] verwendet, die zu Metadaten (einem Type Discriminator) in JSON führen (z. B. “$type” : “PersonWithAge”). Listing 11 zeigt ein Einsatzbeispiel.

Listing 11: Polymorphisms bei ASP.NET Core SignalR

using System.Text.Json.Serialization;

namespace Blazor9;

[JsonPolymorphic]
[JsonDerivedType(typeof(PersonWithAge), nameof(PersonWithAge))]
[JsonDerivedType(typeof(PersonWithBirtday), nameof(PersonWithBirtday))]
public class PersonDTO
{
  public string? Name { get; set; }
}

public class PersonWithAge : PersonDTO
{
  public int Age { get; set; }
}

public class PersonWithBirtday : PersonDTO
{
  public DateTime Birthday { get; set; }
}

public class SignalRHub
{
  public int Search(PersonDTO person)
  {
    if (person is PersonWithAge)
    {
      // Suche Person mit Name und Alter
      // ...
    }
    else if (person is PersonWithBirtday)
    {
      // Suche Person mit Name und Geburtsdatum
      // ...
    }
    else
    {
      // Suche Person nur mit Name
      // ...
    }
    return 0; // ID = 0 -> nicht gefunden
  }
}

Bei der Verwendung von OAuth und OIDC ist es nun deutlich prägnanter, die Parameter anzupassen:

builder.Services.AddAuthentication().AddOpenIdConnect(options =>
  {
    options.AdditionalAuthorizationParameters.Add("prompt", "login");
    options.AdditionalAuthorizationParameters.Add("audience", "https://api.example.com");
});

Fast nichts Neues bei den GUIs

Bei .NET MAUI wurden bisher zahlreiche Fehlerbehebungen und kleinere Verbesserungen, wie beispielsweise die Unterstützung von animierten GIFs auf iOS, eingeführt. Die entsprechenden Release-Notes finden sich unter [8] und [9].

Informationen zu Verbesserungen bei Windows Forms oder der Windows Presentation Foundation (WPF) sind bisher nicht in den Release-Notes enthalten. Immerhin gab es jedoch im Februar ein Bekenntnis von Microsoft, weiterhin am Design für Windows Forms in Visual Studio zu arbeiten, wie unter [10] erklärt wird.

Geänderte Informationskanäle von Microsoft in der Kritik

In den letzten Jahren gab es zu jeder Vorschauversion des modernen .NET mehrere Blogeinträge im Microsoft .NET Blog [11]. Das galt bis einschließlich November 2023, dem Erscheinungstermin von .NET 8.0.

Zu den Previews von .NET 9.0 gibt es leider keine Blogeinträge mehr. Das ist Teil einer seit diesem Jahr veränderten Strategie bezüglich des .NET Blogs. Das .NET Blog soll sich laut einer Ankündigung von .NET Program Manager Rich Lander auf Beiträge über stabile .NET-Versionen konzentrieren [12].

Die Preview-Versionen will man jetzt stattdessen über einen neuen Diskussionsbereich auf GitHub anzukündigen [13]. Die einzelnen Neuerungen sind dann auch nicht dort, sondern in den verlinkten Release-Notes beschrieben, außerdem in „What’s New“-Dokumenten auf Microsoft Learn [14].

Allerdings sind die Neuerungen über mehrere Release-Notes-Dokumente verstreut und werden darin meist nur sehr knapp erwähnt. In den „What’s New“-Dokumenten zu .NET 9.0 [15], ASP.NET Core 9.0 [16], Entity Framework Core 9.0 [17] und .NET MAUI [18] sind die Neuerungen ausführlicher beschrieben. Allerdings fehlt in diesen Dokumenten die Trennung zwischen den verschiedenen Vorschauversionen und es finden sich in den Dokumenten (wie oben am Beispiel HierarchyId.Parse() gezeigt) auch Hinweise auf Features, die noch gar nicht in den aktuellen Preview-Versionen enthalten sind.

Microsofts neue Informationskanäle erschweren die Arbeiten derjenigen Entwicklerinnen und Entwickler, die am Puls der Zeit bleiben wollen und damit auch die Erstellung von journalistischen Fachberichten wie diesem. Die Kommentare auf GitHub [19] zeigen, dass die neue Strategie einigen Kundinnen und Kunden nicht gefällt: „confusing“, „badly done“ und „before it was even out was so much better“ heißt es in den Kommentaren. Ketzerische Reaktionen wie „so, is .net dead?“ gibt es auch. Mitarbeitende von Microsoft haben inzwischen mit Ankündigungen reagiert, die Darstellung zu überdenken. Jon Douglas schreibt: „I will make notes to ask our product and documentation teams to provide clear diffs“ [20].

Der einzige Blogbeitrag, der zu .NET 9.0 erschienen ist, trägt den Titel „Our Vision for .NET 9“ [21]. Ziele für .NET 9.0 sind demnach Verbesserungen für Cloud- und KI-Anwendungen, was angesichts der Microsoft-Unternehmensstrategie nicht überraschend ist. Welche Features genau dazu gehören, bleibt offen. Es bleibt bei schwammigen Aussagen wie „Entwickler werden großartige Bibliotheken und Dokumentationen finden, um mit OpenAI- und OSS-Modellen (gehostet und lokal) zu arbeiten. Wir werden weiterhin an der Zusammenarbeit an Semantic Kernel, OpenAI und Azure SDK arbeiten, um sicherzustellen, dass .NET-Entwickler beim Erstellen intelligenter Anwendungen eine erstklassige Erfahrung haben“.

Was schon zuvor angekündigt wurde, sind die Erweiterungen der Einsatzgebiete des Ahead-of-Timer-Compilers. Er funktioniert in .NET 7.0 und .NET 8.0 für Konsolenanwendungen, Minimal WebAPIs, gRPC-Dienste und Worker Services –, aber auch dort mit großen Einschränkungen (z. B. ist Entity Framework Core nicht nutzbar). Der Blogeintrag lässt offen, was konkret der AOT-Compiler in .NET 9.0 mehr können wird.

Roadmaps und Backlogs

Auch die Liste der geplanten Features ist, anders als bei .NET 5.0 bis .NET 8.0, noch nicht sehr ausführlich. Am meisten hat derzeit das ASP.NET-Core-Team veröffentlicht (Abb. 6). Dazu gehören:

• die bisher fehlende OAuth-Authentifizierung mit der Microsoft Identity Platform in der Projektvorlage Blazor Web App
• eine einfachere Möglichkeit, den aktuellen Render-Modus bei Blazor zu ermitteln (hier muss man bisher die Typnamen der injizierten Instanzen von NavigationManager oder IJSRuntime abfragen)
• Übergabe des Zustandes nach dem Pre-Rendering an den Client
• Verbesserung der Multi-Threading-Unterstützung in Blazor WebAssembly
• eine verbesserte Startzeit von Blazor-WebAssembly-Anwendungen, die im Browsercache liegen

Abb. 6: Pläne für ASP.NET Core 9.0 und Blazor 9.0 [22]

Auch das C#-Team gibt unter [23] wie immer frühe Einblicke. Wenig zu lesen gibt es hingegen bei .NET MAUI [24]. Nichts Aktuelles findet sich bei Windows Forms (Roadmap ist zwei Jahre alt, siehe [25]) und WPF (drei Jahre alte Roadmap, siehe [26]).

Das Entity Framework Core-Entwicklungsteam schreibt Stand 17. März 2024 nur „Coming soon“ [27]. Eine Linkliste auf verschiedene Roadmaps und Backlogs finden Sie unter [28].

Dr. Holger Schwichtenberg – alias der „DOTNET-DOKTOR“ – ist Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1 500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland. Seit 1998 ist er ununterbrochen Sprecher auf sämtlichen BASTA!-Konferenzen. Von Microsoft wird er seit 20 Jahren als MVP ausgezeichnet.

Mail: [email protected]

Twitter: @dotnetdoktor

Web: www.dotnet-doktor.de

Links und Literatur

[1] https://dotnet.microsoft.com/en-us/download/dotnet/9.0

[2] https://spectreconsole.net

[3] https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.assemblybuilder.save?view=netframework-4.8.1

[4] https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-9.0?view=aspnetcore-8.0

[5] https://csrc.nist.gov/pubs/sp/800/185/final

[6] https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/whatsnew

[7] https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/whatsnew#make-existing-model-building-conventions-more-extensible

[8] https://github.com/dotnet/maui/releases/tag/9.0.100-preview.1.9973

[9] https://github.com/dotnet/maui/releases/tag/9.0.0-preview.2.10293

[10] https://devblogs.microsoft.com/dotnet/winforms-designer-64-bit-path-forward/

[11] https://devblogs.microsoft.com/dotnet/

[12] https://github.com/dotnet/core/discussions/9131

[13] https://github.com/dotnet/core/discussions

[14] https://learn.microsoft.com/en-us/dotnet/whats-new/

[15] https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-9/overview

[16] https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-9.0?view=aspnetcore-8.0

[17] https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/whatsnew

[18] https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-9?view=net-maui-8.0

[19] https://github.com/dotnet/core/discussions/9217

[20] https://github.com/dotnet/core/discussions/9217#discussioncomment-8765352

[21] https://devblogs.microsoft.com/dotnet/our-vision-for-dotnet-9/

[22] https://github.com/dotnet/aspnetcore/issues/51834

[23] https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md

[24] https://github.com/dotnet/maui/wiki/Roadmap

[25] https://github.com/dotnet/winforms/blob/main/docs/roadmap.md

[26] https://github.com/dotnet/wpf/blob/main/roadmap.md

[27] https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/plan

[28] https://github.com/dotnet/core/blob/main/roadmap.md

The post .NET 9 Preview: Neuerungen und Änderungen in der Version 9.0 appeared first on BASTA!.

Konzentriert findet Inspect and Adapt oft im Rahmen von Retrospektiven statt. Teammitglieder kommen alle paar Wochen für teils mehrere Stunden zusammen. Es wird besprochen, es wird vorgeschlagen, es wird vereinbart. Und dann?

Gemeinsam an Verbesserung arbeiten ist ein hohes Gut, das der Wertschöpfung dient. Bessere Prozesse, bessere Tools und Psychological Safety zahlen alle auf die Unternehmensziele ein – wenn sie denn erreicht werden. Der wichtigste Grundsatz beim agilen Arbeiten ist Inspect and Adapt. Um diesem Prinzip der kontinuierlichen Verbesserung gerecht zu werden, muss die Arbeit transparent sein und es muss eine offene Kommunikation herrschen. Inspect and Adapt erstreckt sich auf alle Bereiche – ganz gleich, ob es sich dabei um Prozesse, Qualität, Quantität oder Kommunikation handelt.

Man müsste mal … In Konjunktiven gefangen ist es schwierig, die Umsetzungsebene zu erreichen und konkret Antipatterns in Projekten anzugehen. Retrospektiven (auch Retros genannt), richtig angewendet, sind gerade im agilen Umfeld das Mittel der Wahl, um besser zu werden. Wenn ich als Coach neu zu Teams dazukomme, schaue ich gerne, ob es eine Art Dokumentation zu stattgefundenen Retrospektiven gibt. Wenn ja, dann schaue ich nach Action Points, die festgehalten wurden und was damit passiert ist. In manchen Fällen wird den Action Points nachgegangen und eine schrittweise Verbesserung findet statt oder lässt sich vermuten. Jedoch sehe ich ebenfalls seitenweise offene Action Points – Vorhaben, die gemeinsam festgehalten, jedoch nicht umgesetzt wurden. Wie kann das sein? Es gab doch die besten Intentionen.

Ursachen einer Retro-Verpuffung

Was sind die Ursachen für so eine fehlende Umsetzung? Unsichtbare Dokumentation. Was für einen Stellenwert hat eine Zusammenfassung für das Team? Liegt sie z. B. in einem Confluence-Bereich, der von den Teammitgliedern eher selten bis gar nicht frequentiert wird? Natürlich gilt auch bei einer Retro nur so viel wie nötig und so wenig wie möglich zu dokumentieren, denn die Produktion von Dokumenten macht schließlich nicht agiler.

Tools sind hier auch weniger die Lösung als Mittel zum Zweck. Nach dem Kanban-Prinzip „Da anfangen, wo man ist“ schaue ich gerne, was Teams bisher wirklich nutzen. Manchmal muss erst Ordnung reingebracht werden, aber meistens gibt es frequentierte Bereiche, die sich auch für Retro-Dokus eignen. Manchmal reicht es, einfach die Verbesserungsvorhaben direkt im Backlog zu platzieren und einzuplanen.

Untergang im Alltag

Allzu hoher Produktionsdruck oder konstantes Firefighting lassen den Fokus von Verbesserung abschweifen bzw. den notwendigen Fokus erst gar nicht zu. Wenn nur hinterhergerannt wird, ist es ausgeschlossen, die Strecke zu gestalten. Es wird lediglich reagiert und die gegebenen Umstände im schlimmsten Fall als normal angesehen. Die Ursachen können vielfältig sein. Eine volatile Systemlandschaft, die mit Mühe und Not am Leben erhalten wird, eine Technical-Debt-Kakophonie, chronische Unterbesetzung, fehlende Priorisierung, unklare Entwicklungsprozesse und vieles mehr.

Jedes noch so wohlgemeinte Vorhaben kann nur schwer oder gar nicht stattfinden, wenn es schlicht und einfach keine Zeit gibt, um Impediments abzubauen. Also einfach Zeit schaffen – schön wäre es! Die ersten zarten Schritte von Transparenz und einer Arbeitsplanung sind sicherlich ein guter Weg, um mit der Realität umzugehen.

Fehlende Nachhaltigkeit

Wie wird mit Action Points umgegangen? Manchmal fehlt einfach, dass im Team daran erinnert wird, dass Verbesserungsmaßnahmen stattfinden sollen. Teams, die noch auf dem Weg der Reife sind, benötigen mehr Unterstützung und müssen noch Erfahrungen machen, die dann erst in die Arbeitsweisen übergehen können. So finde ich mich als Coach dann häufiger in der Rolle, Fragen zu stellen und dadurch Lösungen anzustoßen. Gerne biete ich aber auch „Good Practices“ an, z. B. die Priorisierung von Retro-Vorhaben im Backlog. Was für das eine Team funktioniert, muss jedoch keine Allgemeingültigkeit haben.

Die Ownership von Action Points zahlt ebenfalls auf Nachhaltigkeit ein. Während das Pull-Prinzip und Cross-Funktionalität hohe Güter sind, kann es trotzdem sinnvoll sein, Ownership für solche Vorhaben frühzeitig explizit zu machen. Der vermeintliche Wert von Retro Action Points kann für manche Teammitglieder im ersten Moment durchaus unklar sein, dann ist der Griff zu produktiven Themen im Backlog naheliegender.

Unkonkrete Vorhaben sind also schwer greifbar. Gibt es jetzt eine Aufgabe, die sich jemand nimmt, oder gibt es in der Wahrnehmung nur eine vage Aussage zu einem Missstand? Timeboxing in Retrospektiven helfen mit der Strukturierung, jedoch helfen sie wenig, wenn am Ende nichts Greifbares rauskommt. Explizite Formulierungen und sogar Akzeptanzkriterien schaffen hier Klarheit und forcieren Bewegung.

Einflussmöglichkeiten

Eine gute Übung für Teams ist es, sich folgende Frage zu stellen: „Was liegt in unserer Macht, das wir ändern können?“ Im Team und auf Teamebene ist es in der Regel einfacher, kleine Schritte in Richtung Verbesserung zu gehen. Das Maß an Einfluss auf andere Ebenen schwindet in der Regel auf dem Weg nach oben bzw. nach außen. „Circles of Influence“ ist ein Konzept, das durch Visualisierung hilft, Bereiche zu erkennen, die mehr Aufmerksamkeit benötigen. Im Grunde geht es um eine Dreiteilung. In der äußeren Hülle, dem „Circle of Concern“ oder „Kreis der Bedenken“, befinden sich Inhalte, auf die kein Einfluss genommen werden kann. Der „Circle of Influence“ oder „Einflussbereich“ ist der Bereich, auf dem bedingt etwas bewegt werden kann. Auf den „Circle of Control“ oder „Kreis der Kontrolle“ kann unmittelbarer Einfluss genommen werden.

Sicherlich gibt es immer wieder mal bedenkenschaffende Einflussfaktoren, wie z. B. einen scheußlichen Produktschnitt, der Antipattern per Design etabliert. Trotzdem ist es sicherlich sinnvoll, Transparenz für Impediments zu schaffen, die nur anderswo gelöst werden können. Teamentwicklung und Organisationsentwicklung gehen zwar gerne Hand in Hand, jedoch in unterschiedlichen Geschwindigkeiten. Darauf zu warten und zu vertrauen, dass etwas passiert, ist nicht zielführend.

Das Format passt nicht zu den Teilnehmer:innen

Manche Teams blühen auf, wenn sie einfallsreiche Retros durchführen und gemeinsam feststellen, welcher Wind in den Segeln sie vorantreibt und welche Anker sie zurückhalten. Andere Teams möchten nur Real Talk. Gezieltes Adressieren von Umständen mit klaren, schnellen Vorhaben ohne großes Check-in und anregenden Metaphern. Beides hat seine Berechtigung und ist in der richtigen Kombination zielführend. Wenn sich jedoch nur ein wie auch immer geratener Hammer im Werkzeugkoffer befindet, besteht die große Gefahr, mit den Retros eher zu traktieren, als etwas voranzubringen.

Gewöhnungseffekte

Beim Gewöhnungseffekt geht es um emotionale Erschöpfung als Reaktion auf frustrierende Umstände oder Themen. Bei dauerhaft ungelösten Problemen ohne wahrnehmbare Verbesserungen kann ein Resignationseffekt eintreten. Betroffene möchten sich einfach nicht mehr mit bestimmten Themen beschäftigen. Solche Umstände können dann als normal empfunden werden. Neue Teammitglieder lernen diese Dysfunktion als normal und unumstößlich kennen, was leider einen nachhaltenden Einfluss auf die Unternehmenskultur hat.

Wenn also Retros verpuffen, dann sinkt ihr Stellenwert und zahlt sogar auf das Gefühl ein, dass es zu viele sinnlose Meetings gibt (ein Retro-Dauerbrenner). Schon bildet sich ungewollt eine explosive Atmosphäre. Die Verpuffung möchte man in der Regel nicht herbeiführen, also wie vorbeugen? Letztendlich gibt es viele Faktoren, die auf den Erfolg von Retrospektiven einzahlen. Was schützt nun vor Verpuffung? Kurzgesagt: Realismus und Nachhaltigkeit. Ich habe ja bereits einige Ansätze genannt, aber wie so oft im Agilen kommt es auf die Situation an. Kleine erreichbare Stellschrauben sollten nicht übersehen werden bei dem Wunsch, am ganz großen Rad zu drehen.

SIE LIEBEN AGILE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Jahresrückblick

Zum Jahresende mache ich gerne eine „Geist-von-Weihnachten-Retrospektive“, in der wir auf die Retros des ablaufenden Jahres zurückblicken und schauen, welche Vorhaben wir festgehalten haben und ob bzw. wie wir sie umgesetzt haben. Das schafft ein Bewusstsein dafür, wie viel bewegt wurde und erinnert an Verbesserungen, die mittlerweile schon als selbstverständlich angenommen werden. Es wird gemeinsam bekräftigt, weiter dem Verbesserungsprinzip zu folgen und entsprechend den Erkenntnissen des Jahresrückblicks ggf. am Vorgehen nachjustiert.

Schaffung einer positiven Atmosphäre

Gerade aus einer Situation heraus, in der hoher Arbeitsdruck besteht, kann es für Teammitglieder schwierig sein, den Kontextwechsel hinzukriegen. Unter dem Damoklesschwert der Ticketflut oder kognitiv tief in der Umsetzung einer User Story zu sein, kann das Empfinden hinterlassen, durch die Retro aus etwas Wichtigerem gerissen zu werden. Es geht hierbei nicht um tatsächlich unternehmenskritische Ereignisse. Klar kann es auch mal Wichtigeres als eine Retrospektive geben. Unternehmenskritisch wird jedoch schon mal etwas weit gesteckt und bildet dann eine dauerhafte Dysfunktion, die am besten in einer Retro zu behandeln ist.

Wie eine positive Atmosphäre geschaffen werden kann, hängt von den Beteiligten ab. Das Team zu fragen, gleichzeitig aber auch Vorschläge mitzubringen ist ein guter Ansatz. Ein Eisbrecher zum Start kann Wunder bewirken und den Kontextwechsel ermöglichen. Beispiele gibt es viele: Von einer Frage wie „Was ist dein Lieblingstier und weshalb?“ bis hin zu Spielen wie „Wahrheit oder Lüge“, bei der jeder eine oder mehrere Anekdoten erzählt und das Team erraten muss, ob sie stimmen.

Ob es gelingt, diese positive Atmosphäre zu schaffen, hängt davon ab, wieviel Zeit zur Verfügung steht, was bezweckt wird und wer die Teilnehmer:innen sind oder wie fortgeschritten ein Team ist. Wie bereits geschrieben, können manche Teams sofort in die Themenfindung springen. Bei anderen geht es darum, dass jede:r mal den Raum findet, sich zu artikulieren, vom Vorherigen abzuschalten, Spaß zu haben oder Offenheit herbeizuführen. Das ist bei jedem Team letztendlich abhängig von den involvierten Charakteren. Zum Beispiel kann ein Scrum Master mit geringen People Skills (möglicherweise befördert im Rahmen einer „Hauptsache-intern-besetzt-Philosophie“) häufig daneben liegen.

Verbesserung braucht Zeit

Verbesserung braucht Zeit – das würde jede:r unterschreiben. Weshalb also ist es so schwierig, Zeit zu schaffen? Der große Wurf wird nicht sofort gelingen. Eindeutige Priorisierung kann helfen. Der Product Owner erfüllt die Gatekeeper-Funktion und stoppt ungeplante Aufgaben von außen bzw. bringt sie in eine Priorisierungsreihenfolge. Die Zeitfresser müssen im Team erarbeitet und in kleinen Schritten gelöst werden. Manches geht hierbei sicherlich nur perspektivisch. Eine schreckliche Architektur beispielsweise wird nicht über Nacht besser.

Timeboxing und klare Struktur

Ja, man kann sich in Diskussionen verlieren und Aussagen werden redundant getätigt. Das passiert. Hier hat der oder die Moderator:in die Aufgabe, ebendies zu erkennen und die Diskussion entsprechend zu steuern. Es muss noch Zeit für die Findung eines Lösungsansatzes gegeben sein, bevor nur schnell etwas durchgeboxt wird. Ein reifes Team entwickelt sich dahin, dass die Struktur intrinsisch befolgt wird und nicht nur auf Ermahnung durch den Scrum Master. Die Charaktere finden ihre Rolle im Team und bringen sich ein.

Retro-Demenz vermeiden

Der Feind nachhaltig umgesetzter Vorhaben ist das Besprechen und Vergessen. Wie weiter oben erwähnt, funktioniert schon das Dokumentieren nicht, fehlt auch die Nachhaltigkeit. So kann es gut sein, dass die verabschiedeten Retro-Themen erst wieder in der nächsten Retrospektive adressiert werden. Insofern die Themen keinerlei Präsenz dazwischen haben, kann auch keine Nachhaltigkeit entstehen. Neben den bereits genannten Ansätzen (im Backlog einplanen oder explizites Ownership) kann allein schon das Ansprechen des Stands bestimmter Retro-Themen im Daily Wunder bewirken.

Déja-vu-Erlebnisse abschaffen

Mir tut es immer leid, wenn ich erfahre, dass Teams in den vergangenen Retrospektiven ständig dieselben Punkte ansprechen, ohne dass sich etwas ändert. Die Ursachen dafür sind vielfältig, aber die Stellschrauben der bereits genannten Lösungsansätze kommen da zum Tragen. Es ist wichtig, den Zyklus der ewigen Wiederholungen zu brechen, beispielsweise dass erstmal nur ein kleiner Schritt gegangen wird, mit der Umsetzung von etwas konkret Greifbarem.

Zum Schluss noch ein Retro-Thema, das ebenfalls überraschend häufig vorkommt: der Abbau von Kopfmonopolen bzw. ihr fehlender Abbau. Ein vollumfänglich cross-funktionales Team zu haben, ist fantastisch – jedoch äußerst selten. Gerade wenn es in die Tiefe geht, ist es eher unwahrscheinlich, dass Skills gut verteilt sind. Bottlenecks (auch vor allem außerhalb der Teams) führen zu Abhängigkeiten und der Disruption von Abläufen. Hier reicht es oft schon aus, im Planning zu klären, wer gemeinsam an welcher Aufgabe mitarbeiten sollte, um schrittweise Wissen zu verbreiten. Wenn es keine Zeit dafür gibt, dann siehe oben.

Das große Bild erkennen und Ansätze finden

(Fast) alles hängt miteinander zusammen. Eine holistische Sicht hilft dabei, zu erkennen, dass kleine Änderungen schon viel bewirken können. So lässt sich ein Momentum verursachen, das Teams den Status quo verlassen lässt und in ihrer Reife voranbringt.

Also: Seid offen, mutig und respektvoll im Umgang miteinander und der Arbeit. Wählt kleine Schlachten und vergesst dabei nicht, am größeren Rad der Strategie (habt ihr eine?) mitzudrehen. Sehenden Auges eine ungewollte Verpuffung herbeizuführen, sollte etwas von gestern sein.

The post Warum Agile Retrospektiven oft scheitern: Lösungen für mehr Erfolg appeared first on BASTA!.

Dass große Freiheit mit großer Verantwortung einhergeht, ist einer ältesten Scherze im Bereich des IT-Managements. Für Cloud Services gilt (logischerweise) Ähnliches: Desto weniger Optionen Entwickler:innen zur Verfügung stehen, desto wahrscheinlicher ist es, dass sie sich an vernünftigen Design Patterns orientieren.

Mit .NET Aspire schlägt Microsoft den angesprochenen Weg ein – schon in der Ankündigung findet sich das folgende Zitat, der Begriff „opinionated“ lässt sich in diesem Zusammenhang als „streng implementiert“ übersetzen: „.NET Aspire is an opinionated stack for building resilient, observable, and configurable cloud-native applications with .NET. It includes a curated set of components enhanced for cloud-native by including service discovery, telemetry, resilience, and health checks by default.“ [1]

Als Anbieter von Cloud-Lösungen ist Microsoft naturgemäß in einer einzigartigen Position, um der Nutzerschaft Vorgaben zu machen. Wenn man in der Lage ist, die Aufmerksamkeit der Entwickler:innen auf bestimmte Dienste zu richten, so lassen sich Kosten, beispielsweise für die Provisionierung, einsparen. In diesem Artikel werfen wir einen ersten Blick darauf, wie .NET Aspire funktioniert und welche praktischen Überlegungen bei der Nutzung zu beachten sind.

Inbetriebnahme der Arbeitsumgebung

Aus dem opinionated Aufbau des Entwicklungssystems folgt, dass Microsoft auch den Entwickler:innen bzw. ihren Workstationkonfigurationen enge Daumenschrauben angelegt. Wer mit Visual Studio arbeiten möchte, benötigt die brandaktuelle Preview-Version 17.9 – der Autor wird die Variante 17.9.0 Preview 1.1 verwenden und eine Windows-11-Workstation als Host einspannen. Im Visual Studio Installer findet sich dann in der Rubrik ASP.NET und Webentwicklung die Option für das Herunterladen der Payload .NET Aspire SDK (Preview) (Abb. 1).

Abb. 1: Aspire-Entwicklung setzt eine spezielle Payload voraus

Zu beachten ist außerdem, dass die Arbeit mit Aspire prinzipiell und immer die Verwendung von .NET in Version 8.0 voraussetzt. Im Hintergrund erfolgt der Großteil der Ausführung unter Nutzung von Docker-Containern. Aus diesem Grund setzt die Aspire-Payload auch das Vorhandensein von Docker Desktop voraus. Ein Produkt, dass der Visual Studio Installer schon aus lizenzrechtlichen Gründen nicht automatisch herunterladen darf.

Zur Behebung des Problems besuchen wir im ersten Schritt [2] und klicken dort auf den Knopf Download for Windows. Nach dem Herunterladen der rund 600 MB großen .msi-Datei installieren wir diese im Allgemeinen wie gewohnt. Wer Docker Desktop – wie der Autor – für die folgenden Experimente frisch installiert, muss darauf achten, dass der Startbildschirm des Produkts den erfolgreichen Start des Docker-Containers ankündigt.

Als Nächstes erfolgt der Wechsel in Visual Studio 2022, wo ein neues Projekt auf Basis der Vorlage .NET Aspire Starter Application entsteht. Die in Visual Studio implementierte Search Engine zeigt sich dabei übrigens widerspenstig. Suchen Sie bitte nach dem String „Aspire Starter“, um die Einschränkungen zu aktivieren. In der Vorlage implementiert Microsoft – auf Wunsch – dabei verschiedene vorgefertigte Elemente. Wichtig ist, dass sie im Drop-down-Menü Framework wie in Abbildung 2 gezeigt .NET 8.0 auswählen und die Checkbox für Redis aktivieren.

Abb. 2: Diese Checkbox spart Zeit und Kosten

Lohn der Mühen ist die Erzeugung des in Abbildung 3 gezeigten Projektskeletts, dass – man denke abermals an das Stichwort des opinionated Designs – aus einer ganzen Gruppe von Unterprojekten aufgebaut ist.

Abb. 3: Aspire Solutions sind durchaus kompliziert

Im Interesse der besseren Verständlichkeit ist es empfehlenswert, das Projekt im ersten Schritt unter Nutzung der Visual-Studio-Default-Payload HTTP zur Ausführung zu bringen. Hierdurch erscheinen die in Abbildung 4 gezeigten Fenster. Ein Blick auf die Docker-Desktop-Umgebung zeigt, dass Visual Studio auch einen Container für uns aktiviert hat (Abb. 5).

Abb. 4: Wer eine Aspire-Applikation startet, bekommt mehrere Fenster

Abb. 5: Dieser Container gehört zu uns

Nun wollen wir aber zum Browserfenster zurückkehren: Aspire-basierte Solutions werden von Microsoft prinzipiell mit einem Dashboard ausgestattet, das Konfiguration und Überwachung der verschiedenen Elemente der Solution erleichtert. Sinn dieser Vorgehensweise ist, dass technisch herausgeforderte Entwickler nicht mit der (oft komplizierten) Logik zum Monitoring der verschiedenen Cloud-Projekte kämpfen müssen.

Interessant ist für uns außerdem die Rubrik Projects, in der unter der Rubrik Endpoints zwei unterschiedliche Solutions zur Verfügung stehen. Unter Apiservice findet sich dabei ein Dienst, der JSON-Daten mit Dummy-Wetterdaten anzeigt. Das Webfrontend-Paket realisiert stattdessen eine Blazor-App. Zu beachten ist, dass das Anklicken der Endpoint URLs in der Rubrik Projects die jeweiligen Elemente direkt im Edge-Browser öffnet.

Analyse der Projektstruktur

Zum Zeitpunkt der Drucklegung dieses Artikels liegt Aspire noch in einem sehr frühen Zustand vor: Das äußert sich unter anderem darin, dass viele der Funktionen noch nicht im Benutzerinterface von Visual Studio angelegt sind. Als Erstes wollen wir uns das Projekt AspireApp1.AppHost ansehen, das als Dreh und Angelpunkt für die Aspire-Lösung dient und auch für die eigentliche Ausführung des Projekts verantwortlich ist. Am wichtigsten ist die Datei AspireApp1.AppHost.csproj, in der wir nach einer Analyse im Codeeditor das folgende zur Aspire-Umgebung gehörende Attribut vorfinden:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    . . .

    <IsAspireHost>true</IsAspireHost>

In der Datei Program.cs findet sich dann die eigentliche Initialisierung, die unser Wetterdatenanzeigesystem ins Leben ruft. Microsoft orientiert sich dabei übrigens an den aus .NET Generic Host und ASP.NET Core Web Host bekannten Design Patterns, weshalb mit diesen Technologien erfahrene Entwickler:innen einen schnelleren Umstieg erleben:

var builder = DistributedApplication.CreateBuilder(args);


var cache = builder.AddRedisContainer("cache");

Nach der Erzeugung des DistributedApplication-Objekts fügen wir diesen ersten Schritt einen Redis-Container hinzu: Aus der Methode AddRedisContainer lässt sich ableiten, dass es sich dabei um ein vorgefertigtes Modul handelt. Im nächsten Schritt folgt das Hinzufügen der zwei in unserer Solution manuell angelegten Projekte (Listing 1):

Listing 1

var apiservice = builder.AddProject<Projects.AspireApp1_ApiService>("apiservice");

builder.AddProject<Projects.AspireApp1_Web>("webfrontend")

  .WithReference(cache)

  .WithReference(apiservice);

builder.Build().Run();

Zum besseren Verständnis wollen wir an dieser Stelle auf die von Microsoft bereitgestellte und in Abbildung 6 gezeigte Grafik zurückgreifen, die die in unserem Aspire-Projekt vorhandenen Komponenten visualisiert.

Aspire-Applikationen bestehen intern aus verschiedenen Instanzen von Resourcen: Zum Zeitpunkt der Drucklegung sind drei bekannt. Als Erstes die durch AddProject hinzuzufügende ProjectResource, die ein .NET-Projekt kennzeichnet. Die ContainerResource – das Einpflegen erfolgt durch AddContainer – kümmert sich um Container-Images, während die durch AddExecutable einzufügende ExecutableResource-Klasse mehr oder weniger beliebige .exe-Dateien in den Aspire-Verbund einbindet. Wichtig ist außerdem noch, dass jede im Verbund lebende Ressource prinzipiell und immer einen einzigartigen Namen aufweisen muss.

Zentralisierte Orchestrierung und Konfiguration

Ein von Quereinsteiger:innen im Bereich der Elektronik häufig unterschätztes Problem ist, das Hochfahren der einzelnen Spannungsversorgungen in einem System zu verwalten. Benötigt ein System mehrere Spannungen und tauchen diese in der falschen Reihenfolge auf, so kommt es mitunter zu seltsamen Problemen.

Im Fall von Cloud-basierten bzw. verteilten Systemen gibt es ähnliche Probleme: Steht ein Konfigurations-Microservice nicht zur Verfügung, wenn ein anderer Dienst hochfährt, entsteht Durcheinander. Damit ist auch schon einer der wichtigsten Problemfälle beschrieben, denen Microsoft mit .NET Aspire entgegenwirken möchte.

Zum Verständnis des Orchestrierungsprozesses wollen wir uns die Datei Program.cs ansehen, die im Projekt AspireApp1.ApiService unterkommt und für die Bereitstellung des API-Endpunkts unseres Wettervorhersagesystems verantwortlich zeichnet. Die Initialisierung erfolgt über einen AppBuilder:

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
builder.Services.AddProblemDetails();
var app = builder.Build();
app.UseExceptionHandler();

Interessant ist hier der Aufruf der Methode AddServiceDefaults(), die Aspire zur Nutzung der projektglobalen Standardeinstellungen für verschiedene häufig benötigte Elemente der Solution animiert. Die restliche Initialisierung kümmert sich vor allem um das Einrichten eines Event Handler, der die ausgegebenen Informationen per Zufallsgenerator generiert. Um es kompakt zu halten, drucken wir diesen Teil des Codes gekürzt ab (Listing 3). Wichtig ist noch der Aufruf von Run, der die Aspire-Arbeitsumgebung zur eigentlichen Ausführung des Codes animiert. Angemerkt sei, dass Microsoft in .NET Aspire auch verschiedene andere Methoden zur Konfiguration anbietet – unter [4] findet sich eine Übersicht.

Listing 3

app.MapGet("/weatherforecast", () =>
{
  var forecast = Enumerable.Range(1, 5).Select(index =>

    . . .
  return forecast;
});
app.MapDefaultEndpoints();
app.Run();

Interessanter ist für uns an dieser Stelle die Frage, woher der Aspire-Orchestrator die anzuwendenden Einstellungen bezieht und welche Teile der Solutions er zu konfigurieren sucht. Die Antwort auf diese Frage findet sich im Projekt AspireApp1.ServiceDefaults. Ich möchte mich auch an dieser Stelle kurz fassen; unter [5] findet sich eine vollständige Analyse des vergleichsweise reich kommentierten Codes.

Im Prinzip erfolgt die Initialisierung durch statische Methoden. Am wichtigsten ist die Funktion AddServiceDefaults, die, wie hier gekürzt gezeigt, verschiedene Basisdienste wie den Orchestrierungsservice konfiguriert und zur Solution hinzufügt:

public static IHostApplicationBuilder AddServiceDefaults(this IHostApplicationBuilder builder) {
  builder.ConfigureOpenTelemetry();
  builder.AddDefaultHealthChecks();
  builder.Services.AddServiceDiscovery();
  . . .

Im Bereich der Telemetriedatenerfassung setzt .NET Aspire auf OpenTelemetry – weitere Informationen hierzu finden sich unter [6]. Wichtig ist, dass die in .NET Aspire enthaltene Implementierung ebenfalls konfiguriert werden muss. Das ist die Aufgabe der Methode ConfigureOpenTelemetry, die wir hier aus Platzgründen nicht abdrucken.

Zu guter Letzt implementiert Aspire auch noch Health Checks. Dabei handelt es sich um Methoden, die das Überprüfen der Systemgesundheit des von .NET Aspire verwalteten Dienst ermöglichen. Ihre Einrichtung erfolgt in den Methoden AddDefaultHealthChecks und MapDefaultEndpoints.

Aspire-Komponenten erlauben das einfache Einpflegen häufig benötigter Dienste. Neben dem Orchestrierungs-Service ist vor allem die Komponentenfunktionalität von .NET Aspire relevant. Dabei handelt es sich um ein Feature, mit dem Microsoft die direkte Integration häufig benötigter Komponenten in die Solution ermöglicht. Zum Zeitpunkt der Drucklegung dieses Artikels bietet die unter [7] ansprechbare Liste dabei die in Abbildung 7 gezeigten Komponenten an.

Abb. 7: In Microsofts Komponentenzoo wimmelt es

Zu Demonstrationszwecken werden wir in den folgenden Schritten einen Azure-Dienst hinzufügen. Im ersten Schritt klicken wir die Projektmappe rechts an, und entscheiden uns für den Assistenten zum Hinzufügen eines neuen Projekts.

Suchen Sie nach der Vorlage Workerdienst und entscheiden Sie sich für die Variante für C#. Relevant ist, dass diese Vorlage nicht Teil der von .NET Aspire eingefügten Elemente ist. Als Name wird der Autor in den folgenden Schritten AspireApp1.AzWorker vergeben. Interessant ist außerdem, dass Sie im Projektkonfigurationsfenster, wie in Abbildung 8 gezeigt, die Option haben, die Checkbox In Aspire-Orchestrierung eintragen zu aktivieren. Diese sollten Sie auswählen, weil sich Visual Studio dann darum kümmert, unsere Worker-Dienste teilweise in die Solutions einzupflegen.

Abb. 8: Die Checkbox erleichtert das Ins-Leben-Rufen neuer Services

Dank der markierten Checkbox gibt es in Program.cs eine nach folgendem Schema erfolgende Anpassung, die sich um das Einpflegen der neuen Komponente kümmert:

. . .
builder.AddProject<Projects.AspireApp1_AzWorker>("aspireapp1.azworker");
builder.Build().Run();

Im nächsten Schritt klicken wir das neu erzeugte Paket rechts an, um die NuGet-Paketverwaltung zu öffnen. Ebenda entscheiden wir uns für das Paket Aspire.Azure.Storage.Blobs, das zum Zeitpunkt der Drucklegung dieses Artikels als Version 8.0.0-preview.1.23557.2 vorliegt. Danach verfahren wir analog mit dem Paket Aspire.Azure.Storage.Queues.

Angemerkt sei hier, dass .NET Aspire als .NET-Technologie logischerweise nicht von den Zwängen befreit ist, die im Bereich der .NET-Technologien zum Tragen kommen. Wichtig ist, dass das Hinzufügen der NuGet-Pakete in allen Solutions gleichermaßen erforderlich ist, die später mit dem jeweiligen Feature des verteilten Systems interagieren wollen oder sollen.

Im nächsten Schritt ist ein Wechsel in das Azure-Backend erforderlich, wo im ersten Schritt ein neuer Storage-Account entsteht. Der Autor vergab in den folgenden Schritten den Namen susaspireexperiment und entschied sich für die preiswerteste Redundanzklasse und eine geringe Performance-Tier. Für unsere hier durchgeführten Experimente ist ein Mehr an Systemperformance nicht notwendig, würde die Kosten aber immens erhöhen.

Im nächsten Schritt benötigen wir einen Blob-Storage-Container und eine Storage-Queue-Instanz: Wichtig ist in beiden Fällen, die Connection-Strings zur Verfügung zu haben. Wichtig ist außerdem, den Connection-String auf Ebene des Storage-Accounts zu beziehen – Abbildung 9 zeigt den korrekten Platz.

Abb. 9: Der Connection-String ist zum Abernten bereit

Als Nächstes stellt sich die Frage, wie der derzeit als String vorliegenden Connection-String in die .NET Aspire Solution einbezogen werden kann. Die Antwort darauf ist die Datei appsettings.json – beachten Sie, dass diese Adaption für jedes mit den Azure-Ressourcen zu verbindende Projekt von Hand durchgeführt werden muss (Listing 4).

Listing 4
{
  "Logging": {
    . . .
  },
  "ConnectionStrings": {
    "blobdb": "DefaultEndpointsProtocol=https;AccountName=susaspire. . .",
    "queuedb": "DefaultEndpointsProtocol=https;AccountName=susaspire. . ."
  }
}

Im vorliegenden Fall ist derselbe Schlüssel unter zwei unterschiedlichen Namen angelegt: Ursache dafür ist die weiter oben erwähnte Bedingung, dass Namen nur einmal im Verbund vorkommen dürfen. Für die erfolgreiche Initialisierung der Containerinfrastruktur ist im AppHost außerdem das Hinzufügen des NuGet-Pakets Aspire.Hosting.Azure erforderlich.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Nach der Erzeugung der Service-Primitiva müssen diese im ersten Schritt zum Webprojekt hinzugefügt werden. Hierzu sind einfach weitere Aufrufe der Methode Add* notwendig, die die schon vorhandenen Aufrufe um die weiteren benötigten Komponenten ergänzen:

using Microsoft.Extensions.Hosting;
var builder = DistributedApplication.CreateBuilder(args);
var storage = builder.AddAzureStorage("tamsstore");
var blobs = storage.AddBlobs("blobdb");
var queues = storage.AddQueues("queuedb");

Im Fall des neuen von Visual Studio hinzugefügten Workers stehen noch keine Referenzen zur Verfügung, weshalb hier etwas umfangreichere Anpassungen der Deklaration anfallen:

builder.AddProject<Projects.AspireApp1_AzWorker>("aspireapp1.azworker")
  .WithReference(blobs)
  .WithReference(queues);

Im Webprojekt muss im nächsten Schritt die Deklaration aus Listing 5 eingefügt werden.

Listing 5

builder.AddProject<Projects.AspireApp1_Web>("webfrontend")
  .WithReference(blobs)
  .WithReference(queues)
  .WithReference(cache)
  .WithReference(apiservice);


var builder = WebApplication.CreateBuilder(args);
builder.AddAzureBlobService("blobdb");
builder.AddAzureQueueService("queuedb");
builder.AddServiceDefaults();

Danach wechseln wir in die Webapplikation, in der einige benötigte Dependencies importiert werden, wie in Listing 6 zu sehen ist.

Listing 6

@page "/counter"
@rendermode InteractiveServer

@using System.ComponentModel.DataAnnotations
@using Azure.Storage.Blobs
@using Azure.Storage.Queues

@inject BlobServiceClient BlobClient
@inject QueueServiceClient QueueServiceClient

Der Container erschwert Aspire-Entwicklern an dieser Stelle das Leben insofern, als er die in die Blobs zu schreibenden Informationen ausschließlich in Form von Streams erwartet. Wer wie wir hier einen String hochladen möchte, muss diesen zunächst vergleichsweise aufwendig in eine Stream-Instanz umwandeln (Listing 7).

Listing 7
@code {
  private int currentCount = 0;
  private async void IncrementCount() {
    String usefulData ="ThisIsTheTestData";
    var stream = new MemoryStream();
    var writer = new StreamWriter(stream);
    writer.Write(usefulData);
    writer.Flush();
    stream.Position = 0;
    var docsContainer = BlobClient.GetBlobContainerClient("fileuploads");
    await docsContainer.UploadBlobAsync(  "TestFile",stream);
    currentCount++;
  }
}

Wer den Knopf dann anklickt, sieht das Aufscheinen eines Fehler-Callouts (Abb. 10) in der von .NET Aspire ebenfalls zur Verfügung gestellten Arbeitsoberfläche. Das Anklicken dieser Option führt zum Aufscheinen eines zusätzlichen Fensters, das – ganz analog zum klassischen Visual Studio – sogar Details zum Aufrufstack und zu den im Exception-Objekt angelegten Fehlerinformationen anbietet.

Abb. 10: Während der Ausführung von Aspire-Applikation auftretende Fehler werden im Web-Frontend zentralisiert präsentiert

Eine detaillierte Analyse des zurückgelieferten Fehlerstrings führt uns dann auch schon zum Ziel: Der Autor hatte einen Tippfehler: Der im Azure-Cloud-Backend angelegte Name des Blobs stimmte nicht mit dem überein, den die Methode erwartet hatte. Mit diesem Wissen lässt sich der Code wie folgt verbessern:

var docsContainer = BlobClient.GetBlobContainerClient("susaspirecont");

Bei der Programmausführung zeigt nun der Blob im Backend die per Aspire angelieferten Informationen an.

Fazit

Mit .NET Aspire integriert Microsoft Lifecycle-Management in die .NET-Arbeitsumgebung: eine Funktion, die bisher beispielsweise in Docker Compose zur Verfügung gestellt wurde. Schon durch die Möglichkeit, mehr Services aus einer Hand zu beziehen, geht das mit einer Erhöhung der Lebensqualität für Entwickler:innen einher. Fraglich ist allerdings, ob bzw. inwiefern diese systemimmanenten Vorteile ausreichen, um Microsoft das Angreifen der gut etablierten Konkurrenz im Umfeld der Containerorchestrierung zu ermöglichen.

Links & Literatur

[1] https://devblogs.microsoft.com/dotnet/introducing-dotnet-aspire-simplifying-cloud-native-development-with-dotnet-8/

[2] https://www.docker.com/products/docker-desktop/

[3] https://learn.microsoft.com/en-us/dotnet/aspire/app-host-overview

[4] https://learn.microsoft.com/en-us/dotnet/aspire/service-defaults

[5] https://learn.microsoft.com/en-us/dotnet/aspire/service-discovery/overview

[6] https://opentelemetry.io

[7] https://learn.microsoft.com/en-us/dotnet/aspire/components-overview?tabs=dotnet-cli

The post Cloud-Native Entwicklung mit .NET Aspire: Praxistest und bewährte Design Patterns appeared first on BASTA!.

Bei der Diskussion um Sicherheit in Webanwendungen rückt unweigerlich die Frage in den Fokus, was genau es zu schützen gilt. In diesem Kontext bietet die sogenannte CIA-Triade [1] einen klaren Rahmen, indem sie drei essenzielle Sicherheitsziele definiert – Vertraulichkeit, Integrität und Verfügbarkeit (Abb. 1).

Abb. 1: Die CIA-Triade

1. Vertraulichkeit (Confidentiality): Dieses Ziel bezieht sich auf den Schutz von Daten vor unbefugtem Zugriff oder Offenlegung. Es gewährleistet, dass sensible Informationen nur für diejenigen zugänglich sind, die berechtigt sind. Maßnahmen zur Aufrechterhaltung der Vertraulichkeit umfassen Verschlüsselung, Zugriffskontrollen und strenge Authentifizierungsverfahren.
2. Integrität (Integrity): Integrität bezieht sich auf die Bewahrung der Genauigkeit und Vollständigkeit von Daten. Es geht darum, sicherzustellen, dass Informationen nicht ohne Autorisierung verändert, manipuliert oder auf andere Weise beschädigt werden. Methoden zur Sicherung der Integrität umfassen Hashfunktionen, digitale Signaturen und Redundanzmechanismen.
3. Verfügbarkeit (Availability): Verfügbarkeit bedeutet, dass Informationen und Ressourcen im Bedarfsfall zugänglich und nutzbar sind. Dieses Ziel soll sicherstellen, dass Systeme und Daten trotz verschiedener Bedrohungen wie Hardwareausfällen, Softwareproblemen oder Cyberangriffen zugänglich bleiben. Maßnahmen zur Gewährleistung der Verfügbarkeit sind unter anderem Back-up-Systeme, Redundanzen und effiziente Wartungsprozesse.

Die CIA-Triade dient als Grundlage für das Verständnis und die Bewertung von Sicherheitsmaßnahmen in IT-Systemen. Mit der Integration von Authentifizierung und Autorisierung sorgen wir also für einen Schutz des Sicherheitsziels der Vertraulichkeit: Schutz vor unbefugtem Zugriff.

Authentifizierung und Autorisierung

Authentifizierung und Autorisierung sind zwei grundlegende Sicherheitskonzepte, die vor allem in der Welt der Informationstechnologie Verwendung finden. Immer wieder werden beide Konzepte vermischt oder sogar synonym verwendet, daher möchte ich mit einer kleinen Definition beide Sicherheitskonzepte noch einmal voneinander abtrennen:

Authentifizierung bezieht sich hierbei auf den Prozess, mit dem überprüft wird, ob jemand oder etwas tatsächlich das ist, was es vorgibt zu sein. Im Kontext von Webanwendungen bedeutet das in der Regel die Überprüfung der Identität eines Benutzers, typischerweise durch Benutzername und Passwort, biometrische Daten, Einmal-Passwörter oder andere Methoden. Authentifizierung ist der erste Schritt, um zu gewährleisten, dass der Zugriff auf ein System oder eine Anwendung von einer legitimen Quelle aus erfolgt. Oftmals werden bei der Authentifizierung sogenannte zweite Faktoren (Multi-factor Authentication) genutzt, um eine weitere Sicherheitsstufe zu integrieren. Das kann in Form eines SMS-Codes oder über eine speziell dafür ausgelegte Applikation [2] auf dem Smartphone integriert werden.

Autorisierung hingegen ist der Prozess der Entscheidung, ob ein authentifizierter Benutzer Zugriff auf bestimmte Ressourcen oder Funktionen erhalten soll. Das beinhaltet in der Regel die Überprüfung von Benutzerrechten oder Rollen gegenüber den Zugriffsanforderungen. Autorisierung erfolgt nach der Authentifizierung und bestimmt, was ein Benutzer in einem System oder einer Anwendung tun darf.

Diese beiden Konzepte sind eng miteinander verknüpft, aber dennoch unterschiedlich:

• Authentifizierung stellt fest, wer der Benutzer ist.
• Autorisierung bestimmt, was der Benutzer tun darf.

Die Herausforderung besteht darin, ein Gleichgewicht zu finden zwischen dem Schutz sensibler Daten und Ressourcen und der Bereitstellung eines nahtlosen und benutzerfreundlichen Erlebnisses für legitime Benutzer. So ist beispielsweise eine Ressource optimal geschützt, wenn der Benutzer noch vier oder mehr weitere Faktoren zur Authentifizierung angeben muss; der Benutzer selbst ist aber vermutlich schnell genervt von dem bereitgestellten Authentifizierungsprozess.

Authentifizierung in einer Webapplikation

Bei der Integration eines Authentifizierungsprozesses in eine Webanwendung stehen uns im Wesentlichen zwei etablierte Methoden zur Verfügung:

• cookiebasierte Authentifizierung
• tokenbasierte Authentifizierung

Beide Ansätze finden heutzutage große Anwendung und bringen jeweils ihre spezifischen Vorzüge und Herausforderungen mit sich. Im Folgenden werde ich diese beiden Konzepte detailliert erörtern und die potenziellen Vor- und Nachteile jedes Ansatzes beleuchten, um ein tieferes Verständnis ihrer Anwendung und Wirksamkeit in modernen Webanwendungen zu vermitteln.

Cookiebasierte Authentifizierung

Cookiebasierte Authentifizierung ist ein verbreiteter Ansatz zur Verwaltung von Benutzersitzungen in Webanwendungen. Dabei wird nach erfolgreicher Authentifizierung des Nutzers ein kleines Stück Daten – bekannt als Cookie – vom Server an den Webbrowser des Benutzers gesendet und dort gespeichert. Dieses Cookie wird dann bei jeder folgenden Anfrage des Browsers an den Server zurückgesendet, wodurch der Server den Benutzer und dessen Sitzungszustand über verschiedene Anfragen hinweg verfolgen kann. Dabei werden folgende Schritte durchgeführt:

• Anmeldung: Der Benutzer gibt seine Anmeldeinformationen (wie Benutzername und Passwort) ein. Nach erfolgreicher Überprüfung dieser Informationen durch den Server wird ein Sitzungscookie erstellt (2).
• Sitzungscookie: Dieses Cookie enthält in der Regel eine einzigartige Sitzungs-ID, die den Benutzer identifiziert. Es speichert keine sensiblen Benutzerdaten direkt, da Cookiedaten innerhalb eines Webbrowsers gespeichert werden und diese theoretisch jederzeit einsehbar sind (3).
• Sicherheit: Um die Sicherheit zu erhöhen, können Cookies mit Attributen wie httpOnly (verhindert den Zugriff durch Client-side-Skripte) und Secure (sorgt dafür, dass Cookies nur über HTTPS gesendet werden) versehen werden [3].
• Sitzungsverwaltung: Bei jeder Anfrage des Benutzers an den Server wird das Sitzungscookie mitgesendet. Der Server prüft die Gültigkeit des Cookies und erlaubt den Zugriff auf geschützte Ressourcen, wenn das Cookie gültig ist (4).
• Ablauf und Abmeldung: Cookies haben ein Ablaufdatum. Nach dem Ablauf oder wenn der Benutzer sich explizit abmeldet, wird das Cookie entweder vom Server als ungültig markiert oder vom Browser gelöscht.

Abb. 2: Nach dem Log-in wird ein Sitzungscookie erstellt

Abb. 2: Nach dem Log-in wird ein Sitzungscookie erstellt

Abb. 3: Das Cookie wird im Browser gespeichert

Abb. 4: Der Server prüft die Gültigkeit des gespeicherten Cookies

Die cookiebasierte Authentifizierung ist besonders effektiv für traditionelle Webanwendungen, bei denen der Server eine aktive Rolle bei der Sitzungsverwaltung spielt. Ein weiterer wichtiger Faktor ist das Management der Cookies über den Browser: Entwickler:innen müssen hierbei keinen eigenen Code für das Verwalten der Cookies schreiben. Das verringert die Komplexität der Webanwendung, da wir uns darauf verlassen können, dass der Webbrowser bei jeder Anfrage an unser Backend die Cookiedaten automatisch mitsendet.

Durch den Einsatz der bereits erwähnten Cookieattribute secure und httpOnly erhöhen wir die Sicherheit in der Verwaltung unserer Cookies. Insbesondere bietet das Setzen des httpOnly-Attributs einen wirksamen Schutz gegen Manipulationen des Cookies durch bösartige JavaScript-Einschleusungen, bekannt als Cross-site-Scripting-(XSS-)Attacken. Dieses Attribut bewirkt, dass die Cookies nicht mehr über das Browser-API document.cookie zugänglich sind, wodurch ein zusätzliches Sicherheitsniveau im Umgang mit sensiblen Benutzerdaten etabliert wird.

Auch wenn die Nutzung von Cookies bösartige Manipulationen über JavaScript verringern kann, sind sie leider die Hauptursache für sogenannte Cross-site-Request-Forgery-(CSRF-)Attacken.

Eine CSRF-Attacke, auch als „One Click Attack“ oder „Session Riding“ bekannt, ist eine Art von Cyberangriff, bei dem ein Angreifer Nutzer dazu bringt, ungewollte Aktionen auf einer Webseite auszuführen, auf der sie gerade angemeldet sind. Das geschieht typischerweise, ohne dass der Nutzer sich dessen bewusst ist. Hierbei wird genau die Tatsache ausgenutzt, dass das Opfer bereits auf der Zielwebseite über ein Cookie authentifiziert ist und dieses Cookie bei allen Anfragen auf die Zielwebseite automatisch vom Webbrowser mitgesendet wird. Die Anfrage kann daraufhin verschiedene Aktionen auslösen, wie das Ändern von Kontoinformationen, das Versenden von Nachrichten oder das Durchführen von Transaktionen. Die Open-Web-Application-Security-Project-(OWASP-)Organisation hat einige Tipps und Tricks in einem Cheat Sheet [4] zusammengestellt, wie man sich am besten vor CSRF-Attacken schützen kann.

Neben der Einführung von potenziellen CSRF-Attacken haben Cookies noch einen weiteren Nachteil: Sie sind weniger geeignet für moderne, verteile Architekturen wie Single Page Applications (SPAs) und Microservices, in denen oft tokenbasierte Authentifizierungsmethoden, wie z. B. JSON Web Tokens (JWT), bevorzugt werden. In Anbetracht dessen möchten wir uns nun der tokenbasierten Authentifizierung zuwenden und diese eingehend beleuchten.

Tokenbasierte Authentifizierung

Tokenbasierte Authentifizierung ist ein Verfahren, bei dem statt traditioneller Session-Cookies ein Authentifizierungstoken für die Identifizierung und Verwaltung von Benutzersitzungen verwendet wird. Dieses Verfahren wird wie bereits erwähnt häufig in modernen Webanwendungen und insbesondere in API-basierten Diensten und Single-Page-Anwendungen eingesetzt. Folgendes sind die Kernaspekte der tokenbasierten Authentifizierung:

• Authentifizierung und Tokenerstellung: Der Benutzer gibt seine Anmeldeinformationen (Benutzername und Passwort) ein. Nach erfolgreicher Überprüfung erstellt der Server ein Token, oft ein JSON Web Token (JWT), das Informationen über den Benutzer und die Sitzung enthält. Meist kommt hierbei ein sogenannter externer Identity Provider ins Spiel der die sichere Generierung und Benutzerverwaltung übernimmt (5).
• Tokenversendung: Das Token wird an den Client (den Browser oder die Anwendung des Benutzers) gesendet und dort gespeichert, beispielsweise im Local Storage, in einer Session oder in einem Cookie (6).
• Clientseitige Verwendung des Tokens: Bei jeder folgenden Anfrage an den Server fügt der Client das Token im HTTP-Header hinzu. Dies dient als Nachweis der Authentifizierung und Autorisierung für die Anfrage (7).
• Serverseitige Validierung: Der Server validiert das Token bei jeder Anfrage, um sicherzustellen, dass es gültig und nicht manipuliert wurde. Nach erfolgreicher Validierung gestattet der Server den Zugriff auf geschützte Ressourcen.
• Ablauf und Erneuerung: Token haben in der Regel ein Ablaufdatum. Nach Ablauf kann der Benutzer entweder erneut seine Anmeldeinformationen eingeben oder ein Refresh-Token verwenden, um ein neues Zugriffstoken zu erhalten.

Abb. 5: Bei der tokenbasierten Authentifizierung ist meist ein Identity Provider im Spiel

Abb. 6: Das Token wird an den Client gesendet

Abb. 7: Das Token im Header dient als Authentifizierungsnachweis

Diese Methode ist besonders effektiv für Anwendungen, die Ressourcen über mehrere Server oder Dienste verteilen, da das Token leicht zwischen verschiedenen Systemkomponenten übertragen werden kann, ohne die Notwendigkeit einer zentralen Sitzungsverwaltung.

Token können auf verschiedene Arten in Browsern oder Webanwendungen gespeichert werden. Doch auch hierbei gibt es einiges zu beachten: Wenn Sie den lokalen Speicher eines Browsers verwenden, kann eine Subdomain nicht auf Tokens zugreifen. Sie können jedoch von jedem JavaScript-Code auf der Webseite sowie von Browser-Plug-ins aufgerufen und manipuliert werden. Das ist also keine empfohlene Methode – sie stellt zum einen ein Sicherheitsrisiko dar und darüber hinaus müssen Sie den Speicher selbst verwalten.

Die Verwaltung der Tokens erfordert oftmals viel manuelle Arbeit: Ein Token kann beispielsweise nicht widerrufen werden. Selbst wenn ein Token gestohlen wird, bleibt es gültig, bis es abläuft, was zu einer schwerwiegenden Sicherheitslücke führt. Um dieses Problem zu umgehen, müssen Sie eine Sperrlistentechnik implementieren, die eine komplexere Einrichtung erfordert.

Aber auch ohne an bösartige Attacken zu denken, kann eine eigenständige Verwaltung der Tokens kompliziert sein: Die Informationen in einem Token stellen eine Momentaufnahme zum Zeitpunkt der ursprünglichen Erstellung des Tokens dar. Der zugehörige Benutzer verfügt möglicherweise nun über andere Zugriffsebenen oder wurde vollständig aus dem System entfernt.

Angesichts der Komplexität und Bedeutung einer sicheren Tokengenerierung und -verwaltung empfiehlt es sich fast immer, diese Aufgaben nicht eigenständig zu übernehmen. Oft ist es vorteilhafter und sicherer, externe Identity-as-a-Service-Anbieter (sogenannte Identity Provider wie Azure Active Directory [5] oder Auth0 [6] by Okta) zu integrieren oder etablierte Identity- und Access-Management-Tools zu verwenden, wie sie beispielsweise mit Keycloak [7] von Red Hat angeboten werden.

Diese Lösungen bieten nicht nur eine robuste Verwaltung von Nutzerkonten und Tokens, sondern erleichtern durch bereitgestellte Entwicklerbibliotheken auch signifikant die Integration in Webanwendungen. Dadurch wird nicht nur die Sicherheit erhöht, sondern auch der Entwicklungsprozess effizienter und benutzerfreundlicher gestaltet.

Wie das Ganze nun konkret aussehen kann, möchte ich Ihnen anhand einer beispielhaften Implementierung demonstrieren. Hierbei werde ich den Identity Provider Auth0 by Okta nutzen, um Authentifizierung und Autorisierung in eine bestehende Angular-Applikation zu integrieren.

Bevor wir mit der konkreten Implementierung starten können, müssen wir uns zuvor kurz mit den offenen Standards für Autorisierung und Authentifizierung auseinandersetzen. Diese beschreiben verschiedene Workflows und Richtlinien, wie eine Webanwendung ein Token sicher erhalten kann, und bieten eine Spezifikation für weitere Authentifizierungskonzepte wie Single Sign-on (SSO) oder die Integration sozialer Medien (Social Log-in).

OAuth und OpenID Connect

OpenID Connect ist eine Identitätsverwaltungsschicht, die auf dem OAuth-Protokoll aufbaut. Sie ermöglicht es Clients, die Identität eines Endbenutzers zu verifizieren und grundlegende Profilinformationen über den Benutzer zu erhalten. OpenID Connect wird oft für Single-Sign-on-(SSO-)Lösungen verwendet und ist weit verbreitet in modernen Webanwendungen und Mobile-Apps. OpenID Connect erweitert hierbei OAuth um die Einführung von ID-Tokens. Diese Tokens sind im JWT-Format und enthalten Informationen über die Authentifizierung des Benutzers.

OAuth ist ein offener Standard für Zugriffsdelegation, der es Benutzern ermöglicht, Dritten eingeschränkten Zugriff auf ihre Ressourcen auf einem anderen Server zu gewähren, ohne dabei ihre Zugangsdaten preiszugeben. Ursprünglich für die API-Autorisierung entwickelt, hat sich OAuth zu einem Schlüsselstandard in der modernen Web- und Anwendungsentwicklung entwickelt. OAuth ermöglicht es Anwendungen, im Namen des Benutzers auf Ressourcen zuzugreifen, indem sie ein Zugriffstoken verwenden, das vom Ressourcenbesitzer (dem Benutzer) genehmigt wurde. Das bedeutet, dass Anwendungen keine Benutzernamen und Passwörter speichern müssen. Kurz gesagt ist OAuth eine Spezifikation für die Autorisierung eines Benutzers: Sie können spezifische Berechtigungen (Scopes) an die Anwendungen vergeben, was eine fein abgestimmte Kontrolle darüber ermöglicht, auf welche Informationen und Funktionen die Anwendung zugreifen darf.

OAuth definiert verschiedene Flows (auch als Grant Types bezeichnet), um unterschiedliche Anwendungsfälle und Szenarien für die Authentifizierung und Autorisierung zu unterstützen. Jeder dieser Flows beschreibt einen spezifischen Prozess zur Erlangung eines Zugriffstokens – dem sogenannten Access-Token.

Je nach Anwendung werden verschiedene Flows empfohlen. Die aktuelle Version OAuth 2.1 [8] spezifiziert hierbei hauptsächlich drei Flows:

• Client Credentials Flow
• Device Code Flow
• Authorization Code Flow mit Proof-Key-Code-Exchange-(PKCE-)Erweiterung

Der Client Credentials Flow wird immer dann verwendet, wenn der Zugriff zwischen zwei Anwendungen ohne Benutzerinteraktion erfolgt. Die Anwendung authentifiziert sich mit ihren eigenen Credentials (nicht mit Benutzer-Credentials) beim OAuth-Server und erhält ein Zugriffstoken. Der Device Code Flow wird für Geräte genutzt, die keine einfache Möglichkeit bieten, Text einzugeben (wie Smart-TVs oder Spielkonsolen). Es verwendet ein Gerät, das einen Code anzeigt, den der Benutzer auf einem anderen Gerät (z. B. einem Smartphone) eingibt, um die Authentifizierung zu bestätigen.

Wenn wir mit Angular eine SPA entwickeln, wird empfohlen, dass wir den Authorization Code Flow mit PKCE nutzen. Dieser Flow ist für Anwendungen gedacht, die auf einem Server laufen. Bei einem einfachen Authorization Code Flow (ohne PKCE-Erweiterung) authentifiziert sich der Benutzer zunächst bei seinem Identity Provider und erteilt der Anwendung die Berechtigung (Abb. 8). Daraufhin erhält die Anwendung einen Autorisierungscode, den sie gegen ein Zugriffstoken eintauschen kann (Abb. 9). Dieser Flow gilt als einer der sichersten, da die Nutzer-Credentials zu keinem Zeitpunkt in unserer Frontend-Applikation einsehbar sind.

Abb. 8: Authentifizierung beim Identity Provider

Abb. 9: Autorisierungscode wird gegen Access-Token getauscht

Mit der Proof-Key-Code-Exchange-Erweiterung – die seit OAuth 2.1 auch verpflichtend ist – fügt man dem Authorization Code Flow noch eine weitere Sicherheitsstufe hinzu. Hierbei generiert der Client einen zufälligen String, bekannt als Code Verifier. Daraufhin erstellt der Client eine Code Challenge aus diesem Verifier, in der Regel, indem er einen Hashwert (SHA256) des Verifiers bildet und den Hash dann in Base64-URL kodiert. Bei der erneuten Authentifizierung des Benutzers werden neben den Credentials die Code Challenge und die Hashfunktion mitgegeben, mit der eben diese Code Challenge erstellt wurde. Daraufhin erhält, wie auch zuvor, die Anwendung einen Autorisierungscode und sendet diesen, diesmal mit dem Code Verifier, an seinen Identity-Provider. Dieser verwendet den empfangenen Code Verifier, um die Code Challenge zu generieren (d. h., er berechnet den SHA256-Hash und kodiert ihn in Base64-URL). Der Identity-Provider vergleicht dann die generierte Challenge mit der ursprünglich vom Client gesendeten Challenge. Stimmen diese überein, weiß der Server, dass die Anfrage vom gleichen Client stammt, der den Autorisierungscode angefordert hat und liefert ebenfalls das Access-Token aus.

Zum Glück entfällt die Notwendigkeit, sich mit den Details der Implementierung dieser Flows auseinanderzusetzen, da das von externen Bibliotheken, wie beispielsweise denen, die Auth0 by Okta bereitstellt, abgedeckt wird. Dennoch ist ein grundlegendes Verständnis der verschiedenen OAuth Flows von unschätzbarem Wert, um eine fundierte und sichere Entscheidung über den am besten geeigneten Flow für unsere spezifischen Anforderungen treffen zu können.

Konfiguration des Identity Provider

Wie bereits erwähnt werde ich in meiner Beispielimplementierung den Identity Provider Auth0 by Okta verwenden. Sämtliche gezeigten Funktionalitäten und Konzepte finden sich aber in anderen Identity-as-a-Service-Lösungen ebenfalls wieder. Auth0 bietet einen kostenlosen Nutzungsplan [9], der bis zu 7 500 aktive Benutzer und unbegrenzte Log-ins umfasst. Diese kostenlosen Pläne sind ideal, um die grundlegenden Funktionen von Auth0 by Okta kennenzulernen und zu testen, wie gut sie sich in Ihre Anwendung oder Ihr Projekt integrieren lassen.

Wenn wir uns nun kostenlos registrieren, können wir eine neue Applikation – auch Tenant genannt – erstellen (Abb. 10). Ein Tenant bezeichnet eine dedizierte Instanz der Identity-Provider-Plattform, die für einen Kunden oder ein Projekt eingerichtet wird. Es ist im Wesentlichen ein separater Container, in dem alle Ihre Benutzer, Sicherheitseinstellungen, Anwendungen und Konfigurationen für Ihre Authentifizierungs- und Autorisierungsvorgänge gespeichert werden. Jeder Tenant bei Auth0 ist durch eine eindeutige Domain gekennzeichnet und isoliert, was bedeutet, dass die Daten und Konfigurationen eines Tenants nicht mit denen anderer Tenants geteilt werden.

Abb. 10: Erstellen einer Applikation

Nachdem der Tenant erfolgreich angelegt wurde können wir diesen nun konfigurieren. Ebenso können wir alle wichtigen Daten direkt einsehen (beispielsweise die Domain und die Client-ID), die wir benötigen, um unsere Frontend-Applikation mit Auth0 zu verbinden (Abb. 11).

Abb. 11: Informationen unserer Applikation

Wichtig hierbei ist, dass wir konfigurieren, welche sogenannten Origins, also URLs auf unseren Tenant zugreifen dürfen. Da wir eine lokale Angular-Anwendung implementieren, müssen wir http://localhost:4200 eintragen. Darüber hinaus ist dieser URL ebenfalls noch in die Liste der Allowed Callback URLs (eine URL-Liste, in der aufgelistet wird, wohin der Identity Provider nach erfolgreicher Authentifizierung wieder navigieren soll) und in die Liste der Allowed Logout URLs (ebenfalls eine Liste der URLs, auf die der Identity Provider uns navigiert, sobald sich der Benutzer erfolgreich ausloggt) einzutragen. Nach erfolgreicher Konfiguration können wir nun damit starten, Auth0 in unserer Angular-Applikation zu integrieren.

Integration in eine Angular-Anwendung

Auth0 erleichtert die Integration erheblich durch die Bereitstellung eines SDK, das als npm-Paket [10] verfügbar ist. Dieses können wir wie folgt installieren:

> npm install @auth/auth0-angular

Nach erfolgreicher Installation nutzen wie uns zur Verfügung gestellte provideAuth0-Funktion und konfigurieren sie mit den spezifischen Details unserer Auth0-Domain und der Client-ID wie in Listing 1.

Listing 1

//main.ts

import { provideAuth0 } from '@auth0/auth0-angular';

bootstrapApplication(AppComponent, {

  providers: [
    provideAuth0({
      domain: 'YOUR_AUTH0_DOMAIN',
      clientId: 'YOUR_AUTH0_CLIENT_ID',
      authorizationParams: {
        redirect_uri: window.location.origin,
      }
    }),
  ]
});

Nun fehlen lediglich noch eine Login- und eine Logout-Komponente damit sich unsere Nutzer gegenüber unserem Identity Provider authentifizieren können. Der bereitgestellte AuthService erleichtert und die Implementierung und Verwaltung des vollständigen Authorization Code Flow mit PKCE-Erweiterung (Listing 2).

Listing 2

import { AuthService } from "@auth0/auth0-angular";




@Component({

  selector: "app-login-button",

  template: `

    <button class="button__login" (click)="handleLogin()">Log In</button>

  `
})

export class LoginButtonComponent {
  constructor(private auth: AuthService) {
  }

  handleLogin(): void {
    this.auth.loginWithRedirect({
      prompt: "login"
    });
  }
}

Beim Klick auf den Log-in-Button erfolgt eine Weiterleitung zur Log-in-Maske unseres Identity Providers (Abb. 12). Werfen wir dabei einen Blick auf den Network-Tab unseres Webbrowsers, sehen wir einen Request an den /authorize-Endpoint unseres Identity Provider (Abb. 13). Ebenfalls zu sehen sind die Properties code_challenge_method und code_challenge. Diese sind notwendig für die PKCE-Erweiterung. Die Property response_type mit dem Wert code gibt hierbei an, dass der Client unseren Identity Provider zu einem Authorization Code Flow aufruft.

Ab.12: Log-in-Maske von Auth0

Abb. 13: Payload des Requests

Wenn wir uns nun erfolgreich einloggen, können wir eine weitere Anfrage auf den /token-Endpoint unseres Identity Provider sehen. Der mitgesendete Payload sieht dieses Mal wie folgt aus:

client_id: "afRDjs6KFS0TV5NL7NzltUw9Wlktukutyk77"

code: "bigvau6q0DIA9HTbJKcXyRG09j1lZX1jTa8zLAsCIV2Wh"

code_verifier: "zBtJLPMI1TcKpLcOgHoY5ukNGmVnstxhWUksfh1Rso7"

grant_type: "authorization_code"

redirect_uri: "http://localhost:4040/callback"

Wie bereits erwähnt wird bei diesem Aufruf nun der Authorization-Code (code) mitgesendet werden, sowie der Code Verifier (code_verifier), damit unser Identity Provider überprüfen kann, ob beide Anfragen vom selben Client stammen.

Als Antwort erhalten wir das Access-Token sowie ein ID-Token, da OpenID Connect ebenfalls automatisch aktiviert ist (Abb. 14). Diese Tokens werden standardmäßig in einem Cookie abgespeichert. Wir können das SDK so konfigurieren, dass die Tokens im localStorage abgelegt werden, allerdings ist das nur in Verbindung mit einem Refresh-Token ratsam.

Abb. 14: Response mit Access-Token und ID-Token

Das Access-Token können wir nun für die Autorisierung gegenüber verschiedenen Backend-APIs verwenden. Hierfür setzen wir den Authorization-Header bei allen Anfragen auf das entsprechende API. Das kann uns auch von einem von Auth0 bereitgestellten Angular Inteceptor abgenommen werden (Listing 3).

Listing 3

//main.ts

import { provideAuth0, authHttpInterceptorFn } from '@auth0/auth0-angular';

bootstrapApplication(AppComponent, {

  providers: [

    provideAuth0(...),

    provideHttpClient(

      withInterceptors([authHttpInterceptorFn])

    )

  ]

});

Senden wir nun also eine Anfrage an ein geschütztes API, wird automatisch der Authorization-Header mit dem Wert des Access-Tokens gesetzt. Um die Anwendung vollständig abzurunden, fügen wir noch eine Logout-Komponente hinzu, die erneut den AuthService injiziert der uns eine Log-out-Funktion anbietet (Listing 4).

Abb. 15: Access-Token im Header

Listing 4

import { Component, Inject } from "@angular/core";
import { AuthService } from "@auth0/auth0-angular";
import { DOCUMENT } from "@angular/common";

@Component({
  selector: "app-logout-button",
  template: `
    <button class="button__logout" (click)="handleLogout()">Log Out</button>

  `
})
export class LogoutButtonComponent {
  constructor(
    private auth: AuthService,
    @Inject(DOCUMENT) private doc: Document
  ) {
  }


  handleLogout(): void {

    this.auth.logout({ returnTo: this.doc.location.origin });
  }
}

Dieser AuthService bietet uns noch viele weitere Observables an, z. B. isAuthenticated$, um herauszufinden, ob der Benutzer bereits eingeloggt ist oder nicht. Möchten wir hingegen Daten des Benutzers erhalten, wie beispielsweise den Usernamen, einen URL auf ein Profilbild oder die E-Mail-Adresse, so erhalten wir diese Daten, wenn wir uns auf das user$-Observable des AuthServices abonnieren.

Wie wir gesehen haben, gestaltet sich die Integration eines Identity Provider in eine Angular-Applikation recht einfach. Selbst bei anderen SPA-Frameworks wie React oder Vue.js bietet Auth0 entsprechende SDKs an, um auch dort die Integration mit so wenig Aufwand wie möglich zu gestalten. Wenn Sie nicht Auth0 nutzen möchten, bietet Microsoft eigene SDKs [11] zur Integration von Azure Active Directory. Darüber hinaus gibt es auch vielerlei etablierte Open-Source-SDKs [12] für die Integration verschiedener Identity Provider in eine Angular-Anwendung.

Die Absicherung Ihrer Backend-Ressourcen durch Autorisierung ist ein absolutes Muss einer jeden modernen Webanwendung. Der richtige Umgang mit dem Access-Token bietet vielerlei Fallstricke, wie beispielsweise die Auswahl eines schwachen kryptographischen Verfahrens zur Verschlüsselung ihrer Access-Tokens. Nicht signierte Tokens können leicht manipuliert werden, sodass ein Nutzer sich mehr Rechte zuweisen kann, als er eigentlich hat. Mehr als die Hälfte der Top 10 API Security Risks [13], die von der OWASP-Organisation veröffentlicht werden, handeln von fehlerhafter oder falsch implementierter Autorisierung. Es ist also definitiv ratsam, sich nicht selbst an der Implementierung einer Authentifizierungs- und Autorisierungslösung zu versuchen und auf bestehende Lösungen zu setzen, wie sie von Identity Providern zur Verfügung gestellt werden.

Abschließend lässt sich festhalten, dass die Integration von Authentifizierung und Autorisierung in Angular-Anwendungen eine entscheidende Rolle bei der Gewährleistung von Sicherheit und Benutzerfreundlichkeit spielt. Durch die sorgfältige Implementierung von AuthN und AuthZ können Entwickler robuste und sichere Webanwendungen erstellen, die nicht nur den Schutz sensibler Daten ermöglichen, sondern auch ein nahtloses und effizientes Nutzererlebnis bieten. Die in diesem Artikel vorgestellten Methoden und Best Practices bieten dabei einen umfassenden Leitfaden, um diese komplexen Prozesse erfolgreich in Angular-basierten Projekten umzusetzen. Mit dem wachsenden Fokus auf Websicherheit und Datenschutz ist es für Entwickler unerlässlich, sich kontinuierlich weiterzubilden und die neuesten Technologien und Methoden in diesem dynamischen Bereich zu adaptieren.

Links & Literatur

[1] https://it-service.network/it-lexikon/cia-triade
[2] Google Authenticator: https://de.wikipedia.org/wiki/Google_Authenticator
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#security
[4] https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
[5] https://www.microsoft.com/de-de/security/business/identity-access/microsoft-entra-id
[6] https://auth0.com/de
[7] https://www.keycloak.org
[8] https://oauth.net/2.1/
[9] https://auth0.com/pricing
[10] https://www.npmjs.com/package/@auth0/auth0-angular
[11] https://learn.microsoft.com/en-us/entra/identity-platform/msal-overview
[12] https://github.com/manfredsteyer/angular-oauth2-oidc und https://github.com/damienbod/angular-auth-oidc-client
[13] https://owasp.org/API-Security/editions/2023/en/0x11-t10/

The post Authentifizierung und Autorisierung – Sicherheit in einer Angular-Anwendung appeared first on BASTA!.

Angular 17 wird im Herbst 2023 weitere Beiträge zur Angular Renaissance leisten: Es kommt mit einer neuen Syntax für den Control Flow, verzögertes Laden von Seitenteilen und einer besseren Unterstützung für SSR. Außerdem setzt das CLI nun auf esbuild und beschleunigt damit den Build erheblich. In diesem Artikel gehe ich anhand einer Beispielanwendung (Abb. 1) auf diese Neuerungen ein. Den verwendeten Quellcode findet man unter [1].

Abb. 1: Beispielanwendung

Neue Syntax für Control Flow in Templates

Seit seinen ersten Tagen hat Angular strukturelle Direktiven wie *ngIf oder *ngFor für den Control Flow verwendet. Da es den Control Flow nun für die mit Angular 16 eingeführten Signals ohnehin umfangreich zu überarbeiten gilt, hat sich das Angular-Team entschieden, ihn gleich auf neue Beine zu stellen. Das Ergebnis ist der neue Build-in Control Flow, der sich deutlich vom gerenderten Markup abhebt (Listing 1).

Listing 1

@for (product of products(); track product.id) {
  <div class="card">
    <h2 class="card-title">{{product.productName}}</h2>
    […]
  </div>
}
@empty {
  <p class="text-lg">No Products found!</p>
}

Beachtenswert ist hier unter anderem der neue @empty-Block, den Angular rendert, wenn die zu iterierende Auflistung leer ist.

Auch wenn Signals ein Treiber für diese neue Syntax waren, sind sie keine Voraussetzung für ihre Nutzung. Die neuen Control-Flow-Blöcke lassen sich genauso mit klassischen Variablen oder auch mit Observables im Zusammenspiel mit der async Pipe nutzen.

Der verpflichtende track-Ausdruck erlaubt es Angular, einzelne Elemente, die innerhalb der iterierten Auflistung verschoben wurden, zu identifizieren. Damit lässt sich der Aufwand für das Rendering drastisch reduzieren und bestehende DOM-Knoten wiederverwenden. Beim Iterieren von Auflistungen primitiver Typen, z. B. number oder string, sollte track Angaben des Angular-Teams zur Folge mit der Pseudovariable $index verwendet werden (Listing 2).

Listing 2

@for (group of groups(); track $index) {
  <a (click)="groupSelected(group)">{{group}}</a>
  @if (!$last) {
    <span class="mr-5 ml-5">|</span>
  }
}

Neben $index stehen auch die anderen von *ngFor bekannten Werte über Pseudovariablen zur Verfügung: $count, $first, $last, $even, $odd. Bei Bedarf lassen sich deren Werte über Ausdrücke in Templatevariablen ablegen (Listing 3).

Listing 3

@for (group of groups(); track $index; let isLast = $last) {
  <a (click)="groupSelected(group)">{{group}}</a>
  @if (!isLast) {
    <span class="mr-5 ml-5">|</span>
  }
}

Das neue @if vereinfacht das Formulieren von else-/else-if-Zweigen (Listing 4).

Listing 4

@if (product().discountedPrice && product().discountMinCount) {
  [...]
}
@else if (product().discountedPrice && !product().discountMinCount) {
  [...]
}
@else {
  [...]
}

Daneben lassen sich verschiedene Fälle auch mit einem @switch unterscheiden (Listing 5).

Listing 5

@switch (mode) {
  @case ('full') {
    [...]
  }
  @case ('small') {
    [...]
  }
  @default {
    [...]
  }
}

Im Gegensatz zu ngSwitch und *ngSwitchCase ist die neue Syntax typsicher. Im betrachteten Beispiel müssen die einzelnen @case-Blöcke Stringwerte aufweisen, zumal die an @switch übergebene Variable mode auch vom Typ string ist.

Die neue Control-Flow-Syntax verringert die Notwendigkeit für den Einsatz struktureller Direktiven, die zwar mächtig, aber teilweise auch unnötig komplex sind. Trotzdem wird das Framework strukturelle Direktiven weiterhin unterstützen. Zum einen gibt es einige valide Anwendungsfälle dafür und zum anderen gilt es trotz der vielen aufregenden Neuerungen das Framework abwärtskompatibel zu gestalten.

Automatische Migration zum Build-in Control Flow

Wer seinen Programmcode automatisiert auf die neue Control-Flow-Syntax migrieren möchte, findet nun im Paket @angular/core ein Schematic dafür:

ng g @angular/core:control-flow

Verzögertes Laden von Seitenteilen

Typischerweise sind nicht alle Bereiche einer Seite gleich wichtig. Bei der Detailansicht eines Produkts geht es zunächst um das Produkt selbst. Vorschläge für ähnliche Produkte sind zweitrangig. Das ändert sich jedoch schlagartig, sobald Benutzer:innen die Produktvorschläge in den sichtbaren Bereich des Browserfensters, den sogenannten View Port, scrollen.

Bei besonders performancekritischen Webanwendungen wie Webshops bietet es sich an, solche zunächst weniger wichtigen Seitenteile verzögert zu laden. Das führt dazu, dass die wirklich wichtigen Elemente rascher verfügbar sind. Wer diese Idee bisher in Angular umsetzen wollte, musste sich manuell darum kümmern. Angular 17 vereinfacht auch diese Aufgabe drastisch mit dem neuen @defer-Block (Listing 6).

Listing 6

@defer (on viewport) {
  <app-recommentations [productGroup]="product().productGroup"></app-recommentations>
}
@placeholder {
  <app-ghost-products></app-ghost-products>
}

Der Einsatz von @defer zögert das Laden der angegebenen Komponente (eigentlich: das Laden des angegebenen Seitenbereichs) hinaus, bis ein bestimmtes Ereignis eintritt. Als Ersatz präsentiert es den unter @placeholder angegebenen Platzhalter. In der hier verwendeten Demoanwendung werden auf diese Weise zunächst Ghost Elements für die Produktvorschläge präsentiert (Abb. 2).

Abb. 2: Ghost Elements als Platzhalter

Nach dem Laden tauscht @defer die Ghost Elements gegen die tatsächlichen Vorschläge (Abb. 3) aus.

Abb. 3: @defer tauscht den Platzhalter gegen die verzögert geladene Komponente

Im betrachteten Beispiel kommt das Ereignis on viewport zum Einsatz. Es tritt ein, sobald der Platzhalter in den sichtbaren Bereich des Browserfensters gescrollt wurde. Weitere unterstützte Ereignisse finden sich in Tabelle 1.

Tabelle 1: Trigger für @defer

Die Trigger on viewport, on interaction und on hover erzwingen standardmäßig die Angabe eines @placeholder-Blocks. Alternativ dazu können sie sich auch auf andere Seitenteile beziehen, die über eine Templatevariable zu referenzieren sind:

<h1 #recommentations>Recommentations</h1>
@defer (on viewport(recommentations)) { <app-recommentations [...] />}

Außerdem kann @defer angewiesen werden, das Bundle zu einem früheren Zeitpunkt vorzuladen. Wie beim Preloading von Routen stellt diese Vorgehensweise sicher, dass die Bundles augenblicklich verfügbar sind, sobald man sie benötigt:

@defer(on viewport; prefetch on immediate) { [...] }

Neben @placeholder bietet @defer auch noch zwei weitere Blöcke: @loading und @error. Ersteren zeigt Angular an, während es das Bundle lädt, letzteren im Fehlerfall. Um ein Flackern zu vermeiden, lassen sich @placeholder sowie @loading mit einer Mindestanzeigendauer konfigurieren. Die Eigenschaft minimum legt den gewünschten Wert fest:

@defer ( [...] ) { [...] }
@loading (after 150ms; minimum 150ms) { [...] }
@placeholder (minimum 150ms) { [...] }

Die Eigenschaft after gibt zusätzlich an, dass der Loading Indicator nur einzublenden ist, wenn das Laden länger als 150 ms dauert.

Build-Performance mit esbuild

Ursprünglich nutzte das Angular CLI webpack für das Bauen von Bundles. Allerdings ist webpack ein wenig in die Jahre gekommen und wird derzeit von jüngeren Werkzeugen, die einfacher zu nutzen und auch um einiges schneller sind, herausgefordert. Bei esbuild [2] handelt es sich um eines dieser Werkzeuge, das mit über 20 000 Downloads pro Woche auch eine beachtenswerte Verbreitung aufweist.

Bereits seit einigen Releases arbeitet das CLI-Team an einer esbuild-Integration. In Angular 16 war diese Integration bereits im Stadium einer Developer Preview enthalten. Ab Angular 17 ist die Implementierung stabil und kommt über den weiter unten beschriebenen Application Builder für neue Angular-Projekte standardmäßig zum Einsatz.

Bei bestehenden Projekten lohnt es sich, eine Umstellung auf esbuild zu prüfen. Dazu ist in der angular.json der Eintrag builder zu aktualisieren:

"builder": "@angular-devkit/build-angular:browser-esbuild"

Anders ausgedrückt: Am Ende ist -esbuild zu ergänzen. In den meisten Fällen sollte sich daraufhin ng serve und ng build wie gewohnt verhalten, jedoch um einiges schneller sein. Ersteres nutzt zur Beschleunigung den Vite dev-server [3], um npm-Pakete erst bei Bedarf zu bauen. Daneben hat das CLI-Team noch weitere Performanceoptimierungen vorgesehen.

Der Aufruf von ng build konnte durch den Einsatz von esbuild auch drastisch beschleunigt werden. Faktor 2 bis 4 wird häufig als Bandbreite genannt.

SSR ohne Aufwand mit dem neuen Application Builder

Auch die Unterstützung für Server-side Rendering (SSR) wurde mit Angular 17 drastisch vereinfacht. Beim Generieren eines neuen Projekts mit ng new steht nun ein Schalter –ssr zur Verfügung. Kommt dieser nicht zum Einsatz, fragt die CLI, ob sie SSR einrichten soll (Abb. 4).

Abb. 4: ng new richtet auf Wunsch SSR ein

Um SSR später zu aktivieren, muss lediglich das Paket @angular/ssr hinzugefügt werden:

ng add @angular/ssr

Wie der Scope @angular verdeutlicht, stammt dieses Paket direkt vom Angular-Team. Es handelt sich dabei um den Nachfolger des Communityprojekts Angular Universal. Um SSR im Zuge von ng build und ng serve direkt zu berücksichtigen, hat das CLI-Team einen neuen Builder bereitgestellt. Dieser sogenannte Application Builder nutzt die oben erwähnte esbuild-Integration und erzeugt damit Bundles, die sowohl im Browser als auch serverseitig nutzen lassen.

Ein Aufruf von ng serve startet auch einen Development-Server, der sowohl serverseitig rendert als auch die Bundles für den Betrieb im Browser ausliefert. Ein Aufruf von ng build –ssr kümmert sich auch um Bundles für beide Welten sowie um das Bauen eines einfachen Node.js-basierten Servers, dessen Quellcode die oben erwähnten Schematics genieren.

Wer keinen Node.js-Server betreiben kann oder möchte, kann mit ng build –prerender die einzelnen Routen der Anwendung bereits beim Build vorrendern.

Weitere Neuerungen

Neben den bis hier diskutierten Neuerungen bringt Angular 17 noch zahlreiche weitere Abrundungen:

• Der Router unterstützt nun das View Transitions API [4]. Dieses von einigen Browsern angebotene API erlaubt das Animieren von Übergängen, z. B. von einer Route auf eine andere mittels CSS-Animationen. Dieses optionale Feature ist beim Einrichten des Routers über die Funktion withViewTransitions zu aktivieren. Zur Demonstration nutzt das Beispiel unter [1] CSS-Animationen, die vom View Transitions API übernommen wurden.
• Die in Version 16 als Developer Preview eingeführten Signals sind nun stabil. Eine wichtige Änderung gegenüber Version 16 ist, dass Signals nun standardmäßig auf die Nutzung mit Immutables ausgelegt sind. Somit kann Angular einfacher herausfinden, an welcher Stelle die über Signals verwalteten Datenstrukturen geändert wurden. Zum Aktualisieren von Signals lässt sich die Methode set, die einen neuen Wert zuweist, oder die Methode update, die den bestehenden Wert auf einen neuen abbildet, einsetzen. Die Methode mutate wurde entfernt, zumal sie nicht zur Semantik von Immutables passt.
• Es existiert nun ein Diagnostic, der eine Warnung ausgibt, wenn beim Lesen von Signals in Templates der Aufruf des Getters vergessen wurde (z. B. {{ products }} anstatt {{ products() }}).
• Animationen können nun lazy geladen werden [5].
• Das Angular CLI generiert standardmäßig Standalone Components, Standalone Directives und Standalone Pipes. Auch ng new sieht standardmäßig das Bootstrapping einer Standalone Component vor. Dieses Verhalten lässt sich mit dem Schalter –standalone false
• Die Anweisung ng g interceptor generiert funktionale Interceptors.

Zusammenfassung

Mit Version 17 schreitet die Angular Renaissance voran. Die neue Syntax für den Control Flow vereinfacht den Aufbau von Templates. Dank Deferred Loading können weniger wichtige Seitenbereiche zu einem späteren Zeitpunkt nachgeladen werden. Damit lässt sich der initiale Page-Load beschleunigen. Durch den Einsatz von esbuild laufen die Anweisungen ng build und ng serve merkbar schneller. Außerdem unterstützt das CLI nun direkt SSR und Prerendering.

Links & Literatur

[1] https://github.com/manfredsteyer/hero-shop.git

[2] https://esbuild.github.io

[3] https://vitejs.dev

[4] https://developer.chrome.com/docs/web-platform/view-transitions/

[5] https://riegler.fr/blog/2023-10-04-animations-

The post Was ist neu in Angular 17? appeared first on BASTA!.

Strategisches Domain-Driven Design

Der strategische Teil des Domain-Driven Designs beinhaltet die Dekomposition der Businessdomäne in Subdomänen und Bounded Contexts. Mit Hilfe einer Context Map werden die Abhängigkeiten zwischen den Bounded Contexts visualisiert. Dabei werden die Abhängigkeiten mittels Context-Mapping-Patterns beschrieben. Letztere stellen eine Mustersprache dar, um Abhängigkeiten auf technischer, fachlicher und organisatorischer Ebene zu gestalten. Auf diese Weise wird eine soziotechnische Architektur der Businessdomäne definiert, die nicht nur den fachlichen Systemschnitt, sondern auch die Entwicklungsteams hinter den Bounded Contexts berücksichtigt [2].

Das Ziel des Domain-Driven Architect besteht darin, Bounded Context auf der strategischen Architekturebene sinnvoll und in den meisten Fällen möglichst unabhängig von anderen Bounded Contexts zu gestalten. Eine optimale Lösung ist nicht immer möglich. Die Transparenz hinsichtlich der Abhängigkeiten sowie deren methodische Betrachtung sind jedoch sehr nützlich. Es geht darum, die Vor- und Nachteile sorgfältig abzuwägen und bewusste Entscheidungen zu treffen. Die bewusste Gestaltung von Abhängigkeiten ist dabei nicht nur zu Beginn eines Projekts wichtig. Zu diesem Zeitpunkt ist oft das Wissen unvollständig und Weiterentwicklungen sind nicht vorhersehbar. Daher ist eine regelmäßige Überprüfung und Anpassung sinnvoll. In der Praxis wird dies aber selten durchgeführt.

Eine Untersuchung der Abhängigkeiten ist besonders dann relevant, wenn das System oder das Projekt aus dem Gleichgewicht gerät. Dies geschieht in der Regel aufgrund verschiedener Arten von Wachstum. Zwei Szenarien, die Anlass geben, die Abhängigkeiten in der strategischen Architektur neu zu überdenken, sind das Wachstum des Systems und das Wachstum des Geschäftsmodells [3] (siehe Kasten: „Wachstum und Folgen“).

Wachstum und Folgen

Wachstum des Systems

Das System wächst rasant und die Abhängigkeiten zwischen den internen Komponenten des Systems bauen sich stetig weiter auf. Zusätzlich werden immer mehr externe Systeme angebunden. Die Komplexität der Integration verknüpft sich mit der Herausforderung, unterschiedliche Domänen- und Kommunikationsmodelle zu handhaben. Wenn sich diese Modelle ändern, führt das zu Seiteneffekten und erfordert Anpassungen im System. Das System ist aufgrund der entstandenen Komplexität nur schwer erweiterbar.

Wachstum des Geschäftsmodells

Geschäftsmodelle und Organisationen wachsen, was über die Zeit Anpassungen in der IT-Architektur bedingt. Das ist besonders dann der Fall, wenn das Geschäftsmodell auf einem monolithischen System gewachsen ist. Die Skalierung von Teams bedeutet nun eine Zerlegung des Systems in Subsysteme zur Aufteilung auf mehrere Teams. Dadurch entstehen neue Abhängigkeiten und bereits bekannte Abhängigkeiten zu externen Systemen müssen neu gedacht werden.

SIE LIEBEN AGILE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Businessdomäne, Bounded Context und Domänenmodell

Eine Businessdomäne ist der Bereich, in dem ein Unternehmen aktiv ist, am Markt teilnimmt und Kunden Produkte oder Dienstleistungen anbietet. Bounded Contexts sind das Mittel zur Zerlegung dieser Domäne in fachlich unabhängige Module der strategischen Architekturebene (Abb. 1). Ein Bounded Context ist ein fachlich abgrenzbarer Bereich, der gleichzeitig eine physische Grenze zu anderen Bounded Contexts darstellt. Er liegt in der Verantwortlichkeit eines Teams und wird unabhängig von anderen Bounded Contexts versioniert, weiterentwickelt und in Produktion gebracht.

Das Besondere an Domain-Driven Design und am Bounded Context ist, dass das Domänenmodell im Mittelpunkt steht. Durch dieses Modell werden Eigenschaften, Ereignisse und Funktionen der Businessdomäne zum Ausdruck gebracht. Als allgegenwärtige Sprache (Ubiquitous Language) dient das Domänenmodell als Bindeglied zwischen allen Projektphasen (Discover, Plan, Do, Check, Adjust), Architekturebenen (strategische, soziotechnische und taktische Architektur) sowie den beteiligten Personen (Architekt:in, Entwickler:in, Product Owner, Agile Coach, Tester:in, UX-Designer:in etc.).

Neben den bereits erwähnten Eigenschaften eines Bounded Context ist der entscheidende Punkt, dass er einen abgegrenzten Bereich (Bounded) um die Bedeutung eines fachlichen Modells (Context) darstellt. Domain-Driven Design formuliert die Heuristik, dass jeder Bounded Context sein eigenes Domänenmodell spezifisch und fachlich eindeutig realisieren sollte. Das Domänenmodell existiert folglich nur in diesem Bounded Context und hat dort Gültigkeit [2], [4]. Fowler [5] erklärt das anhand der Domänenobjekte „Kunde“ und „Produkt“ mittels der unterschiedlichen Perspektiven der Vertriebs- und Supporteinheiten auf diese Geschäftsobjekte. Fachliche Abhängigkeiten existieren in der Realität selbstverständlich trotzdem und müssen als Abhängigkeiten zwischen Bounded Contexts berücksichtigt werden. Das geschieht im Context Mapping.

Abb. 1: Dekomposition einer Businessdomäne in Subdomänen und Bounded Contexts

Abhängigkeiten zwischen Bounded Contexts gestalten

Wenn zwei Systeme miteinander kommunizieren müssen, ist die resultierende technische Abhängigkeit offensichtlich. Es gibt einen Konsumenten, der auf eine vom Provider angebotene Funktionalität zugreift. Auf der technischen Architekturebene kann sich diese Abhängigkeit vereinfacht wie folgt darstellen (Abb. 2):

1. Der Provider stellt eine Schnittstelle zur Verfügung, die von Konsumenten über eine Netzwerkschnittstelle (z. B. HTTP) oder als Bibliothek (z. B. JAR) genutzt werden kann.
2. Der Provider veröffentlicht über einen Broker ein Event. Darauf abonnierte Konsumenten empfangen dieses Event durch den Broker und können es weiterverarbeiten.

Abb. 2: Provider-Konsument-Beziehung zwischen Systemen

Oft wird die daraus resultierende fachliche Abhängigkeit zwischen den Systemen weniger bewusst betrachtet. Provider exponieren ihr Domänenmodell oder einen Teil davon über ihr API oder über Events nach außen. Ändert sich die Fachlichkeit des Providers, ändert sich auch sein Modell und in der Folge das exponierte Modell für die Konsumenten. Für sie stellt sich die Frage, inwieweit das externe Domänenmodell übernommen und in die eigene Domäne integriert werden sollte. Haben die Konsumenten das Ziel, schnell und mit minimalem Aufwand auf Veränderungen des Providers zu reagieren, müssen passende architektonische Lösungsstrategien angewendet werden. Ist das nicht nötig, beispielsweise aufgrund weniger hoher Anforderungen an die Reaktions- und Anpassungszeit oder wenn die Auswirkungen von Veränderungen beim Provider trotz tiefer Integration minimal sind, können einfachere Ansätze genutzt werden.

Im Context Mapping findet sich die fachliche Abhängigkeit als Model Flow wieder. In Abgrenzung dazu wird die technische Abhängigkeit als Call Flow bezeichnet. Der Influence Flow berücksichtigt, dass hinter Bounded Contexts potenziell unterschiedliche Entwicklungsteams stehen (Abb. 3).

Abb. 3: Darstellung des Model Flow, Call Flow und Influence Flow der Methode Context Mapping

Ist das der Fall, ergibt sich aus der technischen und fachlichen Abhängigkeit auch eine organisatorische Abhängigkeit zwischen diesen Teams. Domain-Driven Design untersucht dabei, wie stark diese Teams ihren gegenseitigen Erfolg beeinflussen. Je stärker die Abhängigkeit ist, desto größer ist der Einfluss [2], [6]. Auf organisatorischer Ebene spiegeln sich Abhängigkeiten mit negativer Tendenz wie folgt wider:

• Notwendigkeit einer abgestimmten oder gemeinschaftlichen Planung der fachlichen Roadmap mit regelmäßigen Zielkonflikten in der Priorisierung
• erschwerte, mehrdeutige und widersprüchliche Definition der Fachlichkeit
• Drang, Änderungen in den eigenen Systemen vorzunehmen, aufgrund nicht abgestimmter Änderungen beim Provider
• Drang, Features zu priorisieren, die vorwiegend auf die Ziele eines Konsumenten einzahlen

Bei der Betrachtung der Abhängigkeit zwischen zwei Bounded Contexts werden diese als Upstream- oder Downstream-Kontexte kategorisiert. Damit wird ausgedrückt, welcher Bounded Context weniger abhängig (Upstream) oder stärker abhängig (Downstream) vom anderen ist. Stehen Bounded Contexts in einer Upstream-Downstream-Beziehung, beeinflussen sie ihren Erfolg. Mit Hilfe von Context-Mapping-Patterns wird detaillierter ausgestaltet, wie stark sich die Abhängigkeit und die Beeinflussung des Erfolgs in der Architektur und in der Organisation manifestieren [2]. Ein Team hat Erfolg, wenn es Sprintziele und Termine mit der geforderten Funktionalität einhalten kann. Fehlerfreiheit in der Implementierung, Code- und Architekturqualität drücken ebenfalls den Erfolg eines Entwicklungsteam aus. Die fachliche Trennung mittels Bounded Contexts und die Beziehungsgestaltung mittels Context-Mapping-Patterns haben das Ziel, eine gute Basis für den Erfolg zu schaffen.

Die DDD Crew [6] beschreibt neun Context-Mapping-Patterns. An dieser Stelle werden drei Muster näher erläutert. Unterstützend ist dieser Sachverhalt in Abbildung 4 visualisiert.

Bietet ein Provider eine Schnittstelle mit exponiertem Domänenmodell an, ohne dass es durch Konsumenten beeinflusst werden kann, handelt es sich um einen Open Host Service. Ein Open Host Service kann von vielen Bounded Contexts in gleicher Weise genutzt werden.

Abb. 4: Darstellung des Zusammenwirkens der Context-Mapping-Patterns Open Host Service, Conformist und Anticorruption Layer

Wenn ein konsumierender Bounded Context das Domänenmodell akzeptiert und tief integriert, entsteht eine starke fachliche Abhängigkeit. Der Bounded Context wird dann als Conformist bezeichnet. Andererseits, wenn das exponierte Domänenmodell an der Grenze des konsumierenden Bounded Context transformiert wird, wird die Abhängigkeit auf einen Punkt, die transformierende Schicht, verlagert. Das wird durch das Muster Anticorruption Layer ausgedrückt. Ein Anticorruption Layer reduziert die Kopplung und befähigt den Konsumenten, schnell auf Veränderungen beim Provider zu reagieren. Der Open Host Service ist immer ein Upstream-Kontext, während der Conformist und der Anticorruption Layer Downstream-Kontexte darstellen [2], [6].

Die ganzheitliche Erstellung einer Context Map für eine Businessdomäne erfordert ein tiefes Verständnis aller Muster und eine intensive, analytische Auseinandersetzung mit den direkten und indirekten Beziehungsgeflechten zwischen allen Bounded Contexts. Das ist sicherlich eine Aufgabe, die Affinität und Expertise seitens der Ersteller:innen voraussetzt.

Gamification als Enabler für Context Mapping

Die Kernidee von Gamification besteht darin, Prinzipien und Elemente aus Spielen in andere Kontexte zu integrieren, um Motivation, Kreativität, Engagement und Interaktion von Menschen zu steigern. Ein Erfolgsfaktor ist die intrinsische Motivation sowie der natürliche Spieltrieb von Menschen, gewünschte Verhaltensweisen auszuführen, Aufgaben zu erledigen oder Ziele zu erreichen [7], [8]. Mit Fokus auf Domain-Driven Design Cards werden Spieler:innen als Team mit Herausforderungen konfrontiert, die sie gemeinsam meistern müssen. Dies geschieht in Form von Missionen, die im Spielverlauf abgeschlossen werden müssen. Gamification-Ansätze wie Domain-Driven Design Cards erfreuen sich in verschiedenen Bereichen der Organisations- und Softwareentwicklung großer Beliebtheit. So haben Domain-Driven Design Cards Inspiration in Backlog Refinement Cards [9], unFix Cards [10] oder Cards 42 [11] gefunden.

Ein weiterer wichtiger Aspekt von Domain-Driven Design Cards ist das Ziel, alle Mitglieder der Gruppe gleichwertig zu involvieren, unabhängig von ihrem Wissensstand und Charaktertyp. Das trägt zu den Zielen der Domain-Driven-Design-Philosophie bei, die eine Kultur des breiten gemeinsamen Verständnisses und der Zusammenarbeit anstrebt. Das Context Mapping Game der Domain-Driven Design Cards dient als Enabler für die soziotechnische Architektur mittels Context Mapping. Das Context Mapping Game basiert auf der Annahme, dass in der Realität selten eine Gruppe existiert, die durchgehend über tiefes Wissen im Bereich Domain-Driven Design oder in der Methode des Context Mapping verfügt. Daher ist die Zielsetzung des Context Mapping Game, dass es auch ohne diese Expertise spielbar ist.

Eine kurze Einführung im Vorfeld ist empfehlenswert, insbesondere wenn diese Methode für die Teilnehmer:innen völlig neu ist. Die Teilnahme am Spiel erfordert lediglich ein Grundverständnis der Idee von Context Mapping. Das Spiel ermöglicht die Zusammenarbeit zwischen Entwickler:innen, Architekt:innen, Product Ownern, Fachexpert:innen und Produktmanager:innen, da das Wissen über Abhängigkeiten in einer komplexen Businessdomäne auf viele Köpfe verteilt ist und für alle in gleicher Qualität transparent gemacht werden muss. Die Teilnehmer:innen werden sowohl durch die Spielkarten als auch durch eine:n Moderator:in unterstützt, die Fragen zur Methode des Context Mapping und zum Spiel beantworten kann. Die Durchführung des Spiels bedingt also mindestens eine Person mit Expertise in Domain-Driven Design und Context Mapping. Das Spiel bietet Raum für Kommunikation, Wissensaustausch, Aufbau von Methodenverständnis sowie für die gemeinschaftliche Definition von Abhängigkeiten der Bounded Contexts im eigenen Projektkontext. Bei regelmäßiger Anwendung wird dieses Verständnis gefestigt und inkrementell aufgebaut.

Spielanleitung des Context Mapping Game

Im Folgenden soll eine kurze Anleitung zum Context Mapping Game gegeben werden.

Ziel des Spiels

Das Ziel des Context Mapping Game ist es, als Team Abhängigkeiten zwischen Bounded Contexts zu ermitteln. Die Analyse eines Bounded Context in Bezug auf seine Abhängigkeiten stellt die Mission des Teams dar. Die Mission gilt als erfüllt, wenn Einigkeit hinsichtlich der Vollständigkeit der ermittelten und definierten Abhängigkeiten besteht und diese widerspruchsfrei als Context-Mapping-Pattern abgebildet sind. Die Abbildung erfolgt mit Hilfe der Spielkarten. In der Regel besteht ein Context Mapping Game aus mehreren Missionen, da komplexe Businessdomänen oft zahlreiche Abhängigkeiten aufweisen. Sobald alle Missionen abgeschlossen sind, endet das Spiel.

Spielvorbereitung

Die Vorbedingung für das Spielen des Context Mapping Game ist mindestens eine definierte Mission. Das bedeutet, dass mindestens eine Vision für einen Bounded Context existiert. Diese Vision umfasst Zweck, Verantwortlichkeiten und Existenzbegründung für den Bounded Context sowie die wichtigsten Geschäftsereignisse, Kommandos, Domänenobjekte und Geschäftsregeln. Die Beschreibung des Bounded Context mit den genannten Inhalten bildet das Spielfeld, auf dem die Karten abgelegt werden.

Eine empfehlenswerte Grundlage für das Spielfeld ist das Bounded Context Canvas der DDD Crew (Abb. 5). Ein Canvas ist ein visuelles Werkzeug, um komplexe Konzepte oder Probleme auf übersichtliche und strukturierte Weise darzustellen. Es bietet in der Regel klare Strukturen, die den Beteiligten dabei helfen, Informationen zu organisieren, Ideen zu generieren und Entscheidungen zu treffen. Das Bounded Context Canvas ist ein Instrument, um kollaborativ einen Bounded Context zu definieren und die wichtigsten fachlichen Designentscheidungen visuell zu dokumentieren [12].

Abb. 5: Das Bounded Context Canvas der DDD Crew [12]

Spielverlauf

Besteht das Spiel aus mehreren Missionen, was bedeutet, dass im Workshop mehrere Bounded Contexts betrachtet werden, wird im ersten Schritt die Mission ausgewählt. Jede Mission wird auf der Spieloberfläche ohne gelegte Spielkarten begonnen. Alle Spieler:innen haben ein Kartendeck in ihren Händen. Die Mission beginnt mit zehn Minuten Brainstorming von Abhängigkeiten (Dependency Storming). Im Anschluss werden gleiche Nennungen geclustert und die Abhängigkeiten in ein- bzw. ausgehende Abhängigkeiten unterteilt und als Sticky Notes auf das Spielfeld gelegt. Danach wird jede Abhängigkeit in einer Timebox von zehn Minuten diskutiert. Nach diesem Austausch legen alle Spieler:innen eine oder mehrere Spielkarten für den Upstream- und Downstream-Kontext auf das Spielfeld. Wie viele Spielkarten je Spieler:in gelegt werden, hängt vom ausgewählten Context-Mapping-Pattern ab. Weitere Details sind unter [13] beschrieben.

Wenn sich eine gemeinsame Basis mit Ausreißern ergibt, kann die Entscheidungsfindung durch die Erklärung der Ausreißer gestartet werden. Wenn das Ergebnis sehr unterschiedlich oder einheitlich ist, beginnt ein:e beliebige:r Spieler:in mit der Schilderung ihrer Sicht. Bei der aufkommenden Diskussion hat der/die Moderator:in die Aufgabe, die Diskussion zu leiten, sodass alle Spielerinnen zu Wort kommen und ein Commitment im Team hinsichtlich der final ausgewählten Spielkarten, d. h. der ausgewählten Context-Mapping-Patterns, erzielt wird. Ist es schwierig, ein Commitment zu erzielen, empfiehlt sich der Einsatz von Methoden für die Entscheidungsfindung, wie z. B. Dot-Voting oder Thumb-Voting. Für Thumb-Voting kann das Context Mapping Game mit unFix Decision Patterns [10] ergänzt werden. Dot-Voting ist sowohl vor Ort mit Stift oder Klebepunkten als auch remote auf einem Collaboration Board einfach durchführbar. Der Spielablauf ist ergänzend in Abbildung 6 dargestellt.

Abb. 6: Der Spielablauf des Context Mapping Game

Karten

Abbildung 7 zeigt die Domain-Driven Design Cards des Context Mapping Game in der Übersicht. Neben dem Namen des Context-Mapping-Patterns sind die wichtigsten Eigenschaften des Musters aufgeführt. Das fördert den Aufbau von Verständnis, analytischem Denken und Kreativität bei den Spieler:innen und ermöglicht auch Unerfahrenen die Teilnahme. Die Karten sind zum Download kostenlos unter [13] verfügbar.

Abb. 7: Die Spielkarten des Context Mapping Game

Fazit und Ausblick

Ein Blick auf die Rolle der Moderator:innen im Context Mapping Game ist eine nähere Betrachtung wert. Neben der Offenheit und intrinsischen Motivation des Teams ist der/die Moderator:in ein entscheidender Erfolgsfaktor. Nach unserer Erfahrung sind die Moderator:innen oft auch die Methodenexpert:innen für Domain-Driven Design und Context Mapping. Neben der Aufgabe, Fragen zur Methodik zu beantworten, ergeben sich beim Context Mapping Wechselwirkungen und implizite Abhängigkeiten zwischen Bounded Contexts, auf die spontan reagiert werden muss. Dies deckt das Spiel nicht ab.

Ein starkes Team findet sich in der Kombination aus Agile Coach und Domain-Driven Architect. Beide Rollenbilder fördern die Zusammenarbeit und besitzen die Fähigkeit, Workshops zu moderieren und zu gestalten. Der Agile Coach findet sich weiterhin im agilen Entwicklungsprozess wieder und nutzt dort zum Beispiel Backlog Refinement Cards [9], während der Domain-Driven Architect sich intensiv mit der Überführung der strategischen in die taktische Architektur beschäftigt und dafür das Architecture Game der Domain-Driven Design Cards als methodisches Hilfsmittel einsetzt. Auf Ebene der Organisationsentwicklung finden sich Agile Coach und Domain-Driven Architect auf Basis der Context Map wieder, um die fachliche und soziotechnische Architektur nach Domain-Driven Design in einen organisatorischen Rahmen wie Team Topologies oder SAFe zu integrieren, gestützt auf die Verwendung von unFix Cards [10].

Wir erleben Gamification als echten Unterstützer kollaborativer Projektarbeit, wenn die Ansätze auf die notwendige Offenheit treffen.

Links & Literatur

[1] Horowitz, Andreessen: „Why Software Is Eating the World“: https://a16z.com/why-software-is-eating-the-world

[2] Plöd, Michael: „Hands-on Domain-driven Design – by example“; Leanpub, 2020

[3] Lilienthal, Carola; Schwentner, Henning: „Domain-Driven Transformation“; dpunkt.verlag, 2023

[4] Khononov, Vlad: „Learning Domain-Driven Design“; O’Reilly, 2021

[5] Fowler, Martin: „BoundedContext“: https://martinfowler.com/bliki/BoundedContext.html

[6] DDD Crew: „Context Mapping“: https://github.com/ddd-crew/context-mapping

[7] Aprea, Carmen; Weckmüller, Heiko: „Gamification in der Qualifizierung und darüber hinaus: Alles nur ein Spiel?“: https://www.haufe.de/personal/neues-lernen/gamification-wie-effektiv-ist-das-spielerische-lernen_589614_534032.html

[8] Hombergs, Tom; Schiller, Thorben: „Gamification als Treiber von Codequalität“: https://www.heise.de/ratgeber/Gamification-als-Treiber-von-Codequalitaet-3759236.html?seite=all

[9] Hyoma, Nils: „Backlog Refinement Cards“: https://www.dependencypoker.com/backlog-refinement-cards

[10] unFix: „unFix Cards“: https://unfix.com/cards

[11] Harrer, Markus et al.: „Cards for Analyzing and Reflecting on Doomed Software“: https://cards42.org

[12] DDD Crew: „The Bounded Context Canvas“: https://github.com/ddd-crew/bounded-context-canvas

[13] Eschhold, Matthias: „Domain-driven Design Cards“: LINK

The post Dependencies Are Eating The Business Domain appeared first on BASTA!.

• über die Previews 1 und 2 in Ausgabe 6.2023 sowie
• über die Previews 3 und 4 in Ausgabe 8.2023.

Bis Einreichung dieses Artikels sind noch Preview 5 (13. Juni 2023), Preview 6 (11. Juli 2023) und Preview 7 (8. August 2023) erschienen.

Als geplanter Erscheinungstermin für die fertige Version von .NET 8.0 wurde inzwischen der 14. November 2023 verkündet. Bis dahin wird es noch zwei weitere Vorschauversionen mit dem Titel „Release Candidate“ geben. Üblich ist, dass Microsoft mit den Release-Candidate-Versionen eine Go-live-Lizenz verbindet, das heißt ab dann ist der produktive Einsatz von .NET 8.0 erlaubt. Das heißt aber nicht, dass es in der Release-Candidate-Phase keine Änderungen mehr geben wird.

Blazor United: Ein flexibles Blazor für alle Webarchitekturen

Microsoft hatte am 24. Januar 2023 auf YouTube [1] die Integration von Blazor Server und Blazor WebAssembly zu Blazor United verkündet, sodass aus Benutzerinnen- und Benutzersicht zur Laufzeit ein nahtloser Übergang der Rendering-Arten entsteht.

Blazor United umfasst neben den bisher verfügbaren Blazor-Architekturen für den Webbrowser (Blazor Server und Blazor WebAssembly) die folgenden fünf neuen Architekturen:

1. Blazor Server-side Rendering (Blazor SSR)
2. Blazor Server-side Rendering mit Streaming (Blazor SSR mit Streaming)
3. Hosting von Blazor Server innerhalb von Blazor SSR (anstelle des bisherigen Hostings von Blazor Server in ASP.NET Core Razor Pages)
4. Hosting von Blazor WebAssembly innerhalb von Blazor SSR (anstelle des bisherigen Hostings von Blazor Server in ASP.NET Core Razor Pages)
5. Wechsel einer Komponente von Blazor Server zu Blazor WebAssembly

Spannend ist, dass bei Blazor United diese Architekturmodelle innerhalb eines einzigen Projekts mischbar sind und zwar nicht nur pro Seite, sondern pro einzelner Komponente. Das bedeutet zum Beispiel, dass man eine Webanwendung erschaffen kann, in der alle statischen Inhalte auf dem Server gerendert werden und nur die Teile, die tatsächlich Interaktivität benötigen (z. B. Eingabeformulare, Suchdialoge) dann mit Blazor Server oder Blazor WebAssembly arbeiten. So wird Blazor in Version 8.0 zu einem deutlich universelleren Ansatz für Webanwendungen. Blazor eignet damit auch für öffentliche Websites (z. B. Firmen- und Produktpräsentationen, Webshops) und nicht nur für Intra- und Extranetanwendungen.

Blazor SSR als Nachfolger für MVC und Razor Pages

Der Begriff Server-side Rendering (Blazor SSR) kann verwirren. Erste Erfahrungen in der Praxis zeigen, dass viele Entwickler:innen denken: „Das gibt es doch schon mit Blazor Server“. Aber nein, Blazor Server und Blazor SSR sind nicht das Gleiche.

Das schon seit .NET Core 3.1 verfügbare Blazor Server rendert zwar auf dem Server, es entsteht aber dennoch eine Singel Page Application (SPA). Über eine WebSockets-Verbindung werden Unterschiede des Rendering zum vorherigen Rendering (im Programmiererlatein „Diff“ oder „Change Set“ genannt) zum Client gesendet und dort per JavaScript ausgetauscht. Die Benutzer:innen bemerken daher nicht, dass es ein Server-Rendering gab. Die Seite ist genauso interaktiv wie beim Einsatz von Blazor WebAssembly oder eines JavaScript-basierten Webfrontendframeworks wie Angular, React oder VueJS.

Mit dem neuen Blazor Server-side Rendering (Blazor SSR) bietet Microsoft im Rahmen von Blazor nun auch eine rein serverseitige, aus der Clientsicht statische HTML-Erzeugung zu einer Multi Page Application (MPA). Das Rendering-Ergebnis wird bei Blazor SSR in einem Rutsch über eine normale HTTP-Verbindung zum Client gesendet und es werden immer ganze Seiten ausgetauscht (oberer Teil in Abb. 1), sodass der Benutzer ein typisches Flackern der Darstellung beim Seitenwechsel wahrnimmt. Neue HTTP-Anfragen beim Server werden nur durch Hyperlinks oder Formulareinsendungen ausgelöst. .NET- oder JavaScript-Code im Browser sind bei Blazor SSR nicht notwendig. Optional kann man aber per JavaScript Streaming ermöglichen, das Benutzer:innen schon während des Renderings Anzeigen bietet.

Blazor SSR ist schon seit .NET 8.0 Preview 3 verfügbar. Bei Blazor SSR können (mit einigen Abstrichen) die gleichen Razor Components, die bisher bei Blazor Server, Blazor WebAssembly, Blazor MAUI und Blazor Desktop eingesetzt wurden, nun für reines Server-side Rendering verwendet werden. Blazor SSR besitzt grundsätzlich die gleiche Multi-Page-Application-Architektur wie ASP.NET Core Model View Controller (MVC), das es seit .NET Core 1.0 gibt, und ASP.NET Core Razor Pages, eingeführt in .NET Core 2.0 im Jahr 2017.

Der Unterschied zu MVC und Razor Pages ist, dass bei Blazor SSR auf dem Webserver sogenannte Razor Components mit der Blazor-Variante der Razor-Template-Syntax arbeiten, anstelle von Controller plus Razor Views (bei MVC) bzw. Page Model plus Razor Pages (bei Razor Pages). Genau wie bei den älteren Modellen muss auf dem Webserver für Blazor SSR natürlich ASP.NET Core laufen.