Le but de cette série d’articles est de présenter les principes de la technologie .NET Aspire, au travers de la mise en place d’une application « cloud native », que nous commencerons par définir. 

Elle se découpe en 4 parties : 

Le code de la solution est disponible sur ce lien.

Etape initiale : installation des outils 

Nous écrirons notre code avec Visual Studio 2022 version 17.12 pour bénéficier de l’intégration complète de .NET Aspire dans l’outil (après installation de la charge de travail Aspire), et .NET 9 (pour le fun ! 😁).  

Note : 

Il est possible également d’utiliser d’autres IDE tels que Visual Studio Code ou JetBrains Rider, comme décrit ici 

Etape 1 : création d’une application avec Back/Front 

Cette étape est optionnelle, elle a uniquement pour but de créer une solution .Net contenant un frontal Web et une API. L’idée est d’illustrer comment faire évoluer une application existante pour la transformer en application .NET Aspire. 

L’application est créée de façon extrêmement simpliste en utilisant les templates de projet Web et Api, avec code, fournis par Visual Studio. Aussi nous l’appellerons… Weatherforecast ! 

Création du Backend Weatherforecast.Api 

Nous utilisons ici le template « API web ASP.NET Core », avec le paramétrage par défaut afin de bénéficier d’un code fonctionnel minimaliste : 

La partie « utile » du code se trouve dans le fichier WeatherforecastController.cs, qui renvoie une liste de prévisions météo pour les 5 prochains jours (d’où le nom donné à notre application 😉 !). 

Création du Frontal Web en Blazor Weatherforecast.Web

Nous utiliserons ici le template « Blazor Web App », avec le paramétrage par défaut, là encore afin de bénéficier d’un code fonctionnel minimaliste : 

Appel de l’Api à partir du site Web 

Nous modifions ensuite le code généré par Visual Studio dans le fichier Weather.razor, dans le but d’invoquer le projet API. 

Pour cela, nous remplaçons le code de la méthode OnInitializedAsync()… : 

…par celui-ci :

où Config et Http sont des services injectés dans la page : 

Ajout des services  

Nous ajoutons ensuite dans le fichier Program.cs du projet Web les services d’injection de la classe HttpClient : 

Modification du paramétrage 

La dernière étape est la mise à jour du fichier appsettings.json du projet Web pour définir la valeur de l’Url d’appel : 

Note : 

Le numéro de port est celui défini pour Visual Studio à la création du projet Api, tel qu’il est fourni dans le fichier launchSettings.json de ce projet : 

Test du fonctionnement 

Pour lancer le test, nous définissons les 2 projets au démarrage dans les propriétés de la solution :

Au lancement, notre page Weather doit fonctionner correctement : 

Etape 2 : ajout de l’orchestrateur et des SmartDefaults .NET Aspire 

Orchestration du projet Api 

Pour cette étape, il est possible de rajouter manuellement les projets ApiHost et SmartDefaults, grâce à ces templates sous Visual Studio : 

Une autre option, encore plus simple, est d’utiliser le menu « Support de l’orchestrateuor .NET Aspire » (ou « .NET Aspire Orchestrateur Support« ) disponible par un clic droit sur un de nos projets, par exemple Weatherforecast.Api  : 

Une fenêtre s’affiche pour proposer un nommage des projets .NET Aspire, que nous validons :  

Visual Studio effectue alors plusieurs actions : 

• Les 2 projets Weatherforecast.AppHost et Weatherforecast.ServiceDefaullts sont ajoutés à la solution. 

• Le projet Weatherforecast.Api est automatiquement référencé dans le projet Weatherforecast.AppHost. 

• Le projet Weatherforecast.AppHost est automatiquement défini comme projet de démarrage. 

Le fichier Program.cs du projet Weatherforecast.AppHost contient les lignes suivantes, automatiquement générées : 

L’appel builder.AddProject<..>(…) permet d’injecter le projet Api dans l’orchestrateur .NET Aspire. Cela le rend alors visible et disponible dans le Tableau de bord .NET Aspire… ce qui n’est pas très utile si le projet est seul ! 

Note :  

Le détail du projet ServiceDefaults  est décrit dans notre article 1. 

Orchestration du projet Web 

Nous ajoutons le projet Weatherforecast.Web dans l’orchestrateur par la même technique, via le menu « Support de l’orchestrateur .NET Aspire » (ou « .NET Aspire Orchestrator Support »), opu par un clic droit sur le projet. 

Le message est maintenant différent puisque les projets .NET Aspire ont déjà été générés. Nous validons simplement l’ajout du projet Web dans l’orchestrateur : 

Le fichier Program.cs du projet Weatherforecast.AppHost contient à présent les lignes suivantes : 

Modifications automatisées du code 

Si nous regardons d’un peu plus près les modifications de code, nous pouvons constater que les projets Web et Api ont été enrichis : 

• référencement du projet SmartDefaults, 

• injection des composants de découverte de service, résilience, santé (health check) et télémétrie, via l’appel à la méthode .AddServiceDefaults()  

• ajout des routes pour les tests de bonne santé de l’application (uniquement en mode Développement), via l’appel à la méthode .MapDefaultEndpoints()  

Lancement de l’orchestrateur 

Si nous lançons le projet AppHost, une application web s’ouvre alors : c’est le Tableau de bord .NET Aspire. 

L’onglet « Ressources » (ou « Resources ») affiche nos 2 projets principaux, avec leur état de fonctionnement, et leurs points de terminaison : 

Les boutons d’action permettent d’arrêter ou relancer chaque service, d’accéder au détail de leurs variables d’environnement, et d’accéder aux journaux, aux logs, ou aux métriques pour chacun d’eux : 

Scénario 1 : Api disponible 

Si nous cliquons sur l’Url de lancement du projet Web, et que nous invoquons plusieurs fois la page Weather, nous trouvons dans l’onglet Traces les appels consécutifs : 

 Le détail d’un appel permet d’accéder aux informations de temps de réponse, avec le parcours complet jusqu’à l’Api ! 

 Scénario 2 : Api non disponible 

Nous provoquons ici une panne du système en arrêtant volontairement le service Api, grâce au bouton d’action de l’onglet Ressources (ou « Resources ») :

 Les appels de l’Api ne fonctionnent donc plus : 

Nous pouvons alors constater dans les onglets « Structuré » (ou « Structured« ) et « Traces » que l’application Web a tenté plusieurs appels consécutifs : 

Cela illustre le mécanisme de résilience mis en place par les SmartDefaults, puisque les appels HTTP sont retentés plusieurs fois, jusqu’à atteindre un timeout (de 30 secondes par défaut) en cas d’échecs successifs.

Conclusion 

Cela termine notre 2ᵉ partie de la découverte de .NET Aspire. 

Nous avons pu illustrer dans cet article l’apport de .NET Aspire pour : 

• L’observabilité, par le suivi du comportement des composants backend et frontend, par l’analyse des logs et des traces des appels, 

• La résilience, par les tentatives multiples effectuées par le frontend en cas d’indisponibilité du backend. 

Dans la suite, nous découvrirons les principes de découverte de services et l’utilisation des intégrations.