Einrichten von .NET Aspire auf Linux

Installing the Aspire CLI

[0:48 - 2:20] Tim beginnt bei aspire.dev und bemerkt, dass das Projekt kürzlich von "Aspire.NET" in einfach "Aspire" umbenannt wurde. Die Umbenennung spiegelt den erweiterten Umfang des Tools wider: Während Aspire immer noch auf .NET basiert und primär .NET-Entwicklern dient, unterstützt es nun auch TypeScript-Anwendungs-Hosts sowie weitere Sprachintegrationen sind in Planung.

Die Installation selbst ist ein einzelner Bash-Befehl, der aus der Aspire-Dokumentation für Version 9.2 kopiert wird:

dotnet tool install -g aspirate

dotnet tool install -g aspirate

Nach Ausführen des Installationsprogramms starten Sie Ihre Terminal-Sitzung neu, damit das Tool auf Ihrem PATH registriert wird. Ohne den Neustart wird Ihr Shell den neuen Befehl nicht erkennen.

Bestätigen Sie dann, dass die Installation korrekt abgeschlossen ist:

aspire --version

aspire --version

Wenn die Versionsnummer ausgegeben wird, ist die CLI bereit. Dieser zweistufige Prozess (Installation, Überprüfung) ist die gesamte Einrichtung auf der Terminal-Seite.

Konfigurieren der VS Code-Erweiterung

[2:23 - 3:30] Mit dem installierten CLI besteht der nächste Schritt darin, die VS Code-Erweiterung zu installieren. Öffnen Sie das Erweiterungen-Panel, suchen Sie nach "Aspire" und installieren Sie die offizielle Erweiterung, die von Microsoft veröffentlicht wurde. Die Erweiterung fügt Projektgerüste, Unterstützung für Launchkonfigurationen und Integration mit dem Aspire-Dashboard hinzu.

Nach der Installation führt Visual Studio Code einen Überprüfungsschritt durch, um sicherzustellen, dass CLI und Erweiterung übereinstimmen. Tim merkt an, dass die Erweiterung ein neues Projekt direkt über die Befehlspalette erstellen kann, obwohl er sich stattdessen für die CLI-Methode entscheidet. Diese Wahl ist absichtlich: Wenn Sie die CLI kennen, sind Sie niemals aufgeschmissen, wenn ein GUI-Tool falsch arbeitet. Wenn der VS Code-Vorlagen-Picker nach der Installation keine Aspire-Templates anzeigt, bot die CLI einen sofortigen Rückfall.

Erstellen des Starterprojekts

[3:30 - 6:42] Anstatt den VS Code-Befehl "Create New .NET Project" zu verwenden (der gelegentlich nicht in der Lage war, die Aspire-Templates zu entdecken), wechselt Tim ins Terminal und führt Folgendes aus:

aspire new

aspire new

Mehrere Template-Wahlen erscheinen in der interaktiven Eingabeaufforderung. Für eine Produktionsanwendung würden Sie typischerweise den leeren C#-Anwendungs-Host auswählen und von dort aus aufbauen. Zu Lernzwecken wählt Tim die Starter-App, die eine Blazor-Frontend-Anwendung generiert, die durch eine minimale API unterstütz wird. Die Startervorlage enthält einen Wettervorhersage-Endpunkt, eine Zählerseite und vorkonfigurierte Gesundheitschecks, sodass Sie sofort etwas Funktionales erkunden können.

Nachfolgende Eingabeaufforderungen führen durch die restliche Konfiguration:

T>Projektname: TinyTicket
Ausgabepfad:          TinyTicket
Verwende dev localhost:    Ja
Redis-Cache:          Nein
Testprojekt:         Nein
AI-Agent-Umgebung: Nein

Tim lässt jede optionale Funktion ausgeschaltet, um die Komplexität zu minimieren. Das Ziel ist ein schlanker Ausgangspunkt, auf den sich zukünftige Episoden schrittweise aufbauen werden. Sobald das Gerüst abgeschlossen ist, öffnen Sie den Ordner in Visual Studio Code und vertrauen Sie dem Arbeitsbereich, wenn Sie dazu aufgefordert werden.

Verstehen der Projektstruktur

[6:42 - 10:00] Die generierte Lösung enthält vier Projekte, und die Beziehungen zwischen ihnen zeigen, wie Aspire funktioniert. Das App-Host-Projekt ist die Orchestrierungsschicht. Sein Program.cs umfasst ungefähr zwölf Zeilen Code:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

Beachten Sie, wie das Frontend eine Referenz zur API deklariert und darauf wartet, dass sie gesund wird, bevor es beginnt. Diese Abhängigkeitsreihenfolge, Dienstentdeckung und Gesundheitsprüfung wird alles auf Code-Ebene von Aspire bereitgestellt. Es gibt keine versteckte Magie jenseits dessen, was Sie in dieser Datei sehen.

Neben dem App-Host befindet sich das Service-Defaults-Projekt, das Erweiterungsmethoden für Telemetrie, strukturiertes Logging und die Registrierung von Gesundheitsprüfungen enthält. Dies sind Wahlmöglichkeiten: Wenn Sie noch keine OpenTelemetry oder Gesundheitsendpunkte in Ihren Diensten konfiguriert haben, richten die Standards sie für Sie ein.

Das API-Service-Projekt hat einen einzelnen Endpunkt, der zufällig generierte Wettervorhersagen zurückgibt. Das Web-Projekt ist eine Blazor-Anwendung, die die API über ein HttpClient aufruft, das nur mit einem Dienstnamen ("api") konfiguriert ist. Aspire löst diesen Namen zur korrekten URL zur Laufzeit auf, sodass die Blazor-App niemals eine Portnummer oder einen Hostnamen fest codiert.

Tim hebt ein wichtiges Bereitstellungsdetail hervor: Aspire selbst wird nicht in die Produktion bereitgestellt. Die Orchestrierung ist ein Werkzeug für die Entwicklungszeit. In der Produktion kommen die Service-URLs aus der Konfiguration (Umgebungsvariablen, App-Einstellungen oder eine Bereitstellungspipeline), und die Apps laufen unabhängig ohne den App-Host.

Laufendes Erkunden des Dashboards

[10:59 - 14:46] Starten Sie den App-Host über das Run-and-Debug-Panel in Visual Studio Code, und wählen; Sie das HTTPS-Startprofil. Nach der ersten Wiederherstellung und dem Bau öffnet sich das Aspire-Dashboard im Browser. Beim ersten Verbinden müssen Sie ein Anmeldetoken aus der Terminalausgabe einfügen.

Das Dashboard zeigt vier Kategorien von Observability-Daten ohne zusätzliche Konfiguration:

Konsolenausgabe fasst stdout von jedem Dienst in einer einzigen Ansicht zusammen. Anstatt zwischen Terminal-Tabs zu wechseln, sehen Sie alle Ausgaben durchmischt und nach Dienst filtern.

Strukturierte Logs zeigen Log-Einträge mit ihren strukturierten Eigenschaften intakt. Die Zertifikat-Warnung, die Tim begegnet, erscheint hier mit vollständigem Kontext darüber, welcher Dienst sie generiert hat und auf welchem Schweregrad.

Abläufe zeigen verteilte Aufrufketten. Wenn das Blazor-Frontend Wetterdaten anfordert, zeigt die Spur das HTTP-GET von der Außenseite, den Sprung zum API-Service (was im Video 7,35 Millisekunden dauerte) und die gesamte Seitenrenderzeit. Tim weist darauf hin, dass die absoluten Zahlen weniger wichtig sind als die relativen Vergleiche: Wenn ein Aufruf normalerweise 5 Sekunden dauert und plötzlich 10 braucht, haben Sie Ihre Regression gefunden, ohne einen Profiler anzuhängen.

Metriken bieten dienstbezogene Zähler für Anforderungsraten, Fehlerraten und Ressourcenverbrauch. Das Dashboard deckt auch Umgebungsvariablen und Endpunktanmeldedaten für jeden Dienst auf, was hilfreich ist, um zu überprüfen, ob Konfigurationswerte richtig übertragen werden.

Einführung von Tiny Ticket: Das Serienprojekt

[14:46 - 17:17] Tim legt den Plan für das Projekt dar, das den Rest der Serie begleiten wird. Tiny Ticket ist eine abgespeckte Helpdesk-Anwendung: Benutzer reichen Support-Tickets ein und das System verfolgt Priorität und Status. Das Datenmodell kann so klein wie eine einzelne SQL-Tabelle sein. Der Punkt ist nicht, ein funktionsreiches Produkt zu erstellen, sondern einen vertikalen Schnitt zu schaffen, der jeden Teil des Entwicklungszyklus auf Linux berührt: Aufbau, Testen, Bereitstellung und Verbindung zu externen Diensten.

Die Wettervorhersage- und Zählerseiten der Startervorlage werden durch Ticketansichten ersetzt, aber die Aspire-Orchestrierung, das API-zu-Frontend-Muster und die Servicestandards bleiben erhalten. Zukünftige Episoden werden Microsoft SQL Server als Datenbank hinzufügen, wobei Tim einer häufigen Einwendung entgegentritt: Entwickler, die SQL Server lokal nicht ausführen können (ARM-Prozessoren beispielsweise), greifen manchmal zu einer anderen Datenbank. Seine Antwort ist, dass die Entwicklungsumgebung die Produktion nachbilden sollte. Wenn die Produktionsdatenbank SQL Server ist, muss die Entwicklungsumgebung übereinstimmen, auch wenn das bedeutet, die Datenbank in einem Container auszuführen.

Zusammenfassung: Von Null zum Dashboard

[17:17 - 18:20] In unter zwanzig Minuten deckt das Video die gesamte Aspire-Installation auf Linux ab: eine CLI-Installation, eine VS Code-Erweiterung, ein Gerüstprojekt und ein Dashboard, das strukturiertes Logging, verteilte Spuren und Metriken mit null benutzerdefinierter Konfiguration bereitstellt. Der wahre Wert von Aspire liegt nicht in einem einzigen Merkmal, sondern in der Reibungsreduktion: ein Prozess zum Starten, ein Dashboard zur Überwachung und ein Ort, um zu sehen, wie Dienste interagieren.

Abschluss

[18:20 - 18:53] Die Einrichtung von Aspire auf Linux erfordert das CLI-Tool, die VS Code-Erweiterung und ein Projekterstellungsgerüst. Von dort aus gibt das Dashboard Ihnen Beobachtbarkeit über jeden Dienst, ohne Telemetrie-Code zu schreiben. Die App-Host-Datei definiert Ihr Dienstnetzwerk in einem Dutzend Zeilen, und die Servicestandards übernehmen die Verkabelung, die Sie sonst manuell konfigurieren würden.

Das hier eingeführte Tiny-Ticket-Projekt dient als Grundlage für bevorstehende Episoden zur Datenbankintegration, Azure-Bereitstellung und plattformübergreifenden Workflows. Von diesem Ausgangspunkt aus zu folgen bedeutet, dass jedes neue Konzept auf Infrastruktur aufbaut, die Sie bereits überprüft haben.

Seriennavigation: Dieser Artikel ist Teil der C#-auf-Linux-Serie, die die Tiny Ticket-App entwickelt. Vorher: SQL Server in Docker auf Linux. T>Nächster Schritt: Hinzufügen von Swagger UI zu .NET Aspire auf Linux.

Beispiel-Tipp: Wenn der VS Code-Vorlagenauswähler nach der Erweiterungsinstallation Aspire-Vorlagen nicht findet, verwenden Sie aspire new im Terminal als zuverlässige Alternative und starten Sie anschließend VS Code neu, um den Erweiterungsstatus zu synchronisieren.

Sehen Sie sich das vollständige Video auf seinem YouTube Kanal an, um weitere Einblicke zur Einrichtung von .NET Aspire für die Linux-Entwicklung zu gewinnen.