Einführung in Aspire 9.5 - Schneller Einstieg in dieses wichtige Tool

Einstieg und Installation von Aspire 9.5

Tim beginnt damit, den Zweck von Aspire zu erläutern. Jeder .NET-Entwickler, der APIs oder Webanwendungen erstellt, sollte dieses wichtige Microsoft-Tool verstehen. Es herrscht Verwirrung darüber, was Aspire alles kann, also macht sich Tim auf den Weg, um den Zweck, die Einrichtung und die Verwendung von Grund auf zu demonstrieren.

Er öffnet Visual Studio und beginnt ein neues Projekt mit der Aspire-Starter-App-Vorlage. Wenn Sie Aspire noch nicht installiert haben, verweist er auf die Microsoft-Website für die Einrichtung und das Tooling von Aspire und weist darauf hin, dass Sie es über die .NET CLI, Visual Studio oder VS Code installieren können. Der Einfachheit halber empfiehlt Tim die Verwendung des CLI-Befehls:

dotnet neu installieren aspire.templates

Dadurch werden die neuesten Projektvorlagen, einschließlich Aspire 9.5, installiert. Nach der Installation kann ein Neustart von Visual Studio erforderlich sein, damit die Vorlagen angezeigt werden.

Tim wählt die Aspire Demo App, wählt .NET 9, aktiviert HTTPS und verwendet die Redis-Integration für das Caching. Dies ist ein Beispiel für ein reales Szenario, bei dem Aspire eine gesamte Anwendung lokal verwaltet. Er überspringt die Unit-Tests und fährt mit der Erstellung der Lösungsdateien fort.

Erforschung der Projektstruktur und des App-Modells

Sobald das Projekt generiert ist, zerlegt Tim die Projektdateien, die mit dem App-Modell von Aspire erstellt wurden. Die Lösung umfasst vier Hauptprojekte, die sowohl typische .NET-Projekte als auch Aspire-spezifische Projekte widerspiegeln:

1. Webprojekt - eine Blazor-basierte Webanwendung.

2. API-Dienst - ein Backend-Dienst für Daten oder Geschäftslogik.

3. AppHost - die einzelne Datei AppHost, mit der die gesamte Anwendung gestartet wird.

4. ServiceDefaults - eine Bibliothek, die Gesundheitsprüfungen, Service-Erkennung und Telemetrie-Einstellungen enthält.

Die ersten beiden stehen für ein normales verteiltes System (Frontend und Backend), während die anderen beiden die einheitliche Toolchain von Aspire für die Verwaltung von Umgebungsvariablen, Abhängigkeiten und APIs für Ressourcenlebenszyklusereignisse darstellen.

Tim hebt hervor, wie dieses neue App-Modell erstklassige Unterstützung für die Orchestrierung mehrerer Projekte bietet und es Entwicklern ermöglicht, ihre gesamte App mit einem einzigen Befehl auszuführen. Der AppHost steuert die Startreihenfolge und die Abhängigkeiten, während ServiceDefaults automatisch Konfigurationsvorgaben, Zustandsprüfungen und Telemetrieintegration einfügt.

Warum Aspire die lokale Entwicklung vereinfacht

Tim erklärt die Probleme bei der lokalen Verwaltung eines verteilten Systems ohne Aspire. Traditionell müssen Entwickler Container-Laufzeitkonfigurationen, Portweiterleitungen und Verbindungsstrings für jeden Dienst manuell konfigurieren. Jeder Entwickler muss Umgebungsvariablen, Benutzergeheimnisse und Redis- oder API-Verbindungen individuell replizieren.

Bei Aspire übernimmt die Aspire CLI diese Aufgabe automatisch. Es aktiviert Abhängigkeiten wie z. B. Redis-Container über einen Dev-Container oder eine Docker-Instanz, verwaltet die Endpunkterkennung und bietet privaten Zugriff zwischen Diensten mithilfe der Diensterkennung.

Aspire verwendet ein Reverse-Proxy- und Endpunktauflösungssystem, so dass das Web-Frontend keine fest kodierten Portnummern kennen muss. Die API wird einfach beim Namen genannt (z. B. "apiservice") - den Rest erledigt Aspire.

Dadurch wird die Erfahrung der Entwickler drastisch verbessert, da lästige Einrichtungsschritte entfallen und sich die Entwickler auf den Code und nicht auf die Infrastruktur konzentrieren können.

Definieren von Diensten und Abhängigkeiten in AppHost

Tim zeigt das Herzstück der Aspire-Konfiguration: die Program.cs-Datei des AppHosts. Unter Verwendung eines Var-Builder-Musters definiert Aspire jeden Dienst mit einfachen Befehlen wie:

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Diese Syntax definiert jede Ressource, legt die Reihenfolge der Abhängigkeiten fest und schafft einen klaren Lebenszyklus der Ressourcen. Aspire wartet automatisch auf Abhängigkeiten und stellt sicher, dass zuerst der Cache, dann die API und dann das Web-Frontend gestartet wird.

Dieser kleine Satz von Anweisungen gibt Entwicklern eine genaue Kontrolle über das Startverhalten und spiegelt wider, wie die Dinge in produktionsreifen verteilten Anwendungen ablaufen würden.

Aspire ausführen und das Dashboard verstehen

Wenn Tim das Projekt ausführt, startet Aspire seine eigene Container-Laufzeitumgebung und öffnet das Aspire Dashboard - eine zentrale Schnittstelle, um alles zu überwachen. Zu Beginn erscheint ein Fehler: "Container runtime unhealthy"-Docker wurde nicht ausgeführt. Sobald Docker gestartet wird, initialisiert Aspire automatisch eine ausführbare Redis-Ressource und verbindet sie mit dem Rest der Anwendung.

Das Dashboard zeigt farbcodierte Statussymbole an, die den Zustand der einzelnen Ressourcen anzeigen. Sobald Redis, die API und das Web-Frontend laufen, wird das Dashboard grün und zeigt an, dass die gesamte Anwendung in Ordnung ist.

Dieses Benachrichtigungssystem spiegelt den Zustand in Echtzeit wider und liefert klarere Fehlermeldungen als Standard-Konsolenprotokolle. Entwickler können Servicebeziehungen visualisieren, Metriken überwachen und sogar direkt von der Benutzeroberfläche aus auf Ressourcenendpunkte zugreifen.

Visuelle Einblicke durch das Aspire Dashboard

Die grafische Ansicht im Dashboard veranschaulicht, wie Dienste miteinander verbunden sind. Das Web-Frontend verbindet sich beispielsweise sowohl mit Redis als auch mit dem API-Dienst, während die API unabhängig ist. Diese Trace-Ansicht hilft, den internen Fluss von Aufrufen und Abhängigkeiten zu verstehen.

Tim hebt hervor, dass das Dashboard Verbesserungen bei den Trace-Details enthält, wie z. B. die Anzeige von Trace-Filteroptionen und Timing-Aufschlüsselungen. Entwickler können HTTP-Anfragen über Dienste hinweg verfolgen und die Auswirkungen auf die Leistung mithilfe der Traces-Ansicht von Aspire sehen.

Zentrale Protokollierung und strukturierte Protokolle

Aspire vereinheitlicht Konsolenprotokolle aus allen Projektdateien in einer Ansicht. Anstatt mit mehreren Protokollfenstern zu jonglieren, können Entwickler das Dashboard verwenden, um Protokolle von allen Diensten - Web-App, API und Redis-Integration - in einer Zeitleiste anzuzeigen.

Tim zeigt, dass Aspire eine strukturierte Protokollierung verwendet, die kontextreiche Einträge wie IDs, Parameter und Tags ermöglicht. Die Entwickler können die Protokolle nach Stufe (Info, Warnung, Fehler) oder Eigenschaftswerten filtern.

Zum Beispiel kann ein Entwickler nur Einträge anzeigen, bei denen "evenOddResult" == "ungerade" ist. Diese fortschrittliche Protokollfilterung in Kombination mit den farbcodierten Präfixen von Aspire macht das Debugging intuitiv und visuell.

Arbeiten mit Traces und Telemetrie

Auf der Registerkarte "Traces" demonstriert Tim, wie Aspire Anfragen über die Dienste der App hinweg verfolgt. Jeder Trace enthält Zeitangaben, Status und Spans, die zeigen, welcher Dienst was verarbeitet hat.

Eine "GetWeather"-Anfrage zeigt beispielsweise an, wann der Cache getroffen oder verfehlt wurde, wann der API-Aufruf erfolgte und wie lange jede Aktion dauerte. Diese Trace-Filterung ermöglicht eine genaue Identifizierung von Engpässen und Abhängigkeiten.

Aspire unterstützt auch OpenTelemetry für den Export von Trace-Daten in andere Tools oder Systeme, so dass Entwickler eine vollständige Beobachtungsmöglichkeit über verteilte Dienste hinweg erhalten.

Echtzeit-Metriken und Leistungsüberwachung

Tim erforscht Metriken wie Anfragedauer, aktive SignalR-Verbindungen und Anzahl der aktiven Anfragen. Diese Metriken visualisieren den Live-Status Ihrer Anwendung und ermöglichen eine frühzeitige Erkennung von Verbindungs- oder Latenzproblemen.

Die Metrikdaten in Aspire 9.5 profitieren auch von Verbesserungen der Trace-Details und einer besseren Trace-Filterung, sodass Entwickler in Echtzeit feststellen können, wo Leistungseinbrüche auftreten.

Aspire ist für die lokale Entwicklung, nicht für die Produktion gedacht

Tim weist ausdrücklich darauf hin, dass das Dashboard von Aspire nicht für den Einsatz auf Produktionsservern gedacht ist. Durch die Bereitstellung würden interne Systemdetails und Umgebungsvariablen offengelegt, was ein Risiko darstellen könnte.

Entwickler können jedoch weiterhin den aspire deploy-Befehl von Aspire verwenden, um Dienste in Azure Container Apps, Azure Container App Jobs oder andere Aspire-Integrationen zu veröffentlichen. Diese Bereitstellungsoptionen nehmen zu, bleiben aber vom Dashboard getrennt.

Aspire soll lokal eine produktionsähnliche Umgebung mit sicheren Upgrades und Preview-Support abbilden und nicht die Überwachungssysteme der Produktion ersetzen.

Experimentieren mit Logging und Exception Handling

Tim fügt auf der Seite Zähler eine strukturierte Protokollierung hinzu und führt auf der Seite Wetter absichtlich eine NotImplementedException ein. Beim erneuten Ausführen erfasst das Dashboard sofort sowohl strukturierte Protokolle als auch unbehandelte Ausnahmen.

Er zeigt, wie die Protokolle von Aspire alle Details anzeigen, einschließlich der Parameternamen, Werte und des Aufrufstapels. Die Integration mit GitHub Models und Copilot AI ermöglicht automatische Erklärungen von Ausnahmen und Code-Vorschläge für Korrekturen - ein Beispiel für die frühe Integration von AI-Diensten und generativen AI-Visualisierern in das Entwicklererlebnis.

Fehleranalyse mit Trace-Filterung

Auf der Registerkarte "Traces" demonstriert Tim, wie fehlgeschlagene API-Aufrufe mit roten Ausrufezeichen angezeigt werden. Wenn Sie auf einen Eintrag klicken, werden alle zugehörigen Protokolle angezeigt, gefiltert nach Spann-ID, und jede Anfrage wird mit mehreren .NET-Projekten verknüpft.

Diese vereinheitlichte Ansicht - Logs, Traces und Health Checks - bietet interaktive Eingabeaufforderungen für das Debugging und den Aufbau beobachtbarer Systeme ohne externe Konfiguration.

Einbindung von Aspire in bestehende .NET-Projekte

Anschließend erklärt Tim, wie man Aspire in eine bestehende Anwendung integriert. Die Entwickler müssen nur zwei Dinge hinzufügen:

• Das AppHost-Projekt, das steuert, welche Dienste gestartet werden und welche Abhängigkeiten sie haben.

• Das ServiceDefaults-Projekt, das Feature Flags, Health Checks, Telemetrie und Service Discovery bietet.

Durch den Verweis auf ServiceDefaults in jeder Projektdatei erhalten die Entwickler automatisch Standard-Umgebungsvariablen, Protokollierungseinstellungen und Telemetrie. Das Endpunktauflösungssystem von Aspire macht die manuelle Weiterleitung von Ports oder die Verwaltung von Verbindungsstrings überflüssig.

Erweiterung von Aspire über den lokalen Gebrauch hinaus

Tim geht darauf ein, wie die Möglichkeiten von Aspire über die lokale Nutzung hinaus erweitert werden. Mit den Integrationen von Azure Container Apps und Azure AI Foundry können Entwickler die Aspire CLI verwenden, um verteilte Systeme mit minimaler Konfiguration bereitzustellen.

Das System unterstützt bereits benutzerdefinierte Ressourcensymbole, Namenseigenschaften und Vorschauunterstützung für KI-Dienste wie OpenAI-Endpunkte oder Azure PostgreSQL-Verbindungen.

Die einheitliche Toolchain von Aspire unterstützt auch die Versionskontrolle und sichere Upgrades zwischen Haupt- und Nebenversionen, so dass die Teams Updates wie Aspire 9.5 ohne Bedenken annehmen können.

Abschließende Überlegungen und Zukunftsaussichten

Am Ende des Videos bezeichnet Tim Aspire als "eine Goldgrube für Entwickler" Das Dashboard vereint Traces View, Health Checks, Logs und Metriken in einem einzigen, einheitlichen Panel - etwas, das es bisher in der lokalen Entwicklung nicht gab.

Für Tim und sein Team wird dieses System nun standardmäßig für jedes neue .NET Aspire-Projekt verwendet. Dadurch werden benutzerdefinierte Builds schneller erstellt, die Erfahrung der Entwickler verbessert und sichergestellt, dass sich produktionsreife verteilte Anwendungen auf verschiedenen Rechnern konsistent verhalten.

Er merkt an, dass größere Aspire-Releases die Trace-Filterung, die Endpunktauflösung und die KI-Integrationen weiter verfeinern werden, wobei der Fokus auf sicheren Upgrades und allgemeiner Verfügbarkeit liegt.

Tim ermutigt alle, Aspire 9.5 zu erkunden, es in ihren nächsten .NET-Projekten zu verwenden und die Einfachheit des einen Befehls zu nutzen, um Protokolle anzuzeigen, Entwicklungstunnel zu verwalten und die gesamte Anwendung lokal zu testen.