Emiliano Montesdeoca

Blazor à partir de zéro : Chapitre 3 — Des composants qui passent à l’échelle

Mon, 01 Jun 2026 00:00:00 +0000

Bienvenue dans le Chapitre 3 de Blazor à partir de zéro. Si vous avez manqué le Chapitre 2, commencez par là pour avoir le projet de base prêt.

Au Chapitre 2, on a fait tourner l’application. Ici, on la rend maintenable.

Les apps Blazor deviennent vite désordonnées quand chaque page finit en gros fichier .razor. Les composants évitent ça : plus de cohérence, plus de réutilisation, et des frontières claires entre les morceaux d’UI.

Ce qu’est vraiment un composant Blazor

Un composant est un fichier .razor qui peut :

Rendre du markup
Gérer un état local
Recevoir des entrées via des paramètres
Remonter des événements au parent
Rendre du contenu enfant

À l’exécution, Blazor traite chaque composant comme une petite machine d’état. Quand l’état change, Blazor re-rend et applique un diff DOM.

Votre objectif : des entrées propres et un comportement prévisible.

Étape 1 : Commencer avec un composant ciblé

Créez Components/Common/SectionHeader.razor :

<header class="section-header">
 <h2>@Title</h2>
 @if (!string.IsNullOrWhiteSpace(Subtitle))
 {
 <p>@Subtitle</p>
 }
</header>

@code {
 [Parameter] public string Title { get; set; } = string.Empty;
 [Parameter] public string? Subtitle { get; set; }
}

Utilisez-le dans Components/Pages/Home.razor :

@page "/"

<PageTitle>Blazor à partir de zéro</PageTitle>

<SectionHeader
 Title="Blazor à partir de zéro"
 Subtitle="Le chapitre 3 est consacré aux composants." />

Petit exemple, grande idée : un composant doit être lisible via ses paramètres.

Étape 2 : Utiliser les paramètres pour expliciter le comportement

Créons un bouton réutilisable.

Components/Common/AppButton.razor :

<button class="app-button @VariantCssClass" @onclick="OnClick">
 @Text
</button>

@code {
 [Parameter] public string Text { get; set; } = "Button";
 [Parameter] public string Variant { get; set; } = "primary";
 [Parameter] public EventCallback OnClick { get; set; }

 private string VariantCssClass => Variant.ToLowerInvariant() switch
 {
 "secondary" => "app-button--secondary",
 "danger" => "app-button--danger",
 _ => "app-button--primary"
 };
}

Utilisation :

@code {
 private int _savedCount;

 private void Save()
 {
 _savedCount++;
 }
}

<AppButton Text="Save" Variant="primary" OnClick="Save" />
<p>Sauvegardé @_savedCount fois.</p>

Le point central est le contrat :

Paramètres simples et clairs
Noms explicites plutôt que logique implicite
Valeurs par défaut sûres

Étape 3 : Utiliser `RenderFragment` pour la composition

RenderFragment permet au parent d’injecter des blocs d’UI dans l’enfant.

Créez Components/Common/Card.razor :

<article class="card">
 <header class="card__header">@Title</header>
 <section class="card__body">
 @ChildContent
 </section>
</article>

@code {
 [Parameter] public string Title { get; set; } = string.Empty;
 [Parameter] public RenderFragment? ChildContent { get; set; }
}

Utilisation :

<Card Title="Roadmap">
 <ul>
 <li>Composants</li>
 <li>Data binding</li>
 <li>Routing</li>
 </ul>
</Card>

Ce pattern évite de répéter le même markup de structure partout.

Étape 4 : Préférer la composition aux pages géantes

Quand une page grossit trop, découpez par responsabilité :

ProfileSummary pour le bloc d’identité
ProfileStats pour les métriques
ProfileActivityList pour l’activité récente

La page devient orchestration, pas implémentation.

Étape 5 : Équilibrer markup et logique

Pour les composants simples, @code inline suffit.

Pour les composants plus gros, passez en code-behind :

UserCard.razor
UserCard.razor.cs

Vous gagnez en lisibilité côté markup et côté logique C#.

Étape 6 : Une structure de dossiers pragmatique

Une structure qui passe bien à l’échelle :

Components/Pages/ -> pages routables
Components/Layout/ -> shell applicatif et navigation
Components/Common/ -> blocs génériques partagés
Components/Features/<FeatureName>/ -> composants spécifiques à une feature

Erreurs fréquentes au début

Trop de paramètres au lieu d’un modèle dédié
Règles métier directement dans les pages
Un composant “Dieu” de centaines de lignes
Duplication de markup au lieu d’extraction de composants

Chapitre suivant

Dans le Chapitre 4, on abordera data binding et événements : @bind, gestion des événements, compromis du two-way binding et patterns pour garder un état prévisible.

Blazor à partir de zéro : Chapitre 2 — Votre première application Blazor

Thu, 14 May 2026 00:00:00 +0000

Bienvenue au chapitre 2 de Blazor à partir de zéro. Si vous avez manqué le chapitre 1, lisez-le d’abord pour garder le contexte des modes de rendu.

Dans ce chapitre, nous allons créer une nouvelle application Blazor, l’exécuter en local et comprendre le rôle des fichiers essentiels.

Étape 1 : créer le projet

Depuis votre terminal :

dotnet new blazor -o BlazorFromScratch
cd BlazorFromScratch

Cela crée une application web Blazor .NET 9 avec la structure par défaut.

Si l’outil vous demande un modèle d’interactivité, commencez avec Interactive Server. C’est le mode le plus simple pour apprendre : tout s’exécute côté serveur.

Étape 2 : l’exécuter en local

Démarrez l’application :

dotnet watch

Ouvrez ensuite l’URL affichée dans le terminal (généralement https://localhost:5xxx). Vous devriez voir l’application par défaut avec Home, Counter et Weather.

Si cela fonctionne, votre environnement est prêt.

Étape 3 : comprendre la structure du projet

Voici les dossiers et fichiers à connaître en priorité :

Program.cs — enregistre les services et configure le pipeline HTTP.
Components/App.razor — composant racine de l’application.
Components/Routes.razor — définition des routes.
Components/Pages/ — pages routables comme Home et Counter.
Components/Layout/ — layout partagé (MainLayout.razor, menu).
wwwroot/ — assets statiques (CSS, images, favicon).
appsettings.json — valeurs de configuration.

Ne cherchez pas à tout maîtriser maintenant. Comprendre où vit l’UI et où démarre l’application suffit pour cette étape.

Étape 4 : votre première modification

Ouvrez Components/Pages/Home.razor et remplacez le contenu par :

@page "/"

<PageTitle>Blazor à partir de zéro</PageTitle>

<h1>Blazor à partir de zéro</h1>
<p>Le chapitre 2 tourne en local.</p>

Enregistrez puis rechargez le navigateur. Avec dotnet watch, la mise à jour est immédiate.

Ce petit changement confirme la boucle complète : modifier -> compiler -> afficher.

Étape 5 : lire Program.cs une fois

Pas besoin de le mémoriser, mais repérez ces lignes :

AddRazorComponents() active les composants Razor.
AddInteractiveServerComponents() active les composants interactifs côté serveur.
MapRazorComponents<App>() mappe le composant racine vers des endpoints.

Ces lignes expliquent comment l’application démarre et quels modes sont actifs.

Problèmes courants

Si quelque chose casse, c’est souvent l’un de ces points :

SDK trop ancien : lancez dotnet --version et vérifiez .NET 9.
Certificat HTTPS : lancez dotnet dev-certs https --trust.
Conflit de ports : arrêtez d’anciens processus dotnet puis relancez.

Prochain chapitre

Dans le chapitre 3, nous irons en profondeur sur les composants : paramètres, composition et structure d’une UI réutilisable.

Blazor de zéro : Chapitre 1 — Qu'est-ce que Blazor ?

Fri, 08 May 2026 00:00:00 +0000

Bienvenue au Chapitre 1 de Blazor de zéro. Si vous avez manqué le post d’introduction où j’explique le but de cette série et à qui elle s’adresse, commencez par là — c’est court.

Dans ce chapitre, nous allons répondre à la question fondamentale : qu’est-ce que Blazor ? Cela semble simple, mais la réponse a plusieurs couches, d’autant plus que « Blazor » a pris des significations légèrement différentes au fil des années. À la fin de ce post, vous saurez ce qu’est Blazor, comment il s’intègre dans l’écosystème .NET, quels sont les différents modèles de rendu et pourquoi vous pourriez — ou non — le choisir plutôt qu’un framework JavaScript.

Un peu d’histoire

Blazor a démarré comme un projet expérimental de Steve Sanderson chez Microsoft vers 2017. L’idée était provocatrice : exécuter du C# dans le navigateur via WebAssembly, en éliminant totalement le besoin de JavaScript. C’était une preuve de concept, et le nom était un mélange délibéré de Blazer et Razor — le moteur de templates sur lequel Blazor allait finalement être construit.

L’expérience a suscité suffisamment d’enthousiasme pour que Microsoft la prenne au sérieux. Blazor a été livré dans le cadre d’ASP.NET Core 3.0 en septembre 2019, d’abord sous forme de Blazor Server — un modèle qui exécute votre code C# sur le serveur et utilise une connexion SignalR en temps réel pour envoyer les mises à jour de l’interface au navigateur. Blazor WebAssembly a suivi en mai 2020 dans le cadre d’ASP.NET Core 3.1, apportant une véritable exécution côté client au framework.

.NET 6 et 7 ont affiné l’expérience développeur. Puis .NET 8, publié en novembre 2023, a fondamentalement repensé le modèle de rendu avec ce que Microsoft a appelé UI web full-stack. Le rendu statique côté serveur, le streaming rendering, le serveur interactif, WebAssembly interactif et un nouveau mode Auto coexistaient sous le même toit dans un seul projet. .NET 9 a construit sur ces fondations et corrigé les aspérités.

C’est là où nous en sommes aujourd’hui.

Ce qu’est vraiment Blazor

À son cœur, Blazor est un framework d’interface basé sur les composants pour .NET. Vous construisez votre interface à partir de composants — des éléments autonomes de C# et de balisage HTML qui peuvent maintenir un état, répondre à des événements et se composer en structures plus larges. Si vous avez travaillé avec React ou Vue, ce modèle mental vous semblera familier. La différence clé est qu’au lieu de JavaScript, vous écrivez du C#.

Les composants Blazor s’écrivent dans des fichiers .razor. Un fichier .razor mélange du balisage HTML et du code C# en utilisant la syntaxe Razor que vous connaissez peut-être déjà des vues ASP.NET MVC. Voici à quoi ressemble un composant simple :

@page "/counter"

<h1>Compteur</h1>
<p>Compte actuel : @currentCount</p>
<button @onclick="IncrementCount">Cliquez ici</button>

@code {
 private int currentCount = 0;

 private void IncrementCount()
 {
 currentCount++;
 }
}

Pas de JavaScript en vue. La directive @onclick connecte le clic du bouton à une méthode C#. L’expression @currentCount affiche la valeur actuelle. Quand l’état change, Blazor détermine ce qu’il faut mettre à jour dans le DOM.

C’est l’essentiel. Tout le reste — routage, injection de dépendances, formulaires, appels HTTP — est construit sur ce modèle de composants.

Les modèles de rendu

C’est là que réside beaucoup de confusion, alors soyons précis. « Blazor » désigne aujourd’hui une famille de modes de rendu, pas un seul modèle de déploiement. Comprendre la différence est important car cela affecte les performances, les exigences d’infrastructure et ce que vos composants peuvent ou ne peuvent pas faire.

SSR statique

Le mode le plus simple. Vos composants Razor s’affichent sur le serveur en HTML et ce HTML est envoyé au navigateur. Il n’y a pas de connexion persistante, pas de WebAssembly et pas d’interactivité côté client par défaut. C’est essentiellement ce que fait Razor Pages, mais en utilisant le modèle de composants.

Utilisez-le pour les pages riches en contenu, les landing pages, tout ce qui ne nécessite pas d’interactivité en temps réel.

Serveur interactif

Votre code de composant s’exécute sur le serveur. Une connexion WebSocket SignalR est établie entre le navigateur et le serveur. Quand vous cliquez sur un bouton ou tapez dans un champ, l’événement voyage via le WebSocket jusqu’au serveur, votre C# s’exécute, le diff est calculé et les mises à jour du DOM sont renvoyées au navigateur.

Avantages : Accès complet aux ressources serveur (bases de données, système de fichiers, secrets). Chargement initial rapide. Taille de téléchargement réduite. Fonctionne dans les navigateurs sans support WebAssembly.

Inconvénients : Chaque interaction utilisateur nécessite un aller-retour vers le serveur, ce qui ajoute de la latence. Les ressources serveur s’adaptent au nombre de connexions actives. L’application se dégrade si la connexion est interrompue.

Utilisez-le pour les applications métier, les outils internes, les applications où l’accès aux données côté serveur prime sur la capacité hors ligne.

WebAssembly interactif

Le runtime .NET est téléchargé dans le navigateur et votre application s’exécute entièrement côté client. Après le téléchargement initial, l’application fonctionne complètement hors ligne et chaque interaction est instantanée — sans allers-retours serveur pour la logique d’interface.

Avantages : Exécution véritablement côté client. Fonctionne hors ligne. Charge serveur réduite une fois l’application chargée.

Inconvénients : Téléchargement initial plus volumineux (runtime .NET + votre application). Premier chargement plus lent. Vous avez besoin d’une API pour accéder aux données côté serveur.

Utilisez-le pour les applications pouvant fonctionner hors ligne, les outils nécessitant une réactivité immédiate, les scénarios où le traitement serveur n’est pas nécessaire pour l’interface.

Mode Auto

Introduit dans .NET 8. L’application démarre en mode Serveur interactif (chargement initial rapide, sans attendre que WebAssembly se télécharge). Une fois les fichiers WebAssembly téléchargés en arrière-plan, les visites suivantes basculent automatiquement en mode WebAssembly.

Cela vous donne le chargement initial rapide du mode Serveur et finalement l’exécution complète côté client de WebAssembly. C’est le modèle le plus complexe à appréhender, mais c’est une valeur par défaut pratique pour de nombreuses applications.

Mélanger les modes dans la même application

Avec .NET 8 et les versions ultérieures, vous n’êtes pas limité à un seul mode de rendu pour toute l’application. Une landing page peut être en SSR statique ; le tableau de bord authentifié peut être en Serveur interactif ; un widget de visualisation de données peut être en WebAssembly interactif. Le framework gère les transitions.

Dans cette série, nous commencerons par le Serveur interactif car c’est le plus simple à mettre en place et le modèle mental le plus direct. Nous explorerons les autres modes au fur et à mesure.

Comment Blazor se compare aux frameworks JavaScript

Si vous avez développé avec React, Angular ou Vue, c’est probablement la comparaison qui vous intéresse.

Les similitudes sont réelles. Le modèle de composants de Blazor est délibérément similaire à celui de React. Vous avez des props (Paramètres dans Blazor), un état local (champs dans le bloc @code), des hooks de cycle de vie et le même modèle de communication données vers le bas / événements vers le haut. Si vous connaissez React, vous serez à l’aise en quelques heures.

La différence clé est le langage. Dans Blazor, vous écrivez du C#. Votre logique métier, vos règles de validation et vos modèles de données peuvent tous être partagés entre votre frontend Blazor et votre backend ASP.NET Core. Fini de dupliquer une classe User en TypeScript quand vous l’avez déjà en C#.

L’écart d’écosystème est réel mais se réduit. L’écosystème npm est énorme. L’écosystème NuGet pour les composants d’interface est plus petit, bien qu’il ait considérablement grandi. Pour une librairie de graphiques spécifique ou un widget de glisser-déposer, JavaScript a encore plus d’options. Mais pour la plupart des applications métier, ce qui est disponible dans l’écosystème .NET est largement suffisant.

L’interopérabilité JavaScript existe quand vous en avez besoin. Blazor vous permet d’appeler JavaScript depuis C# et C# depuis JavaScript. Pour les API navigateur sans wrapper .NET, ou quand vous voulez utiliser une librairie JS existante, l’interop est disponible. Cela ajoute une couche mais ce n’est pas pénible.

La réponse honnête : si votre équipe est entièrement composée de développeurs JavaScript qui construisent un produit public où le SEO, les performances et l’écosystème npm sont critiques, restez avec JavaScript. Si votre équipe est composée de développeurs .NET, si vous construisez des applications internes ou métier, ou si le partage de code entre frontend et backend vous importe, Blazor est un choix convaincant.

Ce dont vous avez besoin pour suivre la série

Pour le reste de cette série, vous aurez besoin de :

.NET 9 SDK — téléchargez-le sur dot.net
Un IDE — Visual Studio 2022 (l’édition Community est gratuite), VS Code avec l’extension C# Dev Kit, ou JetBrains Rider
Une aisance de base avec C# — classes, propriétés, interfaces, async/await

C’est tout. Pas de Node, pas de npm, pas de webpack.

La suite

Au Chapitre 2, nous allons générer votre première application Blazor, parcourir la structure du projet et nous assurer que vous pouvez l’exécuter localement. À la fin, vous aurez une application fonctionnelle et une image claire de ce que fait chaque fichier.

À bientôt.

Blazor de zéro : une nouvelle série

Mon, 04 May 2026 00:00:00 +0000

Cela fait un moment que j’écris sur Blazor — les cycles de vie des composants, le CSS isolé, les modèles d’interactivité, l’authentification. Ces articles ont été utiles pris individuellement, mais j’ai toujours senti qu’ils manquaient de fondation. Ils supposent que vous savez déjà ce qu’est Blazor, pourquoi il existe et comment il s’intègre dans l’écosystème .NET. Ce n’est pas le cas de tout le monde, et c’est tout à fait normal.

Je commence donc quelque chose de nouveau : Blazor de zéro. Une vraie série, construite depuis les bases, destinée aux développeurs qui veulent réellement comprendre ce qu’ils construisent — pas seulement copier-coller jusqu’à ce que ça fonctionne.

À qui s’adresse cette série

Cette série est faite pour vous si :

Vous êtes un développeur .NET qui a entendu parler de Blazor mais n’a jamais trouvé le bon moment ou le bon point de départ pour s’y plonger.
Vous avez essayé Blazor, vous l’avez fait fonctionner, mais vous avez le sentiment de deviner pourquoi les choses fonctionnent.
Vous venez du monde JavaScript/React/Angular et voulez comprendre ce que Microsoft propose pour le frontend moderne.
Vous voulez une ressource unique et cohérente plutôt que de la documentation éparpillée et des articles de blog dispersés.

Vous n’avez pas besoin d’être un développeur senior. Vous devez en revanche être à l’aise avec les bases de C# — classes, interfaces, async/await. Si vous pouvez écrire une simple API CRUD en ASP.NET Core, vous êtes prêt.

Ce que nous allons couvrir

Voici une feuille de route approximative de ce que j’ai prévu. Certains sujets se développeront en plusieurs articles si nécessaire :

Qu’est-ce que Blazor ? — Modèles d’hébergement, historique, comparaison avec le développement web traditionnel
Votre première app Blazor — Scaffolding, structure du projet, exécution en local
Les composants — Le bloc fondamental de toute interface Blazor
Liaison de données et événements — Rendre votre interface réactive
Communication entre composants — Paramètres, EventCallbacks, valeurs en cascade
Routing et navigation — Comment Blazor gère les URLs et les transitions de pages
Injection de dépendances — Services, scopes et le conteneur DI dans Blazor
Formulaires et validation — EditForm, DataAnnotations, validateurs personnalisés
HTTP et données externes — Appeler des APIs depuis votre app Blazor
Authentification et autorisation — Sécuriser votre app correctement
Interop JavaScript — Quand vous avez besoin d’accéder au navigateur
Performance et optimisation — Virtualisation, lazy loading, stratégies de rendu
Tester les composants Blazor — bUnit et à quoi ressemble un bon test
Déploiement — Publier sur Azure, IIS et les hébergeurs statiques

Cette liste évoluera. Certains sujets seront divisés en plusieurs articles ; d’autres pourront être fusionnés. Je mettrai à jour cet article au fil de la série et ajouterai des liens vers chaque entrée au fur et à mesure de leur publication.

Pourquoi une série, pourquoi maintenant

Blazor a beaucoup mûri. Avec .NET 8 et 9, le modèle de rendu a été profondément remanié — SSR statique, streaming rendering, Server interactif, WebAssembly interactif et le mode Auto coexistent désormais sous le même toit. C’est un framework vraiment intéressant et capable, mais la complexité croissante rend l’expérience de démarrage désorientante.

Je veux construire une ressource qui vous rencontre là où vous en êtes et vous guide à travers tout de manière systématique. Pas un remplacement de la documentation officielle — elle est bonne et vous devriez la lire — mais un complément qui explique le pourquoi derrière le quoi.

Comment suivre la série

Chaque article de la série sera suffisamment autonome pour être lu seul, mais ils s’appuieront aussi les uns sur les autres. Si vous commencez de zéro, je recommande de suivre l’ordre. Si vous rejoignez la série pour combler un manque précis, c’est aussi possible — je renverrai aux articles prérequis lorsque c’est nécessaire.

Le code de chaque article sera disponible sur GitHub. Je partagerai les liens au fur et à mesure.

À bientôt dans le prochain article.

Types de syndicats C# : les syndicats discriminés arrivent enfin

Wed, 01 Apr 2026 00:00:00 +0000

Si vous écrivez du C# depuis un certain temps, il y a de fortes chances que vous vous heurtiez à un mur lorsque vous essayez de modéliser quelque chose qui peut être « une chose parmi plusieurs ». Peut-être aviez-vous besoin d’une méthode pour renvoyer soit une valeur de réussite, soit une erreur. Peut-être étiez-vous en train de créer un système de paiement qui gère les cartes de crédit, les virements bancaires et les portefeuilles numériques, chacun avec des données totalement différentes. Ou peut-être avez-vous simplement regardé F# ou Rust et pensé : « Pourquoi ne puis-je pas avoir cela en C# ?

L’attente est presque terminée. Les syndicats discriminés arrivent en C#.

Il s’agit de l’une des fonctionnalités linguistiques les plus demandées depuis des années, avec des discussions communautaires remontant à 2017 et avant. L’équipe de conception du langage C# a travaillé sur une proposition qui introduit un mot-clé union pour définir des hiérarchies de types fermées avec une correspondance de modèles exhaustive. Dans cet article, je souhaite vous expliquer ce que sont les syndicats discriminés, pourquoi ils sont si importants, comment nous les avons simulés jusqu’à présent et à quoi ressemble réellement la syntaxe proposée – avec de vrais exemples de code pour chacun.

Un petit mot avant de plonger dans le vif du sujet : au moment d’écrire ces lignes, la fonctionnalité des types d’union est encore au stade de la proposition et de l’aperçu. La syntaxe et le comportement que je décris ici sont basés sur les derniers documents de conception accessibles au public et sur les discussions de l’équipe de conception du langage C#. Les choses peuvent changer avant la version finale. Je serai clair sur ce qui est confirmé par rapport à ce qui est encore en discussion.

Que sont les syndicats discriminés ?

À la base, une union discriminée (parfois appelée « union étiquetée » ou « type somme ») est un type qui peut contenir l’une d’un ensemble fixe de valeurs possibles, où chaque variante peut transporter des données différentes. La partie « discriminée » signifie que le runtime sait toujours de quelle variante il s’agit — il y a une balise qui l’identifie.

Pensez-y comme à un enum, mais où chaque membre peut transporter sa propre charge utile de données.

Si vous avez utilisé d’autres langages, vous avez probablement déjà vu ce concept :

F# a des syndicats discriminés depuis le premier jour :

type Shape =
 | Circle of radius: float
 | Rectangle of width: float * height: float
 | Triangle of base: float * height: float

Rust utilise enum pour la même idée :

enum Shape {
 Circle { radius: f64 },
 Rectangle { width: f64, height: f64 },
 Triangle { base: f64, height: f64 },
}

TypeScript réalise quelque chose de similaire avec les unions balisées :

type Shape =
 | { kind: "circle"; radius: number }
 | { kind: "rectangle"; width: number; height: number }
 | { kind: "triangle"; base: number; height: number };

Dans tous ces cas, le compilateur connaît toutes les variantes possibles et peut vous obliger à les gérer toutes. C’est le super pouvoir : vérifier l’exhaustivité. Si vous ajoutez une nouvelle variante, le compilateur vous indique partout où vous avez oublié de la gérer.

C# n’a jamais eu de moyen efficace d’exprimer cela. Jusqu’à maintenant.

Comment nous simulons les syndicats aujourd’hui

Au fil des années, la communauté C# a proposé plusieurs solutions de contournement, chacune comportant ses propres compromis. Permettez-moi de passer en revue les approches les plus courantes.

Enregistrements abstraits avec héritage

La solution de contournement la plus idiomatique en C# moderne consiste à utiliser des enregistrements abstraits avec des types dérivés scellés :

public abstract record Shape
{
 public sealed record Circle(double Radius) : Shape;
 public sealed record Rectangle(double Width, double Height) : Shape;
 public sealed record Triangle(double Base, double Height) : Shape;

 private Shape() { } // Prevent external inheritance
}

Cela fonctionne raisonnablement bien. Vous obtenez l’immuabilité, l’égalité des valeurs et vous pouvez utiliser la correspondance de modèles :

double Area(Shape shape) => shape switch
{
 Shape.Circle c => Math.PI * c.Radius * c.Radius,
 Shape.Rectangle r => r.Width * r.Height,
 Shape.Triangle t => 0.5 * t.Base * t.Height,
 _ => throw new InvalidOperationException("Unknown shape")
};
```Mais il existe des inconvénients importants. Le compilateur ne sait pas que la hiérarchie est fermée, vous avez donc toujours besoin de ce bras de suppression de `_` ou vous recevez un avertissement. Si vous ajoutez une nouvelle variante, le compilateur ne vous indiquera pas tous les endroits où vous avez oublié de la gérer : la suppression l'avale silencieusement. Cela va complètement à l’encontre du but recherché.

### La bibliothèque OneOf

Une autre approche populaire est le package NuGet [OneOf](https://github.com/mcintyre321/OneOf) :

```csharp
public OneOf<Success<Order>, NotFound, ValidationError> ProcessOrder(OrderRequest request)
{
 // ...
}

// Usage
var result = ProcessOrder(request);
result.Switch(
 success => Console.WriteLine($"Order {success.Value.Id} processed"),
 notFound => Console.WriteLine("Order not found"),
 error => Console.WriteLine($"Validation failed: {error.Message}")
);

OneOf fournit une vérification d’exhaustivité au moment de la compilation via ses paramètres de type génériques, ce qui est génial. Mais il repose sur la correspondance de position (premier type, deuxième type, etc.), les signatures génériques deviennent rapidement lourdes et ne s’intègre pas à la correspondance de modèles du langage. C’est un hack intelligent, mais ça reste un hack.

Énumération manuelle + modèle de données

Certains développeurs choisissent la voie classique avec une balise enum et un conteneur de données :

public enum PaymentType { CreditCard, BankTransfer, DigitalWallet }

public class Payment
{
 public PaymentType Type { get; init; }
 public CreditCardInfo? CreditCard { get; init; }
 public BankTransferInfo? BankTransfer { get; init; }
 public DigitalWalletInfo? DigitalWallet { get; init; }
}

C’est fragile. Rien ne vous empêche de définir Type sur CreditCard mais de renseigner la propriété BankTransfer. Le compilateur ne peut pas vous aider et vous vous retrouvez avec des erreurs d’exécution et des vérifications nulles partout. Il s’agit de l’approche “stringly-typée” de la modélisation de types, et elle n’est pas évolutive.

Toutes ces approches partagent un problème fondamental : elles combattent le langage au lieu de travailler avec lui. Le compilateur ne peut pas raisonner sur l’ensemble fermé des possibilités, vous perdez donc la propriété la plus précieuse des unions discriminées : la vérification exhaustive.

La proposition C# : le mot clé `union`

La proposition de l’équipe du langage C# introduit un mot-clé dédié union qui définit un ensemble fermé de membres nommés, chacun portant éventuellement des données. Voici la syntaxe de base telle qu’elle a été proposée :

union Shape
{
 Circle(double Radius),
 Rectangle(double Width, double Height),
 Triangle(double Base, double Height)
}

C’est tout. Propre, concis et immédiatement lisible. Chaque membre au sein de l’union définit une variante distincte avec ses propres données. Le compilateur sait que Shape ne peut être qu’une de ces trois choses.

Sous le capot, le compilateur génère une hiérarchie de types scellée, similaire à ce que vous écririez à la main avec des enregistrements abstraits, mais avec une pleine conscience du compilateur de la nature fermée du type. Cela signifie que le compilateur peut imposer l’exhaustivité dans la correspondance de modèles, ce qui constitue le principal avantage.

### Membres à valeur uniquement

Les membres du syndicat ne sont pas obligés de transporter des données. Vous pouvez mélanger des membres porteurs de données avec des membres de valeur simples :

union Option<T>
{
 Some(T Value),
 None
}

Il s’agit du type classique Option/Maybe que les programmeurs fonctionnels demandent en C# depuis des années. None ne contient aucune donnée : c’est juste une balise.

Syndicats génériques

Comme vous pouvez le voir dans l’exemple Option<T> ci-dessus, les syndicats soutiennent les génériques. Voici un exemple plus complexe :

union Result<T, E>
{
 Ok(T Value),
 Error(E Err)
}

Cela ouvre tout un style de gestion des erreurs qui ne repose pas sur des exceptions pour les cas d’échec attendus – ce qui est une pratique standard dans Rust et les langages fonctionnels depuis des années.

Unions avec méthodes

La proposition permet également aux syndicats d’avoir des méthodes, des propriétés calculées et d’implémenter des interfaces, comme n’importe quel autre type :```csharp union Shape { Circle(double Radius), Rectangle(double Width, double Height), Triangle(double Base, double Height);

public double Area => this switch
{
Circle(var r) => Math.PI * r * r,
Rectangle(var w, var h) => w * h,
Triangle(var b, var h) => 0.5 * b * h
};
public double Perimeter => this switch
{
Circle(var r) => 2 * Math.PI * r,
Rectangle(var w, var h) => 2 * (w + h),
Triangle(var b, var h) => b + h + Math.Sqrt(b * b + h * h)
};

}


Remarquez comment l'expression `switch` à l'intérieur de `Area` et `Perimeter` n'a pas besoin d'un bras par défaut. Le compilateur sait que l’union est exhaustive : il n’existe que trois variantes, et toutes les trois sont gérées. Si vous ajoutez une quatrième variante plus tard, le compilateur signalera chaque `switch` qui ne la gère pas.

## Intégration de correspondance de modèles

La correspondance de modèles évolue en C# depuis la version 7.0, et les types d'union sont conçus pour être des citoyens de premier ordre de ce système.

### Expressions de commutation exhaustives

La fonctionnalité la plus efficace est la vérification exhaustive des commutateurs. Avec les unions, le compilateur **connaît** tous les cas possibles :

```csharp
string Describe(Shape shape) => shape switch
{
 Circle(var r) => $"A circle with radius {r}",
 Rectangle(var w, var h) => $"A {w}x{h} rectangle",
 Triangle(var b, var h) => $"A triangle with base {b} and height {h}"
};

Pas de bras de rejet. Non _ => throw new NotImplementedException(). Si vous oubliez un cas, le compilateur émet une erreur et non un avertissement. Il s’agit d’une amélioration fondamentale en matière de sécurité.

Correspondance de modèles imbriqués

Les unions composent naturellement avec des motifs imbriqués :

union Expr
{
 Literal(double Value),
 Add(Expr Left, Expr Right),
 Multiply(Expr Left, Expr Right),
 Negate(Expr Inner)
}

double Evaluate(Expr expr) => expr switch
{
 Literal(var v) => v,
 Add(var left, var right) => Evaluate(left) + Evaluate(right),
 Multiply(var left, var right) => Evaluate(left) * Evaluate(right),
 Negate(var inner) => -Evaluate(inner)
};

Ce type de structure de données récursive est extrêmement courant dans les compilateurs, les interprètes, les moteurs de règles et la modélisation mathématique. Aujourd’hui, en C#, vous auriez besoin d’une hiérarchie de classes approfondie et du modèle de visiteur. Avec les syndicats, le code est considérablement plus simple.

Clauses de garde

La correspondance de modèles avec les unions prend en charge les gardes when comme vous vous en doutez :

string Classify(Shape shape) => shape switch
{
 Circle(var r) when r > 100 => "Large circle",
 Circle(var r) when r > 10 => "Medium circle",
 Circle(_) => "Small circle",
 Rectangle(var w, var h) when w == h => "Square",
 Rectangle _ => "Rectangle",
 Triangle _ => "Triangle"
};

Exemples pratiques

Permettez-moi de vous présenter quelques scénarios concrets dans lesquels les types de syndicats améliorent considérablement le code.

Le modèle de résultat : remplacement des exceptions pour les erreurs attendues

L’un des modèles les plus courants dans le développement d’applications modernes consiste à représenter des opérations qui peuvent réussir ou échouer sans utiliser d’exceptions pour le flux de contrôle. Les exceptions doivent être exceptionnelles – des choses comme des pannes de réseau ou des conditions de mémoire insuffisante. Une erreur de validation ou un résultat « introuvable » est un résultat attendu et non une exception.

union Result<T, E>
{
 Ok(T Value),
 Error(E Err)
}

union OrderError
{
 NotFound(Guid OrderId),
 InsufficientStock(string ProductId, int Requested, int Available),
 PaymentDeclined(string Reason),
 ValidationFailed(IReadOnlyList<string> Errors)
}

Result<Order, OrderError> ProcessOrder(OrderRequest request)
{
 if (!Validate(request, out var errors))
 return new ValidationFailed(errors);

 var product = catalog.Find(request.ProductId);
 if (product is null)
 return new NotFound(request.OrderId);

 if (product.Stock < request.Quantity)
 return new InsufficientStock(request.ProductId, request.Quantity, product.Stock);

 var paymentResult = paymentGateway.Charge(request.Payment);
 if (!paymentResult.Success)
 return new PaymentDeclined(paymentResult.Message);

 var order = CreateOrder(request, product);
 return new Ok(order);
}

L’appelant est alors obligé de gérer tous les résultats possibles :

var result = ProcessOrder(request);

var response = result switch
{
 Ok(var order) => Results.Created($"/orders/{order.Id}", order),
 Error(NotFound(var id)) => Results.NotFound($"Order {id} not found"),
 Error(InsufficientStock(var pid, var req, var avail)) =>
 Results.Conflict($"Product {pid}: requested {req}, only {avail} available"),
 Error(PaymentDeclined(var reason)) =>
 Results.UnprocessableEntity($"Payment declined: {reason}"),
 Error(ValidationFailed(var errors)) =>
 Results.BadRequest(new { Errors = errors })
};

Pas de blocs try-catch, pas de types d’exceptions oubliés, pas de surprises d’exécution. Chaque mode de défaillance est visible dans la signature de type et appliqué par le compilateur. Il s’agit d’une amélioration considérable de la fiabilité de l’API.

Modélisation de domaine : types de paiement

Voici un exemple concret de modélisation de domaine — gérant différentes méthodes de paiement dans un système de commerce électronique :

union PaymentMethod
{
 CreditCard(string CardNumber, string Expiry, string Cvv),
 BankTransfer(string Iban, string Bic),
 DigitalWallet(string Provider, string Token),
 CashOnDelivery
}

decimal CalculateProcessingFee(PaymentMethod method, decimal amount) => method switch
{
 CreditCard _ => amount * 0.029m + 0.30m,
 BankTransfer _ => 1.50m,
 DigitalWallet(provider: "PayPal", _) => amount * 0.034m + 0.35m,
 DigitalWallet _ => amount * 0.025m,
 CashOnDelivery => 4.99m
};

string FormatForReceipt(PaymentMethod method) => method switch
{
 CreditCard(var num, _, _) => $"Credit Card ending in {num[^4..]}",
 BankTransfer(var iban, _) => $"Bank Transfer ({iban[..4]}****)",
 DigitalWallet(var provider, _) => $"Digital Wallet ({provider})",
 CashOnDelivery => "Cash on Delivery"
};

Comparez cela à l’approche actuelle où vous auriez une interface ou une classe abstraite avec cinq implémentations différentes réparties sur cinq fichiers, éventuellement avec un modèle de visiteur au-dessus. L’approche syndicale maintient la définition des données et les opérations ensemble, lisibles et vérifiées de manière exhaustive.

Machines à états

Les machines à états sont omniprésentes dans les logiciels : traitement des commandes, moteurs de flux de travail, gestion des connexions, état de l’interface utilisateur. Les syndicats les rendent explicites et sûrs :

union ConnectionState
{
 Disconnected,
 Connecting(string Host, int Port, DateTime StartedAt),
 Connected(string Host, int Port, TcpClient Client),
 Reconnecting(string Host, int Port, int Attempt, TimeSpan Delay),
 Failed(string Host, Exception Error)
}

ConnectionState HandleEvent(ConnectionState state, ConnectionEvent evt) => (state, evt) switch
{
 (Disconnected, Connect(var host, var port)) =>
 new Connecting(host, port, DateTime.UtcNow),

 (Connecting(var h, var p, _), ConnectionSucceeded(var client)) =>
 new Connected(h, p, client),

 (Connecting(var h, var p, _), ConnectionFailed(var ex)) =>
 new Reconnecting(h, p, Attempt: 1, Delay: TimeSpan.FromSeconds(1)),

 (Reconnecting(var h, var p, var attempt, _), ConnectionSucceeded(var client)) =>
 new Connected(h, p, client),

 (Reconnecting(var h, var p, var attempt, _), ConnectionFailed(var ex)) when attempt >= 5 =>
 new Failed(h, ex),

 (Reconnecting(var h, var p, var attempt, _), ConnectionFailed(_)) =>
 new Reconnecting(h, p, attempt + 1, TimeSpan.FromSeconds(Math.Pow(2, attempt))),

 (Connected(_, _, var client), Disconnect) =>
 new Disconnected,

 _ => state // Ignore events that don't apply to current state
};

Chaque état contient exactement les données pertinentes pour cet état. Vous ne pouvez pas accéder accidentellement à un TcpClient lorsque vous êtes dans l’état Connecting car il n’existe pas sur cette variante. Le système de types applique les invariants de la machine à états.

Considérations sur la sérialisation et l’interopérabilitéL’une des questions pratiques qui se posent immédiatement avec les types d’unions est la suivante : comment les sérialiser ? Si vous créez des API ou stockez des données, vous avez besoin de la sérialisation JSON pour fonctionner correctement.

L’équipe de conception a discuté de la prise en charge intégrée de System.Text.Json pour les types d’union. L’approche attendue consiste à sérialiser avec une propriété discriminante :

{
 "$type": "Circle",
 "radius": 5.0
}

{
 "$type": "Rectangle",
 "width": 10.0,
 "height": 20.0
}

Ceci est cohérent avec la prise en charge de la sérialisation polymorphe existante introduite dans .NET 7 avec les attributs JsonDerivedType. On s’attend à ce que les syndicats travaillent avec System.Text.Json dès le départ, en utilisant le nom de la variante comme discriminateur de type par défaut.

Pour Entity Framework Core, l’approche probable consiste à stocker les valeurs d’union à l’aide d’une colonne discriminatrice, de la même manière que le mappage d’héritage table par hiérarchie (TPH) fonctionne déjà. L’intégration exacte d’EF Core est encore en cours de conception, mais l’infrastructure permettant de gérer les hiérarchies de types fermées existe déjà.

Il convient de noter que l’interopérabilité avec d’autres langages .NET devrait être fluide, puisque les unions se compileront sous le capot selon des hiérarchies de classes IL standard. Le code F# consommant une union C# le verrait comme une hiérarchie de types standard, et vice versa.

Comment l’essayer

Au moment de la rédaction de cet article, les types d’union sont disponibles en tant que fonctionnalité d’aperçu dans les dernières versions d’aperçu du SDK .NET. Pour expérimenter la syntaxe proposée, vous devrez :

Installez le dernier SDK de prévisualisation .NET
Activez la version linguistique d’aperçu dans votre fichier de projet :

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <LangVersion>preview</LangVersion>
 </PropertyGroup>
</Project>

Gardez à l’esprit que les fonctionnalités d’aperçu sont susceptibles de changer. La syntaxe, le comportement et les diagnostics du compilateur peuvent évoluer considérablement avant la version finale. Ne livrez pas de code de production en s’appuyant sur les fonctionnalités du langage d’aperçu, mais expérimentez-les absolument et fournissez vos commentaires. L’équipe C# surveille activement les discussions sur le référentiel csharplang.

Si vous souhaitez suivre l’avancée de la proposition, les principaux endroits à surveiller sont :

Le référentiel dotnet/csharplang pour les discussions sur la conception du langage
Le référentiel dotnet/roslyn pour la progression de l’implémentation du compilateur
Le blog .NET pour les annonces officielles

Comparaison avec les approches existantes

Permettez-moi de faire une comparaison rapide afin que vous puissiez voir comment les différentes approches se comparent :

Fonctionnalité	Dossiers abstraits	UnDe<T1,T2>	Énumération + Données	Types de syndicats
Vérification de l’exhaustivité	❌ Non	✅ Oui	❌ Non	✅ Oui
Correspondance de motifs	✅ Oui	❌ Limité	❌ Manuel	✅Autochtone
Fermeture imposée par le compilateur	❌ Non	✅ Oui	❌ Non	✅ Oui
Données par variante	✅ Oui	✅ Oui	⚠️Fragile	✅ Oui
Lisibilité	⚠️ Verbeux	⚠️ Positionnel	❌ Pauvre	✅Excellent
Sérialisation	✅ Manuel	⚠️ Complexe	✅ Manuel	✅ Intégré
Passe-partout	⚠️ Modéré	✅ Faible	⚠️ Élevé	✅ Minime
Aucune dépendance externe	✅ Oui	❌ NuGet	✅ Oui	✅ Oui

Ce que cela signifie pour l’écosystème .NET

L’introduction de syndicats discriminés aura des répercussions sur l’ensemble de l’écosystème .NET. Voici ce que je m’attends à voir :

La conception de la bibliothèque sera améliorée. Les API qui renvoient actuellement null pour indiquer « introuvable » ou lèvent des exceptions en cas d’échec de validation pourront renvoyer des types Result<T, E> à la place. Cela rend les modes de défaillance explicites dans la signature de type : vous pouvez voir ce qui peut mal se passer en examinant la signature de la méthode, et non en lisant la documentation ou le code source.

La modélisation du domaine devient plus expressive. L’écart entre le domaine problématique et la représentation du code se réduit considérablement. Lorsque votre expert en domaine dit « un paiement peut être une carte de crédit, un virement bancaire ou un paiement à la livraison », vous pouvez modéliser cela directement comme une union plutôt que de le traduire dans une hiérarchie d’héritage.

Les idées F# deviennent accessibles aux développeurs C#. De nombreux développeurs C# ont admiré de loin le système de types F#, mais n’ont pas été en mesure d’adopter F# dans leur organisation. Les types Union apportent l’une des fonctionnalités les plus puissantes de F# à C#, ce qui constitue une victoire pour l’ensemble de l’écosystème .NET.

Moins d’erreurs d’exécution. La vérification de l’exhaustivité à elle seule empêchera des catégories entières de bugs. Chaque fois que vous ajoutez une nouvelle variante à une union, le compilateur vous guidera vers chaque endroit de la base de code qui nécessite une mise à jour. Fini les cas switch oubliés, plus de NotImplementedException dans les branches par défaut qui n’apparaissent qu’en production.

Conclusion

Les syndicats discriminés figurent en tête de la liste de souhaits de la communauté C# depuis près d’une décennie, et pour cause. Ils comblent une lacune fondamentale du système de types : la capacité de modéliser des données qui peuvent être « une chose parmi plusieurs » avec la sécurité renforcée par le compilateur.

Le mot-clé union proposé apporte une syntaxe claire et concise qui s’intègre profondément à la correspondance de modèles de C#, fonctionne avec des génériques, prend en charge les méthodes et les interfaces et permet une vérification exhaustive qui détecte les bogues au moment de la compilation plutôt qu’à l’exécution.

Que vous construisiez des modèles de domaine, conceviez des API avec des types d’erreur explicites, implémentiez des machines à états ou essayiez simplement de remplacer des hiérarchies d’héritage délicates par quelque chose de plus naturel, les types d’union vont changer la façon dont vous écrivez C#.

Nous attendons cela depuis longtemps. La syntaxe est élégante, l’intégration avec les fonctionnalités du langage existant est réfléchie et l’impact pratique se fera sentir dans l’ensemble de l’écosystème .NET.

Gardez un œil sur les versions préliminaires, expérimentez la fonctionnalité et faites part de vos commentaires à l’équipe de conception du langage. C’est une de ces fonctionnalités qui, une fois que vous l’aurez utilisée, vous vous demanderez comment vous avez pu vivre sans elle.

Construire un système RAG en C# avec Semantic Kernel

Wed, 18 Mar 2026 00:00:00 +0000

##Présentation

Si vous avez essayé d’utiliser un LLM pour répondre à des questions sur vos propres données (documents d’entreprise, spécifications de produits, bases de connaissances internes), vous avez probablement remarqué qu’il hallucine ou dit simplement « Je n’ai aucune information à ce sujet ». C’est parce que le modèle sait seulement sur quoi il a été formé.

RAG (Retrieval-Augmented Generation) corrige ce problème. Au lieu d’affiner un modèle sur vos données, vous récupérez des morceaux pertinents de vos documents au moment de la requête et les transmettez au LLM en tant que contexte. Le modèle génère ensuite des réponses fondées sur vos données réelles.

Dans cet article, je vais vous guider dans la création d’un pipeline RAG complet en C# à l’aide du noyau sémantique.

Comment fonctionne RAG

Le déroulement est simple :

Ingérer : divisez vos documents en morceaux, générez des intégrations pour chaque morceau, stockez-les dans une base de données vectorielle
Requête : lorsqu’un utilisateur pose une question, générez une intégration pour la requête, recherchez dans la base de données vectorielles des morceaux similaires.
Générer : transmettez les morceaux récupérés comme contexte au LLM avec la question de l’utilisateur

C’est tout. La magie réside dans les intégrations : elles capturent la signification sémantique du texte sous forme de vecteurs, afin que vous puissiez trouver un contenu pertinent même lorsque les mots exacts ne correspondent pas.

Prérequis

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Connectors.AzureOpenAI
dotnet add package Microsoft.Extensions.VectorData.Abstractions
dotnet add package Microsoft.SemanticKernel.Connectors.InMemory

Pour la production, vous remplaceriez le magasin en mémoire par Azure AI Search, Qdrant, Pinecone ou toute autre base de données vectorielles prise en charge. Mais la mémoire en mémoire est parfaite pour l’apprentissage et le prototypage.

Configuration du noyau

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.AzureOpenAI;
using Microsoft.Extensions.VectorData;
using Microsoft.SemanticKernel.Connectors.InMemory;
using Microsoft.SemanticKernel.Embeddings;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"]);

builder.AddAzureOpenAITextEmbeddingGeneration(
 deploymentName: "text-embedding-3-small",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"]);

var kernel = builder.Build();

Nous avons besoin de deux modèles : un pour terminer le chat (répondre aux questions) et un pour générer des intégrations (transformer le texte en vecteurs).

Définir le modèle de données

Nous avons besoin d’une classe pour représenter nos morceaux de documents dans le magasin de vecteurs :

using Microsoft.Extensions.VectorData;

public class DocumentChunk
{
 [VectorStoreRecordKey]
 public string Id { get; set; } = Guid.NewGuid().ToString();

 [VectorStoreRecordData]
 public string Content { get; set; } = string.Empty;

 [VectorStoreRecordData]
 public string Source { get; set; } = string.Empty;

 [VectorStoreRecordData]
 public int ChunkIndex { get; set; }

 [VectorStoreRecordVector(1536)]
 public ReadOnlyMemory<float> Embedding { get; set; }
}

L’attribut VectorStoreRecordVector(1536) indique au magasin de vecteurs la dimension de nos intégrations. Le modèle text-embedding-3-small produit des vecteurs à 1 536 dimensions.

## Regrouper des documents

Avant de pouvoir créer des intégrations, nous devons diviser nos documents en morceaux gérables. Voici un simple séparateur de texte :

public static class TextChunker
{
 public static List<string> SplitText(string text, int maxChunkSize = 500, int overlap = 50)
 {
 var chunks = new List<string>();
 var paragraphs = text.Split("\n\n", StringSplitOptions.RemoveEmptyEntries);
 var currentChunk = new System.Text.StringBuilder();

 foreach (var paragraph in paragraphs)
 {
 if (currentChunk.Length + paragraph.Length > maxChunkSize && currentChunk.Length > 0)
 {
 chunks.Add(currentChunk.ToString().Trim());

 // Keep overlap from the end of the previous chunk
 var overlapText = currentChunk.ToString();
 currentChunk.Clear();
 if (overlapText.Length > overlap)
 {
 currentChunk.Append(overlapText[^overlap..]);
 currentChunk.Append(' ');
 }
 }

 currentChunk.Append(paragraph);
 currentChunk.Append("\n\n");
 }

 if (currentChunk.Length > 0)
 {
 chunks.Add(currentChunk.ToString().Trim());
 }

 return chunks;
 }
}

Le chevauchement est important : il garantit que le contexte à la frontière entre les morceaux n’est pas perdu. Si une phrase pertinente est divisée en deux morceaux, le chevauchement signifie qu’elle apparaîtra entièrement dans au moins l’un d’entre eux.

Ingestion de documents

Maintenant, rassemblons tout cela pour ingérer des documents dans notre magasin de vecteurs :

var vectorStore = new InMemoryVectorStore();
var collection = vectorStore.GetCollection<string, DocumentChunk>("documents");
await collection.CreateCollectionIfNotExistsAsync();

var embeddingService = kernel.GetRequiredService<ITextEmbeddingGenerationService>();

async Task IngestDocument(string content, string source)
{
 var chunks = TextChunker.SplitText(content);

 for (int i = 0; i < chunks.Count; i++)
 {
 var embedding = await embeddingService.GenerateEmbeddingAsync(chunks[i]);

 var chunk = new DocumentChunk
 {
 Content = chunks[i],
 Source = source,
 ChunkIndex = i,
 Embedding = embedding
 };

 await collection.UpsertAsync(chunk);
 }

 Console.WriteLine($"✅ Ingested {chunks.Count} chunks from {source}");
}

// Ingest some documents
var doc1 = await File.ReadAllTextAsync("docs/product-guide.md");
var doc2 = await File.ReadAllTextAsync("docs/faq.md");
var doc3 = await File.ReadAllTextAsync("docs/troubleshooting.md");

await IngestDocument(doc1, "product-guide.md");
await IngestDocument(doc2, "faq.md");
await IngestDocument(doc3, "troubleshooting.md");

Recherche de morceaux pertinents

Lorsqu’un utilisateur pose une question, nous générons une intégration pour sa requête et recherchons des morceaux similaires :

async Task<List<DocumentChunk>> SearchAsync(string query, int topK = 3)
{
 var queryEmbedding = await embeddingService.GenerateEmbeddingAsync(query);

 var searchResults = await collection.VectorizedSearchAsync(
 queryEmbedding,
 new VectorSearchOptions { Top = topK });

 var results = new List<DocumentChunk>();
 await foreach (var result in searchResults.Results)
 {
 results.Add(result.Record);
 }

 return results;
}

Générer des réponses avec le contexte

Passons maintenant à la partie RAG : nous prenons les morceaux récupérés et les incluons comme contexte dans notre invite :

using Microsoft.SemanticKernel.ChatCompletion;

var chatService = kernel.GetRequiredService<IChatCompletionService>();

async Task<string> AskAsync(string question)
{
 // Step 1: Retrieve relevant chunks
 var relevantChunks = await SearchAsync(question);

 // Step 2: Build context from chunks
 var context = string.Join("\n\n---\n\n",
 relevantChunks.Select(c => $"[Source: {c.Source}]\n{c.Content}"));

 // Step 3: Generate answer with context
 var history = new ChatHistory();
 history.AddSystemMessage($$"""
 You are a helpful assistant that answers questions based on the provided context.
 Use ONLY the information from the context to answer. If the context doesn't contain
 enough information to answer the question, say "I don't have enough information
 to answer that question."

 Do not make up information. Always cite the source document when possible.

 Context:
 {{context}}
 """);

 history.AddUserMessage(question);

 var response = await chatService.GetChatMessageContentAsync(history);
 return response.Content ?? "No response generated.";
}

L’utiliser

// Ask questions about your documents
var answer1 = await AskAsync("How do I reset my password?");
Console.WriteLine($"Q: How do I reset my password?\nA: {answer1}\n");

var answer2 = await AskAsync("What are the system requirements?");
Console.WriteLine($"Q: What are the system requirements?\nA: {answer2}\n");

var answer3 = await AskAsync("What's the capital of France?");
Console.WriteLine($"Q: What's the capital of France?\nA: {answer3}\n");
// Should respond with "I don't have enough information" since it's not in the docs

Passage en production

Le magasin de vecteurs en mémoire est idéal pour le prototypage, mais pour la production, vous aurez besoin d’une base de données de vecteurs persistante. Le noyau sémantique dispose de connecteurs pour plusieurs options :

# Azure AI Search
dotnet add package Microsoft.SemanticKernel.Connectors.AzureAISearch

# Qdrant
dotnet add package Microsoft.SemanticKernel.Connectors.Qdrant

# Redis
dotnet add package Microsoft.SemanticKernel.Connectors.Redis

L’échange est simple puisqu’ils implémentent tous la même interface IVectorStore :

// Instead of InMemoryVectorStore, use:
using Azure;
using Microsoft.SemanticKernel.Connectors.AzureAISearch;

var vectorStore = new AzureAISearchVectorStore(
 new Azure.Search.Documents.Indexes.SearchIndexClient(
 new Uri(config["AzureAISearch:Endpoint"]),
 new AzureKeyCredential(config["AzureAISearch:ApiKey"])));
```Tout le reste reste pareil. C'est la beauté de l'abstraction.

## Conseils pour la création de systèmes RAG

Quelques choses que j'ai apprises à mes dépens :

- **La taille des morceaux compte beaucoup.** Trop petite et vous perdez le contexte. Trop volumineux et vous gaspillez des jetons sur du contenu non pertinent. Commencez avec 500 à 800 jetons et ajustez en fonction de vos données.
- **Le chevauchement évite les problèmes de limites.** Un chevauchement de 50 à 100 jetons entre les morceaux est généralement suffisant.
- **Récupérez plus que vous ne le pensez.** Commencez par `topK = 5` et réduisez si vous obtenez trop de bruit. Il est préférable d'avoir un contexte supplémentaire plutôt que de manquer le morceau pertinent.
- **Les invites système sont cruciales.** Soyez très explicite sur l'utilisation uniquement du contexte fourni. Sans cette instruction, le modèle hallucinera volontiers « sur la base de ses données d’entraînement ».
- **Suivez les sources.** Stockez toujours les métadonnées avec vos morceaux afin de pouvoir citer d'où vient la réponse. Les utilisateurs font davantage confiance aux réponses lorsqu’ils peuvent vérifier la source.
- **Reclassez si nécessaire.** La similarité des vecteurs n'est pas parfaite. Pour les applications critiques, ajoutez une étape de reclassement à l’aide d’un modèle multi-encodeur pour améliorer la précision.

## Conclusion

RAG est actuellement l’un des modèles les plus pratiques en IA. Il vous permet de créer des systèmes de questions-réponses basés sur l'IA sur vos propres données sans réglage fin, et Semantic Kernel le rend étonnamment propre en C#. Commencez par le magasin en mémoire, obtenez votre segmentation et vos invites correctes, puis échangez dans une véritable base de données vectorielles lorsque vous êtes prêt pour la production.

Bon codage !

## Ressources

- [Documentation du magasin de vecteurs du noyau sémantique](https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/)
- [Modèle RAG avec Azure AI Search](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview)
- [Modèles d'intégration de texte](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models#embeddings)

Création de flux de travail d'agent avec Microsoft Agent Framework

Tue, 10 Feb 2026 00:00:00 +0000

##Présentation

Si vous avez lu mes articles précédents sur Agent Framework de Microsoft, vous savez comment créer des agents individuels et même des discussions de groupe multi-agents. Mais dans les scénarios du monde réel, vous avez souvent besoin de quelque chose de plus structuré : un flux de travail dans lequel les agents s’exécutent dans un ordre spécifique, se transmettent les résultats et gèrent la logique de branchement en fonction des résultats.

C’est exactement ce que vous offrent les fonctionnalités de flux de travail d’Agent Framework. Au lieu de lancer des agents dans une discussion de groupe en espérant qu’ils comprendront, vous définissez des étapes explicites, des dépendances et un flux de données entre les agents.

Que sont les workflows des agents ?

Considérez les flux de travail des agents comme un pipeline. Chaque étape est gérée par un agent spécialisé et le résultat d’une étape alimente la suivante. Vous pouvez exécuter des étapes de manière séquentielle, en parallèle ou conditionnellement en fonction des résultats.

Quelques exemples :

Pipeline de contenu : Recherche → Brouillon → Révision → Publier
Traitement des données : Extraire → Transformer → Valider → Charger
Support client : Classer → Itinéraire → Répondre → Suivi

Prérequis

Assurez-vous de disposer des derniers packages Agent Framework :

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Agents.Core

Et un point de terminaison Azure OpenAI ou OpenAI configuré.

Créer un workflow séquentiel

Créons un workflow de création de contenu avec trois agents : un chercheur, un rédacteur et un éditeur.

Définir les agents

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;

var kernel = Kernel.CreateBuilder()
 .AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: config["AzureOpenAI:Endpoint"],
 apiKey: config["AzureOpenAI:ApiKey"])
 .Build();

var researcher = new ChatCompletionAgent
{
 Name = "Researcher",
 Instructions = """
 You are a research specialist. Given a topic, find key facts, statistics,
 and talking points. Return a structured research brief with bullet points.
 Be thorough but concise.
 """,
 Kernel = kernel
};

var writer = new ChatCompletionAgent
{
 Name = "Writer",
 Instructions = """
 You are a technical blog writer. Given a research brief, write a clear
 and engaging blog post. Use a conversational tone, include code examples
 where relevant, and structure the post with clear headings.
 """,
 Kernel = kernel
};

var editor = new ChatCompletionAgent
{
 Name = "Editor",
 Instructions = """
 You are a senior editor. Review the blog post for clarity, accuracy,
 grammar, and flow. Return the corrected version with a summary of
 changes made at the end.
 """,
 Kernel = kernel
};

Exécution séquentielle

Le workflow le plus simple est séquentiel : chaque agent traite le résultat du précédent :

using Microsoft.SemanticKernel.Agents.Chat;
using Microsoft.SemanticKernel.ChatCompletion;

async Task<string> RunSequentialWorkflow(string topic)
{
 var history = new ChatHistory();
 string currentInput = $"Research the following topic: {topic}";

 var agents = new[] { researcher, writer, editor };

 foreach (var agent in agents)
 {
 history.AddUserMessage(currentInput);

 var response = new System.Text.StringBuilder();
 await foreach (var message in agent.InvokeAsync(history))
 {
 response.Append(message.Content);
 }

 currentInput = response.ToString();
 Console.WriteLine($"✅ {agent.Name} completed");
 }

 return currentInput;
}

var result = await RunSequentialWorkflow("Blazor render modes in .NET 9");
Console.WriteLine(result);

Chaque agent récupère le contexte accumulé, le traite et le résultat passe à l’étape suivante.

Exécution parallèle

Parfois, les agents peuvent travailler de manière indépendante. Par exemple, vous souhaiterez peut-être rechercher plusieurs sous-thèmes en même temps :

async Task<List<string>> RunParallelResearch(string[] topics)
{
 var tasks = topics.Select(async topic =>
 {
 var history = new ChatHistory();
 history.AddUserMessage($"Research: {topic}");

 var response = new System.Text.StringBuilder();
 await foreach (var message in researcher.InvokeAsync(history))
 {
 response.Append(message.Content);
 }

 Console.WriteLine($"✅ Research completed: {topic}");
 return response.ToString();
 });

 var results = await Task.WhenAll(tasks);
 return results.ToList();
}

var topics = new[]
{
 "Blazor SSR streaming",
 "Enhanced navigation in .NET 9",
 "Render mode boundaries"
};

var briefs = await RunParallelResearch(topics);

Ensuite, vous pouvez transmettre tous les résumés de recherche à un seul agent rédacteur pour produire un article cohérent.

Branchement conditionnel

Les vrais flux de travail nécessitent des décisions. Peut-être souhaitez-vous une étape de contrôle de qualité qui renvoie à l’auteur si le message n’est pas assez bon :

var qualityChecker = new ChatCompletionAgent
{
 Name = "QualityChecker",
 Instructions = """
 You are a quality assurance reviewer. Evaluate the blog post on:
 1. Technical accuracy
 2. Clarity and readability
 3. Completeness

 Respond with either:
 - "APPROVED" if the post meets all criteria
 - "REVISION NEEDED: [specific feedback]" if changes are required

 Be strict. Only approve posts that are truly ready to publish.
 """,
 Kernel = kernel
};

async Task<string> RunWithQualityLoop(string topic, int maxRevisions = 3)
{
 var history = new ChatHistory();

 // Step 1: Research
 history.AddUserMessage($"Research: {topic}");
 string research = await InvokeAgent(researcher, history);

 // Step 2: Write
 history.AddUserMessage(research);
 string draft = await InvokeAgent(writer, history);

 // Step 3: Quality loop
 for (int i = 0; i < maxRevisions; i++)
 {
 var qaHistory = new ChatHistory();
 qaHistory.AddUserMessage($"Review this post:\n\n{draft}");
 string qaResult = await InvokeAgent(qualityChecker, qaHistory);

 if (qaResult.Contains("APPROVED", StringComparison.OrdinalIgnoreCase))
 {
 Console.WriteLine($"✅ Approved after {i + 1} review(s)");
 return draft;
 }

 Console.WriteLine($"🔄 Revision {i + 1}: {qaResult[..Math.Min(100, qaResult.Length)]}...");

 // Send back to writer with feedback
 history.AddUserMessage($"Please revise based on this feedback:\n{qaResult}");
 draft = await InvokeAgent(writer, history);
 }

 Console.WriteLine("⚠️ Max revisions reached, returning latest draft");
 return draft;
}

async Task<string> InvokeAgent(ChatCompletionAgent agent, ChatHistory history)
{
 var response = new System.Text.StringBuilder();
 await foreach (var message in agent.InvokeAsync(history))
 {
 response.Append(message.Content);
 }
 return response.ToString();
}

Ce modèle est super utile. Le vérificateur de qualité agit comme une porte et le flux de travail boucle jusqu’à ce que le résultat soit suffisamment bon ou atteigne la limite de révision maximale.

Ajout de plugins aux agents de workflow

Les agents des workflows peuvent utiliser des plugins tout comme les agents autonomes. C’est là que les choses deviennent vraiment puissantes : les agents peuvent appeler des API, interroger des bases de données ou effectuer des opérations sur les fichiers dans le cadre de leur étape de flux de travail :

var researcherWithTools = new ChatCompletionAgent
{
 Name = "Researcher",
 Instructions = "Research the topic using available tools. Summarize findings.",
 Kernel = kernel
};

// Add a web search plugin
kernel.Plugins.AddFromType<WebSearchPlugin>();

// Add a database plugin
kernel.Plugins.AddFromObject(new DatabasePlugin(connectionString), "Database");

public class WebSearchPlugin
{
 [KernelFunction, Description("Search the web for information")]
 public async Task<string> SearchAsync(
 [Description("The search query")] string query)
 {
 // Your search implementation
 using var httpClient = new HttpClient();
 var response = await httpClient.GetStringAsync(
 $"https://api.search.example.com?q={Uri.EscapeDataString(query)}");
 return response;
 }
}

Gestion des erreurs dans les workflows

Lorsque vous enchaînez plusieurs agents, la gestion des erreurs devient critique. Vous ne voulez pas qu’une étape échouée fasse planter l’ensemble du flux de travail en silence :

async Task<WorkflowResult> RunResilientWorkflow(string input)
{
 var result = new WorkflowResult();

 try
 {
 result.Research = await InvokeAgent(researcher, new ChatHistory(input));
 }
 catch (Exception ex)
 {
 result.Errors.Add($"Research failed: {ex.Message}");
 return result;
 }

 try
 {
 var writeHistory = new ChatHistory(result.Research);
 result.Draft = await InvokeAgent(writer, writeHistory);
 }
 catch (Exception ex)
 {
 result.Errors.Add($"Writing failed: {ex.Message}");
 result.Draft = result.Research; // Fallback to research output
 }

 result.Success = result.Errors.Count == 0;
 return result;
}

class WorkflowResult
{
 public string Research { get; set; } = "";
 public string Draft { get; set; } = "";
 public List<string> Errors { get; set; } = new();
 public bool Success { get; set; }
}

## Bonnes pratiques

Après avoir créé plusieurs workflows d’agent, voici ce que j’ai appris :- Gardez les instructions des agents concentrées : chaque agent doit bien faire une chose. N’essayez pas de faire un agent couteau suisse.

Limiter le contexte : ne transmettez pas l’intégralité de l’historique des conversations à chaque agent. Donnez à chaque étape uniquement ce dont elle a besoin.
Définissez des limites de révision — les boucles de qualité sont excellentes mais peuvent s’exécuter indéfiniment si vous ne faites pas attention. Ayez toujours un plafond d’itérations maximum.
Tout enregistrer : les résultats de l’agent peuvent être imprévisibles. Enregistrez les entrées et sorties de chaque étape pour le débogage.
Utilisez judicieusement l’exécution parallèle : cela accélère les choses, mais surveillez les limites de débit de votre API et les coûts des jetons.
Testez d’abord avec des modèles plus petits : développez et testez votre logique de flux de travail avec GPT-3.5 avant de passer à GPT-4o pour la production.

Conclusion

Les workflows d’agent vous permettent de créer des pipelines d’IA complexes en plusieurs étapes dans lesquels chaque agent est un spécialiste. Commencez par des flux de travail séquentiels, ajoutez une exécution parallèle où les étapes sont indépendantes et utilisez le branchement conditionnel pour les contrôles de qualité. Les modèles sont composables : une fois que vous avez compris, vous pouvez créer une automatisation assez sophistiquée.

Bon codage !

Ressources

Cycle de vie des composants Blazor : le guide complet

Thu, 15 Jan 2026 00:00:00 +0000

J’utilise Blazor depuis un moment maintenant et honnêtement, les méthodes de cycle de vie m’ont dérouté au début. OnInitialized contre OnInitializedAsync ? OnParametersSet contre OnAfterRender ? Quand StateHasChanged déclenche-t-il réellement un nouveau rendu ? Après de nombreux essais et erreurs, j’ai enfin un modèle mental solide pour tout cela.

Le cycle de vie en un coup d’œil

Lorsqu’un composant Blazor est rendu, il utilise ces méthodes dans l’ordre :

SetParametersAsync
OnInitialized / OnInitializedAsync
OnParametersSet / OnParametersSetAsync
OnAfterRender / OnAfterRenderAsync
Dispose / DisposeAsync

Passons en revue chacun d’entre eux.

SetParametersAsync

C’est la toute première méthode appelée. Il reçoit le ParameterView brut du composant parent. La plupart du temps, vous ne remplacez pas cela – Blazor gère automatiquement les paramètres de mappage. Mais si vous avez besoin d’une gestion ou d’une validation de paramètres personnalisés avant leur attribution :

public override async Task SetParametersAsync(ParameterView parameters)
{
 // Custom logic before parameters are set
 if (parameters.TryGetValue<string>("Title", out var title))
 {
 Console.WriteLine($"Title is being set to: {title}");
 }

 await base.SetParametersAsync(parameters);
}

Je l’ai utilisé exactement une fois dans un vrai projet. La plupart du temps, vous l’ignorerez.

OnInitialized / OnInitializedAsync

C’est ici que vous effectuez votre travail de configuration : charger les données, initialiser les services, définir les valeurs par défaut. Il s’exécute une fois lors de la première création du composant.

@code {
 private List<Product> products = new();

 protected override async Task OnInitializedAsync()
 {
 products = await Http.GetFromJsonAsync<List<Product>>("api/products");
 }
}

Une chose qui m’a fait trébucher : dans Blazor Server, OnInitializedAsync est appelé deux fois lors du prérendu. La première fois lors du prérendu côté serveur et la deuxième fois lorsque la connexion SignalR est établie. Si votre appel API coûte cher, vous souhaiterez peut-être gérer cela :

private bool isPrerendering = true;

protected override async Task OnInitializedAsync()
{
 products = await Http.GetFromJsonAsync<List<Product>>("api/products");
 isPrerendering = false;
}

Ou encore mieux, utilisez PersistentComponentState pour éviter complètement le double appel.

OnParametersSet / OnParametersSetAsync

Cela se déclenche chaque fois que le composant parent effectue un nouveau rendu et transmet de nouvelles valeurs de paramètres. Il se déclenche également après OnInitialized. C’est le bon endroit pour réagir aux changements de paramètres :

[Parameter]
public int CategoryId { get; set; }

private int previousCategoryId;
private List<Product> products = new();

protected override async Task OnParametersSetAsync()
{
 if (CategoryId != previousCategoryId)
 {
 previousCategoryId = CategoryId;
 products = await Http.GetFromJsonAsync<List<Product>>(
 $"api/products?category={CategoryId}");
 }
}

La vérification de CategoryId != previousCategoryId est importante : sans elle, vous rechargeriez les données à chaque fois que le parent effectue un nouveau rendu, même si la catégorie n’a pas changé.

OnAfterRender / OnAfterRenderAsync

Cela se déclenche après le rendu du composant dans le DOM. Le paramètre firstRender vous indique s’il s’agit du rendu initial. C’est l’endroit idéal pour les appels JS Interop puisque les éléments DOM existent à ce stade :

[Inject]
private IJSRuntime JS { get; set; }

protected override async Task OnAfterRenderAsync(bool firstRender)
{
 if (firstRender)
 {
 await JS.InvokeVoidAsync("initializeChart", chartElement);
 }
}

J’utilise beaucoup firstRender pour éviter de réinitialiser les bibliothèques JavaScript à chaque nouveau rendu. Si vous configurez des écouteurs d’événements, des bibliothèques de graphiques ou tout ce qui touche directement le DOM, c’est ici que cela se passe.

DevraitRender

Celui-ci est moins connu mais super utile. Il contrôle si un composant est restitué lorsque StateHasChanged est appelé :

private bool shouldRender = true;

protected override bool ShouldRender() => shouldRender;

private void HeavyOperation()
{
 shouldRender = false;

 // Do a bunch of state changes without triggering renders
 for (int i = 0; i < 1000; i++)
 {
 items[i].Process();
 }

 shouldRender = true;
 StateHasChanged(); // Now render once with all changes
}

Je l’ai utilisé pour optimiser les composants qui traitent de grandes listes. Au lieu de refaire le rendu à chaque modification d’élément, vous regroupez les mises à jour et effectuez le rendu une fois à la fin.

Dispose / DisposeAsync

Lorsqu’un composant est supprimé de l’interface utilisateur, vous devez nettoyer toutes les ressources. Implémentez IDisposable ou IAsyncDisposable :

@implements IAsyncDisposable

@code {
 private Timer? timer;
 private IJSObjectReference? jsModule;

 protected override void OnInitialized()
 {
 timer = new Timer(OnTick, null, 0, 1000);
 }

 protected override async Task OnAfterRenderAsync(bool firstRender)
 {
 if (firstRender)
 {
 jsModule = await JS.InvokeAsync<IJSObjectReference>("import", "./timer.js");
 }
 }

 public async ValueTask DisposeAsync()
 {
 timer?.Dispose();

 if (jsModule is not null)
 {
 await jsModule.DisposeAsync();
 }
 }
}

Éléments courants à éliminer : minuteries, abonnements à des événements, références de modules JS, CancellationTokenSource et tous les services IDisposable que vous avez créés.

ÉtatHasChangedIl ne s’agit pas d’une méthode de cycle de vie, mais elle est étroitement liée. Il dit à Blazor “hé, mon état a changé, s’il te plaît, restitue-moi.” Blazor l’appelle automatiquement après les gestionnaires d’événements, mais vous devez parfois l’appeler manuellement - généralement lorsque l’état change en dehors du flux d’événements Blazor normal :

private async Task StartPolling()
{
 while (!cts.Token.IsCancellationRequested)
 {
 data = await Http.GetFromJsonAsync<Data>("api/data");
 StateHasChanged(); // Manual call needed since this isn't a Blazor event
 await Task.Delay(5000, cts.Token);
 }
}

Une remarque importante : si vous effectuez une mise à jour à partir d’un thread en arrière-plan dans Blazor Server, utilisez InvokeAsync :

await InvokeAsync(() =>
{
 data = newData;
 StateHasChanged();
});

L’image complète

Voici l’ordre dans lequel tout se passe :

Component created
 └─ SetParametersAsync
 └─ OnInitialized / OnInitializedAsync
 └─ OnParametersSet / OnParametersSetAsync
 └─ Render
 └─ OnAfterRender(firstRender: true)

Parameter change from parent
 └─ SetParametersAsync
 └─ OnParametersSet / OnParametersSetAsync
 └─ ShouldRender?
 └─ Render
 └─ OnAfterRender(firstRender: false)

Component removed
 └─ Dispose / DisposeAsync

Une fois que vous avez ce flux en tête, le débogage des problèmes de cycle de vie devient beaucoup plus facile.

J’espère que vous avez aimé le message ! N’hésitez pas à me contacter sur tous les réseaux sociaux à @emimontesdeoca.

Ressources

Agent Framework de Microsoft pour sauver Noël

Tue, 16 Dec 2025 00:00:00 +0000

##Présentation

Trouver les cadeaux de Noël parfaits peut être stressant. Entre le brainstorming d’idées cadeaux, la comparaison des prix dans les magasins et le fait de s’assurer que tout arrive à temps, le magasinage des Fêtes devient rapidement écrasant. Et si nous pouvions déléguer ces tâches à des agents d’IA spécialisés qui travaillent ensemble ? Dans cet article, nous explorerons comment utiliser Agent Framework de Microsoft pour créer un système multi-agents dans lequel chaque agent se spécialise dans une tâche spécifique, de la génération d’idées cadeaux à la comparaison des prix, le tout coordonné via des flux de travail.

Calendrier technologique festif 2025

Ce projet fait partie de ma session au Festive Tech Calendar 2025, un incroyable événement communautaire célébrant la technologie pendant la période des fêtes. Vous pouvez en savoir plus sur l’événement sur Sessionize.

Qu’est-ce que l’Agent Framework de Microsoft ?

Agent Framework est la solution de Microsoft pour créer, orchestrer et déployer des agents IA et des systèmes multi-agents. Il fournit une base flexible pour créer des agents pouvant travailler de manière séquentielle, simultanée ou via des modèles de transfert. Le framework prend en charge les modèles OpenAI, Azure OpenAI et Microsoft Foundry, ce qui le rend incroyablement polyvalent.

Les principales fonctionnalités incluent :

Orchestration multi-agents : discussions de groupe, modèles séquentiels, simultanés et de transfert
Écosystème de plugins : extension avec des fonctions natives, OpenAPI et Model Context Protocol (MCP)
Support de workflow : créez des pipelines d’agents complexes avec des exécuteurs et des dispositifs Edge

Prérequis

Avant de plonger dans le code, assurez-vous d’avoir :

-.NET 9

Accès Azure OpenAI (ou clé API OpenAI)
Visual Studio ou Visual Studio Code

Installez les packages requis (notez que l’indicateur --prerelease est requis en version préliminaire) :

dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
dotnet add package Microsoft.Agents.AI.Workflows --prerelease
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity
dotnet add package Azure.AI.Agents.Persistent --prerelease

Les agents d’achat de cadeaux

Notre chercheur de cadeaux de Noël sera composé de trois agents spécialisés travaillant ensemble :

Gift Idea Agent - Génère des suggestions de cadeaux créatives en fonction du profil du destinataire
Agent de comparaison de prix - Trouve les meilleurs prix dans différents magasins
Agent de synthèse - Compile les recommandations finales

Les modèles

Commençons par définir nos modèles de données qui circuleront dans le pipeline des agents :

public class GiftRecipient
{
 public string Name { get; set; } = string.Empty;
 public int Age { get; set; }
 public List<string> Interests { get; set; } = [];
 public decimal Budget { get; set; }
}

public class GiftIdea
{
 public string Name { get; set; } = string.Empty;
 public string Description { get; set; } = string.Empty;
 public string Category { get; set; } = string.Empty;
 public decimal EstimatedPrice { get; set; }
}

public class PriceResult
{
 public string GiftName { get; set; } = string.Empty;
 public string Store { get; set; } = string.Empty;
 public decimal Price { get; set; }
 public string Url { get; set; } = string.Empty;
}

public class GiftRecommendation
{
 public GiftIdea Gift { get; set; } = new();
 public List<PriceResult> Prices { get; set; } = [];
 public PriceResult? BestDeal { get; set; }
}

Construire les agents

La beauté d’Agent Framework réside dans la facilité avec laquelle il est possible de créer des agents spécialisés. Chaque agent est simplement un ChatClientAgent avec une invite système spécifique qui définit son expertise.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Extensions.AI;

public static class ChristmasAgentFactory
{
 public static AIAgent CreateGiftIdeaAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a creative Christmas gift advisor. When given information about a person
 (age, interests, budget), you suggest thoughtful and personalized gift ideas.

 For each suggestion, provide:
 - Gift name
 - Brief description of why it's a good fit
 - Category (Electronics, Books, Fashion, Home, Experience, etc.)
 - Estimated price range

 Always suggest 3-5 gift options within the specified budget.
 Format your response as a structured list.");
 }

 public static AIAgent CreatePriceComparisonAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a price comparison specialist. Given a list of gift ideas,
 you research and compare prices from different online retailers.

 For each gift, provide:
 - Store name (Amazon, Best Buy, Target, Walmart, etc.)
 - Current price
 - Any available discounts or deals

 Always highlight the best deal for each item.
 Consider shipping costs and delivery times for Christmas.");
 }

 public static AIAgent CreateSummaryAgent(IChatClient chatClient)
 {
 return new ChatClientAgent(
 chatClient,
 @"You are a gift recommendation summarizer. Take the gift ideas and price
 comparisons and create a final recommendation report.

 Your summary should:
 - Rank gifts by value (quality vs price)
 - Highlight the top pick with reasoning
 - Include total cost estimate
 - Add any tips for holiday shopping

 Make the summary cheerful and festive!");
 }
}

Création du workflow

Vient maintenant la partie amusante : connecter nos agents dans un flux de travail séquentiel. Agent Framework fournit WorkflowBuilder et AgentWorkflowBuilder pour composer les agents selon différents modèles.

public static class ChristmasGiftWorkflow
{
 public static async Task RunAsync()
 {
 // Set up the Azure OpenAI client
 var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
 ?? throw new InvalidOperationException("AZURE_OPENAI_ENDPOINT is not set.");
 var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME")
 ?? "gpt-4o-mini";

 var chatClient = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsIChatClient();

 // Create our specialized agents
 AIAgent giftIdeaAgent = ChristmasAgentFactory.CreateGiftIdeaAgent(chatClient);
 AIAgent priceAgent = ChristmasAgentFactory.CreatePriceComparisonAgent(chatClient);
 AIAgent summaryAgent = ChristmasAgentFactory.CreateSummaryAgent(chatClient);

 // Build a sequential workflow: Ideas -> Prices -> Summary
 var workflow = AgentWorkflowBuilder.BuildSequential(
 "ChristmasGiftFinder",
 [giftIdeaAgent, priceAgent, summaryAgent]);

 // Define our gift recipient
 var recipient = new GiftRecipient
 {
 Name = "Mom",
 Age = 55,
 Interests = ["gardening", "cooking", "reading", "yoga"],
 Budget = 100
 };

 var prompt = $@"Find Christmas gifts for {recipient.Name},
 age {recipient.Age}, who enjoys {string.Join(", ", recipient.Interests)}.
 Budget: ${recipient.Budget}";

 // Execute the workflow with streaming
 await using StreamingRun run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, prompt));

 // Send the turn token to start processing
 await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

 // Watch for workflow events
 await foreach (WorkflowEvent evt in run.WatchStreamAsync())
 {
 if (evt is AgentRunUpdateEvent agentUpdate)
 {
 Console.Write(agentUpdate.Data);
 }
 else if (evt is WorkflowOutputEvent outputEvent)
 {
 Console.WriteLine("\n🎄 Final Recommendations:");
 Console.WriteLine(outputEvent.Data);
 }
 }
 }
}

Exécution d’agents simultanément

Que se passe-t-il si nous voulons rechercher des cadeaux pour plusieurs personnes à la fois ? Agent Framework prend en charge l’exécution simultanée, ce qui est parfait pour ce scénario :

public static async Task FindGiftsForEveryoneAsync(IChatClient chatClient, List<GiftRecipient> recipients)
{
 // Create an agent for each recipient
 var agents = recipients.Select(r => new ChatClientAgent(
 chatClient,
 $@"Find the perfect Christmas gift for {r.Name} (age {r.Age}),
 who loves {string.Join(", ", r.Interests)}. Budget: ${r.Budget}.
 Provide one well-researched recommendation with price."
 )).ToList();

 // Build a concurrent workflow - all agents run in parallel
 var workflow = AgentWorkflowBuilder.BuildConcurrent(
 "FamilyGiftFinder",
 agents);

 await using StreamingRun run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, "Find gifts now!"));

 await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

 await foreach (WorkflowEvent evt in run.WatchStreamAsync())
 {
 if (evt is WorkflowOutputEvent output)
 {
 Console.WriteLine("🎁 All gift recommendations ready!");
 Console.WriteLine(output.Data);
 }
 }
}

Exécuteurs personnalisés pour plus de contrôlePour des scénarios plus complexes, vous pouvez créer des exécuteurs personnalisés qui vous donnent un contrôle précis sur le flux de travail :

public sealed class GiftValidatorExecutor : Executor<List<ChatMessage>, List<ChatMessage>>
{
 public GiftValidatorExecutor() : base("GiftValidator") { }

 public override async ValueTask<List<ChatMessage>> HandleAsync(
 List<ChatMessage> messages,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 var lastMessage = messages.LastOrDefault()?.Text ?? "";

 // Validate that suggestions are within budget
 if (lastMessage.Contains("over budget", StringComparison.OrdinalIgnoreCase))
 {
 Console.WriteLine("⚠️ Some suggestions exceeded budget, filtering...");
 // Add validation logic here
 }

 Console.WriteLine("✅ Gift suggestions validated!");
 return messages;
 }
}

Vous pouvez ensuite insérer cet exécuteur dans votre workflow :

var validator = new GiftValidatorExecutor();

var workflow = new WorkflowBuilder(giftIdeaAgent)
 .AddEdge(giftIdeaAgent, validator)
 .AddEdge(validator, priceAgent)
 .AddEdge(priceAgent, summaryAgent)
 .WithOutputFrom(summaryAgent)
 .Build();

Ajout d’une vraie recherche sur le Web avec Bing Grounding

Jusqu’à présent, nos agents génèrent des réponses basées sur les connaissances du modèle d’IA. Mais que se passe-t-il si nous souhaitons rechercher sur le Web les prix et la disponibilité réels des produits ? C’est là qu’intervient Grounding with Bing Search. Il s’agit d’un outil disponible dans Microsoft Foundry (anciennement Azure AI Foundry) qui permet à vos agents d’incorporer des données Web publiques en temps réel lors de la génération de réponses.

Tout d’abord, vous devez créer une ressource Grounding with Bing Search dans le Portail Azure. Assurez-vous de le créer dans le même groupe de ressources que votre projet IA.

Configuration de Grounding avec Bing Search

La beauté de Grounding avec Bing Search est qu’il s’intègre directement aux agents Azure AI. L’agent décide quand utiliser l’outil de recherche en fonction de la requête de l’utilisateur, effectue une recherche sur le Web et utilise les résultats pour générer une réponse fondée.

using Azure.AI.Agents.Persistent;
using Azure.Identity;

public static class BingGroundingSetup
{
 public static async Task<PersistentAgent> CreateAgentWithBingGroundingAsync(
 string projectEndpoint,
 string modelDeploymentName,
 string bingConnectionId)
 {
 // Create the Persistent Agents client
 var agentClient = new PersistentAgentsClient(projectEndpoint, new DefaultAzureCredential());

 // Configure the Bing Grounding tool
 var bingGroundingTool = new BingGroundingToolDefinition(
 new BingGroundingSearchToolParameters(
 [new BingGroundingSearchConfiguration(bingConnectionId)]
 )
 );

 // Create the agent with Bing Grounding enabled
 var agent = await agentClient.Administration.CreateAgentAsync(
 model: modelDeploymentName,
 name: "ChristmasPriceHunter",
 instructions: @"You are a Christmas gift price comparison specialist.

 When given gift ideas, use Bing to search for:
 - Current prices at major retailers (Amazon, Best Buy, Target, Walmart)
 - Available discounts and holiday deals
 - Shipping times to ensure delivery before Christmas

 Always provide URLs to the products you find.
 Highlight the best deals and recommend where to buy.",
 tools: [bingGroundingTool]
 );

 return agent;
 }
}

Création d’un agent de comparaison de prix avec Real Search

Créons maintenant un agent de comparaison de prix complet qui recherche sur le Web des informations réelles sur les produits :

using Azure.AI.Agents.Persistent;
using Azure.Identity;

public class ChristmasPriceAgent
{
 private readonly PersistentAgentsClient _client;
 private readonly string _modelDeployment;
 private readonly string _bingConnectionId;

 public ChristmasPriceAgent(string projectEndpoint, string modelDeployment, string bingConnectionId)
 {
 _client = new PersistentAgentsClient(projectEndpoint, new DefaultAzureCredential());
 _modelDeployment = modelDeployment;
 _bingConnectionId = bingConnectionId;
 }

 public async Task<string> FindGiftPricesAsync(string giftIdeas)
 {
 // Create agent with Bing Grounding
 var bingTool = new BingGroundingToolDefinition(
 new BingGroundingSearchToolParameters(
 [new BingGroundingSearchConfiguration(_bingConnectionId)]
 )
 );

 var agent = await _client.Administration.CreateAgentAsync(
 model: _modelDeployment,
 name: "PriceHunter",
 instructions: @"Search the web for current prices on the given gift ideas.
 For each gift, find prices from at least 2-3 different stores.
 Include direct links to the products.
 Note any Christmas sales or discounts available.",
 tools: [bingTool]
 );

 try
 {
 // Create a thread for the conversation
 var thread = await _client.Threads.CreateThreadAsync();

 // Add the gift ideas as a message
 await _client.Messages.CreateMessageAsync(
 thread.Id,
 MessageRole.User,
 $"Find current prices for these gift ideas: {giftIdeas}"
 );

 // Run the agent
 var run = await _client.Runs.CreateRunAsync(thread.Id, agent.Id);

 // Wait for completion
 do
 {
 await Task.Delay(500);
 run = await _client.Runs.GetRunAsync(thread.Id, run.Id);
 }
 while (run.Status == RunStatus.Queued || run.Status == RunStatus.InProgress);

 // Get the response
 var messages = _client.Messages.GetMessages(thread.Id);
 var response = messages
 .Where(m => m.Role == MessageRole.Agent)
 .SelectMany(m => m.ContentItems)
 .OfType<MessageTextContent>()
 .FirstOrDefault();

 // Clean up
 await _client.Threads.DeleteThreadAsync(thread.Id);

 return response?.Text ?? "No results found.";
 }
 finally
 {
 // Clean up the agent
 await _client.Administration.DeleteAgentAsync(agent.Id);
 }
 }
}

Intégration de Bing Grounding dans le workflow

Voici comment utiliser l’agent de prix alimenté par Bing dans un flux de travail complet de recherche de cadeaux :

public static async Task RunWithBingGroundingAsync()
{
 var projectEndpoint = Environment.GetEnvironmentVariable("PROJECT_ENDPOINT")!;
 var modelDeployment = Environment.GetEnvironmentVariable("MODEL_DEPLOYMENT_NAME") ?? "gpt-4o";
 var bingConnectionId = Environment.GetEnvironmentVariable("BING_CONNECTION_ID")!;
 // Connection ID format: /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}/projects/{project}/connections/{connection}

 Console.WriteLine("🔍 Searching the web for real prices with Bing Grounding...\n");

 var priceAgent = new ChristmasPriceAgent(projectEndpoint, modelDeployment, bingConnectionId);

 // First, generate gift ideas (could come from another agent)
 var giftIdeas = "1. Milwaukee cordless drill set, 2. Weber portable grill, 3. Carhartt beanie";

 // Search for real prices
 var priceResults = await priceAgent.FindGiftPricesAsync(giftIdeas);

 Console.WriteLine("📊 Price Comparison Results:");
 Console.WriteLine(priceResults);
 Console.WriteLine("\n🎁 Happy Shopping! 🎁");
}

Traitement des citations à partir des résultats Bing

Un aspect important de Grounding with Bing Search est que les réponses incluent des citations avec des liens vers les sites Web sources. Voici comment les extraire et les afficher :

public static void ProcessBingGroundingResponse(IEnumerable<PersistentThreadMessage> messages)
{
 foreach (var message in messages.Where(m => m.Role == MessageRole.Agent))
 {
 foreach (var content in message.ContentItems)
 {
 if (content is MessageTextContent textContent)
 {
 var response = textContent.Text;

 // Process URL citations
 if (textContent.Annotations != null)
 {
 foreach (var annotation in textContent.Annotations)
 {
 if (annotation is MessageTextUriCitationAnnotation uriAnnotation)
 {
 // Replace citation placeholder with markdown link
 response = response.Replace(
 uriAnnotation.Text,
 $" [{uriAnnotation.UriCitation.Title}]({uriAnnotation.UriCitation.Uri})"
 );
 }
 }
 }

 Console.WriteLine(response);
 }
 }
 }
}

Désormais, lorsque l’agent de comparaison de prix s’exécute, il utilise Grounding with Bing Search pour trouver de véritables listes de produits, les prix actuels et les offres disponibles sur le Web en direct. L’agent décide automatiquement quand effectuer la recherche en fonction de la requête et renvoie des réponses fondées avec les citations appropriées.

Le programme complet

Voici comment tout se déroule dans Program.cs :

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Extensions.AI;

Console.WriteLine("🎄 Christmas Gift Finder - Powered by AI Agents 🎄\n");

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!;
var deployment = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME") ?? "gpt-4o-mini";

var chatClient = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetChatClient(deployment)
 .AsIChatClient();

// Create the agent team
var ideaAgent = ChristmasAgentFactory.CreateGiftIdeaAgent(chatClient);
var priceAgent = ChristmasAgentFactory.CreatePriceComparisonAgent(chatClient);
var summaryAgent = ChristmasAgentFactory.CreateSummaryAgent(chatClient);

// Build the workflow
var workflow = AgentWorkflowBuilder.BuildSequential(
 "ChristmasGiftWorkflow",
 [ideaAgent, priceAgent, summaryAgent]);

Console.Write("Who are you shopping for? ");
var recipientName = Console.ReadLine() ?? "Someone special";

Console.Write("What are their interests? ");
var interests = Console.ReadLine() ?? "general";

Console.Write("What's your budget? $");
var budget = Console.ReadLine() ?? "50";

var prompt = $"Find Christmas gifts for {recipientName} who enjoys {interests}. Budget: ${budget}";

Console.WriteLine("\n🔍 Searching for the perfect gifts...\n");

await using var run = await InProcessExecution.StreamAsync(
 workflow,
 new ChatMessage(ChatRole.User, prompt));

await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

await foreach (var evt in run.WatchStreamAsync())
{
 switch (evt)
 {
 case AgentRunUpdateEvent update:
 Console.Write(update.Update.Text);
 break;
 case WorkflowOutputEvent output:
 Console.WriteLine("\n\n🎁 Happy Shopping! 🎁");
 break;
 }
}

Conclusion

L’Agent Framework de Microsoft facilite étonnamment la création de systèmes multi-agents dans lesquels chaque agent se spécialise dans une tâche spécifique. En coordonnant ces agents via des workflows, nous pouvons résoudre des problèmes complexes comme les achats de Noël de manière structurée et efficace.

Ce qui rend cela encore plus puissant, c’est la possibilité d’ajouter des fonctionnalités du monde réel via des outils. En intégrant Grounding with Bing Search de Microsoft Foundry, notre agent de comparaison de prix peut réellement rechercher sur le Web les prix, les offres et la disponibilité actuels, transformant ainsi un simple chatbot IA en un assistant d’achat vraiment utile avec des citations appropriées.

La prise en charge par le framework des modèles séquentiels, simultanés et de transfert signifie que vous pouvez concevoir des systèmes d’agents qui répondent exactement à vos besoins. Qu’il s’agisse de trouver des cadeaux, de planifier des voyages ou de toute autre tâche en plusieurs étapes, Agent Framework fournit les éléments de base pour y parvenir.En cette période des fêtes, laissez les agents IA gérer les recherches pendant que vous vous concentrez sur l’emballage des cadeaux et le temps passé en famille !

##Code source

Les concepts présentés dans cet article sont basés sur les exemples officiels de Agent Framework. Vous pouvez explorer plus d’exemples sur le référentiel GitHub de Microsoft Agent Framework.

Bonnes vacances et bon codage ! 🎄

Créer un agrégateur de flux RSS alimenté par l'IA

Fri, 12 Dec 2025 00:00:00 +0000

En tant que MVP Microsoft et passionné de technologie, je me retrouve constamment noyé dans l’océan de contenu incroyable publié sur les DevBlogs de Microsoft. Des annonces .NET aux mises à jour de Visual Studio, des innovations Azure aux analyses approfondies du noyau sémantique, il se passe toujours quelque chose de nouveau et d’excitant dans l’écosystème Microsoft.

Le problème ? Suivre tout cela est presque impossible.

Je voulais rester au courant des dernières annonces et les partager avec mon réseau, mais vérifier manuellement sept flux RSS différents, lire des articles, créer des publications attrayantes sur les réseaux sociaux et suivre ce que j’avais déjà partagé devenait un travail à temps plein en soi. Chaque matin, j’ouvrais plusieurs onglets de navigateur, parcourais des dizaines d’articles, essayais de me souvenir de ceux que j’avais déjà partagés, puis passais un temps précieux à rédiger des articles sur ceux qui avaient retenu mon attention.

J’ai donc fait ce que n’importe quel développeur ferait : Je l’ai automatisé.

Dans ce guide complet, je vais vous expliquer comment j’ai créé un agrégateur de flux RSS alimenté par l’IA qui surveille plusieurs flux RSS Microsoft DevBlogs pour le nouveau contenu, utilise Azure OpenAI et Semantic Kernel pour analyser les articles et générer des publications attrayantes, crée une documentation de démarque détaillée pour chaque article analysé, envoie des notifications via Telegram afin que je puisse réviser et partager le contenu, tout suivre pour éviter les publications en double et s’exécute automatiquement via GitHub Actions.

Examinons en profondeur tous les aspects de cette solution.

L’histoire derrière ce projet

Vivre avec une surcharge d’informations

Laissez-moi vous dresser un tableau de ma matinée typique avant de créer cet outil. Je me réveillais, prenais mon café et ouvrais mon ordinateur portable pour vérifier les nouveautés de l’écosystème des développeurs Microsoft. Tout d’abord, je naviguerais vers le site principal de DevBlogs pour voir s’il y avait des annonces majeures. Ensuite, je consulterais le blog .NET spécifiquement parce que c’est ma principale pile technologique. Après cela, je me dirigerais vers le blog Semantic Kernel car l’IA devient de plus en plus importante. Le blog Visual Studio était le prochain sur la liste car les mises à jour de l’IDE peuvent avoir un impact significatif sur mon flux de travail quotidien. Vint ensuite le blog DevOps pour les actualités liées à CI/CD et GitHub, suivi du blog All Things Azure pour les mises à jour de l’infrastructure cloud, et enfin du blog Azure SQL pour les innovations en matière de bases de données.

Cela fait sept flux différents à vérifier. Chacun de ces blogs publie plusieurs articles par semaine, parfois plusieurs par jour lors des périodes d’annonces majeures comme .NET Conf ou Build. Cela représente potentiellement des dizaines d’articles à suivre, à lire et à partager. Et voici le problème : en tant que personne qui valorise le partage de connaissances avec la communauté, je ne voulais pas simplement lire ces articles. Je voulais partager les plus précieux avec mon réseau sur LinkedIn, aidant ainsi les autres développeurs à rester informés.Mais rédiger une bonne publication sur LinkedIn prend du temps. Vous devez lire attentivement l’article, comprendre les points clés, réfléchir aux raisons pour lesquelles il est important pour votre public, rédiger un texte engageant et bien formater le tout. Multipliez cela par plusieurs articles par semaine et vous obtenez des heures de travail.

Ce que je voulais vraiment

Après avoir réfléchi à ce problème pendant des mois, je me suis assis et j’ai réfléchi à ce à quoi ressemblerait une solution idéale. Avant tout, je ne voulais plus jamais manquer des annonces importantes. Le système devrait automatiquement détecter les nouveaux articles dès qu’ils sont publiés. Je voulais également gagner du temps sur la création de contenu en laissant l’IA m’aider à créer des publications engageantes – non pas pour remplacer entièrement ma voix, mais pour me donner un point de départ solide que je pourrais personnaliser.

La cohérence était un autre facteur important. Je voulais partager du contenu régulièrement sans avoir à penser à le faire manuellement chaque jour. L’aspect suivi était également crucial : j’avais besoin d’un moyen de savoir ce que j’avais déjà partagé pour éviter de publier des doublons et d’ennuyer mes abonnés. Enfin, je voulais rester organisé avec un enregistrement permanent de tout ce que j’ai traité, afin de pouvoir regarder en arrière et voir quels sujets j’ai abordés.

La solution prend forme

La solution que j’envisageais s’exécuterait selon un calendrier en utilisant GitHub Actions, entièrement mains libres. Il récupérerait automatiquement les sept flux sans que j’aie à ouvrir un seul onglet de navigateur. Le composant IA lirait et comprendrait le contenu, puis le résumerait d’une manière utile pour mon public. Au lieu de devoir écrire des articles à partir de zéro, cela créerait du contenu sur les réseaux sociaux prêt à partager que je pourrais modifier si nécessaire. Tout serait envoyé sur mon Telegram pour examen, afin que je puisse rapidement jeter un coup d’œil sur mon téléphone et décider quoi partager. Et bien sûr, il conserverait un enregistrement permanent de tout pour référence future.

Avant de commencer à construire

Ce dont vous aurez besoin sur votre machine

Pour suivre ce didacticiel, vous aurez besoin de quelques éléments installés sur votre machine de développement. Le plus important est le SDK .NET version 9.0 ou ultérieure. Il s’agit de notre environnement d’exécution et fournit tous les outils de construction dont nous avons besoin. Si vous ne l’avez pas installé, rendez-vous sur dot.net et téléchargez la dernière version. L’installation est simple sous Windows, macOS ou Linux.

Vous souhaiterez également que Git soit installé pour le contrôle de version. Nous allons transmettre notre code à GitHub et utiliser GitHub Actions pour l’automatisation. Il est donc essentiel de configurer Git localement. Toute version récente fonctionnera correctement.

Pour votre environnement de développement, je recommande Visual Studio ou VS Code. Personnellement, j’utilise VS Code pour la plupart de mon travail ces jours-ci car il est léger et offre un excellent support C# via l’extension C# Dev Kit. Mais si vous êtes plus à l’aise avec Visual Studio complet, cela fonctionne également parfaitement.

Services et comptes dont vous aurez besoinAu-delà des outils locaux, vous aurez besoin de comptes avec quelques services. Le plus important est Azure OpenAI, qui alimente notre analyse de l’IA. Il s’agit d’un service payant, mais les coûts sont minimes pour ce cas d’utilisation : nous parlons de centimes par article analysé. Si vous n’avez pas de compte Azure, vous pouvez vous inscrire pour un essai gratuit qui comprend des crédits pour commencer.

Pour les notifications, nous utiliserons un Telegram Bot. L’avantage de Telegram est que son API de bot est totalement gratuite. Vous pouvez créer autant de robots que vous le souhaitez et envoyer des messages illimités. Je vous expliquerai le processus de configuration plus loin dans ce guide.

Enfin, vous aurez besoin d’un compte GitHub pour héberger votre code et exécuter GitHub Actions. Le niveau gratuit est plus que suffisant pour ce projet. GitHub vous offre 2 000 minutes d’exécution d’actions par mois sur les référentiels privés et un nombre illimité de minutes sur les référentiels publics.

Les bibliothèques qui rendent cela possible

Notre projet s’appuie sur trois packages NuGet principaux, chacun servant un objectif spécifique.

Le premier est HtmlAgilityPack, qui est la référence en matière d’analyse HTML dans .NET. Lorsque nous récupérons un article d’un blog, nous récupérons le code HTML complet de la page, y compris les menus de navigation, les pieds de page, les publicités et toutes sortes d’éléments qui ne nous intéressent pas. HtmlAgilityPack nous permet d’analyser ce code HTML et d’extraire uniquement le contenu de l’article dont nous avons besoin.

Le deuxième package est Microsoft.SemanticKernel, qui est le SDK de Microsoft permettant d’intégrer des modèles d’IA dans des applications. Considérez-le comme le pont entre votre code .NET et les grands modèles de langage comme GPT-4. Il gère toute la complexité des appels d’API, de la gestion des jetons et de l’analyse des réponses, vous permettant de vous concentrer sur ce que vous voulez que l’IA fasse réellement.

Le troisième package est System.ServiceModel.Syndication, qui fournit une prise en charge intégrée pour l’analyse des flux RSS et Atom. RSS peut sembler une technologie ancienne, mais il reste le meilleur moyen d’obtenir des mises à jour structurées à partir de blogs et de sites d’actualités. Ce package transforme les flux XML bruts en objets C# fortement typés et faciles à utiliser.

Comprendre l’architecture

Comment les pièces s’emboîtent

Avant de plonger dans le code, laissez-moi vous expliquer comment tous les composants fonctionnent ensemble. Comprendre la situation dans son ensemble rendra les détails de mise en œuvre beaucoup plus clairs.

Au plus haut niveau, nous avons notre fichier principal Program.cs qui fait office d’orchestrateur. C’est le point d’entrée de notre application, et il coordonne tous les autres composants. Lorsque l’application s’exécute, elle charge d’abord la configuration à partir des variables d’environnement, telles que les clés API et les informations d’identification Telegram. Ensuite, il récupère les flux RSS des sept sources Microsoft DevBlogs. Lors du traitement de ces flux, il déduplique les articles pour gérer les cas où le même article apparaît dans plusieurs flux. Il vérifie chaque article par rapport à notre fichier de suivi pour voir si nous l’avons déjà traité. Pour les nouveaux articles, il les transmet à l’analyseur IA pour traitement.La classe ArticleAnalyzer est l’endroit où la magie de l’IA se produit. Ce composant reçoit un article et en fait plusieurs choses. Tout d’abord, il récupère l’intégralité du contenu HTML à partir de l’URL de l’article. Ensuite, il extrait le texte propre de ce code HTML, en supprimant tous les éléments de navigation, scripts et styles dont nous n’avons pas besoin. Une fois qu’il dispose d’un texte clair, il l’envoie à Azure OpenAI via Semantic Kernel avec une invite soigneusement conçue. L’IA analyse l’article et renvoie une réponse structurée qui comprend un résumé, des sujets clés, une explication de pertinence et, surtout, une publication LinkedIn prête à l’emploi. L’analyseur analyse cette réponse et renvoie un objet ArticleAnalysis contenant toutes ces informations.

La classe MarkdownGenerator prend cet objet ArticleAnalysis et en crée un enregistrement permanent. Il génère un fichier de démarque bien formaté qui comprend toutes les métadonnées de l’article, l’analyse de l’IA et la publication générée. Ces fichiers sont stockés dans un répertoire de publications générées, vous offrant une archive consultable de tout ce que vous avez traité.

Enfin, l’intégration Telegram envoie le contenu de la publication généré à votre téléphone. C’est à ce moment-là que vous, en tant qu’humain, pouvez examiner le travail de l’IA et décider de le partager ou non. Le bot vous envoie un message avec le contenu de la publication, et vous pouvez soit le copier directement sur LinkedIn, soit le modifier d’abord.

Le flux de données

Laissez-moi vous expliquer ce qui se passe lorsqu’un nouvel article est publié sur le blog .NET. Le workflow démarre lorsque GitHub Actions déclenche notre application selon son calendrier, disons toutes les six heures. L’application se réveille et commence à récupérer les sept flux RSS. Chaque flux renvoie un document XML contenant les articles les plus récents de ce blog.

Au fur et à mesure que nous analysons chaque flux, nous extrayons des articles individuels et les stockons dans une liste. Mais voici une partie délicate : le flux principal des DevBlogs comprend souvent des articles qui apparaissent également dans les flux de catégories individuelles. Ainsi, un article sur « .NET 10 » peut apparaître à la fois dans le flux principal et dans le flux spécifique à .NET. Nous gérons cela en suivant les URL dans un HashSet, ce qui empêche automatiquement les doublons.

Une fois que nous avons notre liste d’articles dédupliquée, nous la filtrons uniquement pour les plus récents – généralement les articles publiés au cours des derniers jours. Nous ne voulons pas traiter d’anciens articles que nous avons déjà traités lors d’exécutions précédentes. Ensuite, nous vérifions chaque article récent par rapport à notre fichier de suivi. Si nous avons déjà traité et publié un article, nous l’ignorons.

Pour chaque nouvel article, nous lançons le pipeline d’analyse de l’IA. L’analyseur récupère le code HTML complet de l’article, le nettoie et l’envoie à GPT-4 avec notre invite. L’IA lit l’article et génère une analyse complète ainsi qu’une publication LinkedIn. Nous enregistrons cette analyse dans un fichier de démarque pour nos dossiers.Une fois l’analyse terminée, nous formatons un message et l’envoyons via Telegram. Le message inclut le contenu de la publication généré avec l’URL et les hashtags ajoutés. Sur mon téléphone, je reçois une notification, je consulte la publication et si je l’aime, je peux la copier et la partager sur LinkedIn en quelques clics.

Enfin, nous mettons à jour notre fichier de suivi pour marquer cet article comme traité, afin de ne plus le traiter lors des prochaines exécutions. Si des fichiers ont été créés ou modifiés, GitHub Actions valide ces modifications dans le référentiel, en gardant tout synchronisé.

Configurer le projet à partir de zéro

Création de la structure de la solution

Commençons à construire. Ouvrez votre terminal et accédez à l’endroit où vous souhaitez créer le projet. J’aime garder mes projets organisés dans un dossier Développement, mais vous pouvez le placer là où cela vous convient.

Tout d’abord, nous allons créer un nouveau fichier de solution. Dans .NET, une solution est un conteneur pouvant contenir plusieurs projets. Même si nous n’avons qu’un seul projet pour l’instant, commencer par une solution facilite l’ajout de projets supplémentaires ultérieurement si nécessaire. Exécutez la commande dotnet new sln -n vs-feed-linkedin pour créer une solution nommée vs-feed-linkedin.

Ensuite, nous devons créer notre projet d’application console. Nous allons mettre cela dans un sous-répertoire src pour garder les choses organisées. Exécutez dotnet new console -n VsFeedLinkedin -o src pour créer un projet de console nommé VsFeedLinkedin dans le dossier src. Ajoutez ensuite ce projet à notre solution avec dotnet sln add src/VsFeedLinkedin.csproj.

Naviguez maintenant dans le répertoire src avec cd src. C’est ici que nous ajouterons nos packages NuGet et effectuerons l’essentiel de notre développement.

Ajout des packages requis

Une fois notre projet créé, nous devons ajouter les trois packages NuGet que j’ai mentionnés plus tôt. Exécutez chacune de ces commandes dans l’ordre :

dotnet add package System.ServiceModel.Syndication --version 9.0.9
dotnet add package Microsoft.SemanticKernel --version 1.30.0
dotnet add package HtmlAgilityPack --version 1.11.72

Après avoir exécuté ces commandes, votre fichier de projet devrait ressembler à ceci :

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>net9.0</TargetFramework>
 <ImplicitUsings>enable</ImplicitUsings>
 <Nullable>enable</Nullable>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="HtmlAgilityPack" Version="1.11.72" />
 <PackageReference Include="Microsoft.SemanticKernel" Version="1.30.0" />
 <PackageReference Include="System.ServiceModel.Syndication" Version="9.0.9" />
 </ItemGroup>

</Project>

Le fichier de projet indique à .NET que nous construisons un exécutable (OutputType est Exe), ciblant .NET 9.0 et utilisant des fonctionnalités C# modernes telles que les utilisations implicites et les types de référence nullables. La section ItemGroup répertorie nos trois dépendances de packages avec leurs versions exactes.

Plongez en profondeur dans les flux RSS

Qu’est-ce que RSS exactement ?

Avant de commencer à écrire du code pour récupérer des flux, assurons-nous de bien comprendre avec quoi nous travaillons. RSS signifie Really Simple Syndication et il s’agit d’un format XML standardisé pour la distribution de mises à jour de contenu. L’idée est simple : au lieu d’obliger les utilisateurs à visiter votre site Web pour voir s’il y a du nouveau contenu, vous publiez un fichier lisible par machine qui répertorie votre contenu récent. Les applications peuvent ensuite interroger périodiquement ce fichier pour découvrir de nouveaux articles.

Le RSS existe depuis la fin des années 1990 et le début des années 2000. Vous pensez peut-être qu’il s’agit d’une technologie obsolète, mais elle est en réalité encore largement utilisée, notamment par les blogs, les sites d’actualités et les podcasts. La beauté du RSS réside dans sa simplicité. C’est juste du XML avec une structure définie, et n’importe quelle application peut l’analyser.

La structure d’un flux DevBlogsLorsque vous récupérez un flux RSS depuis Microsoft DevBlogs, vous obtenez un document XML qui suit une structure spécifique. Au niveau supérieur, il y a un élément rss qui contient un seul élément de canal. Le canal représente le blog lui-même et inclut des métadonnées telles que le titre, l’URL et la description du blog.

À l’intérieur de la chaîne, vous trouverez plusieurs éléments d’élément, chacun représentant un article de blog individuel. Chaque élément comprend un titre (le titre de l’article), un lien (l’URL où vous pouvez lire l’article complet), une pubDate (la date de publication de l’article), un élément dc:creator (le nom de l’auteur), un ou plusieurs éléments de catégorie (balises pour l’article) et une description (généralement un résumé ou un extrait de l’article).

Voici un exemple simplifié de ce à quoi cela ressemble :

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
 <channel>
 <title>.NET Blog</title>
 <link>https://devblogs.microsoft.com/dotnet</link>
 <description>The latest news about .NET</description>
 <item>
 <title>Announcing .NET 10</title>
 <link>https://devblogs.microsoft.com/dotnet/announcing-dotnet-10</link>
 <pubDate>Mon, 10 Dec 2025 12:00:00 GMT</pubDate>
 <dc:creator>Microsoft</dc:creator>
 <category>Announcements</category>
 <category>.NET</category>
 <description>Article summary...</description>
 </item>
 </channel>
</rss>

L’avantage du package System.ServiceModel.Syndication de .NET est qu’il analyse tout cela pour nous. Nous n’avons pas besoin de naviguer manuellement dans les nœuds XML ni de nous soucier des différentes versions RSS. Nous chargeons simplement le flux et récupérons les objets fortement typés.

Les sept flux que nous surveillons

Dans mon implémentation, je surveille sept flux Microsoft DevBlogs différents. Le flux principal DevBlogs sur devblogs.microsoft.com/feed nous donne une vue d’ensemble de tout ce que Microsoft publie sur tous ses blogs de développeurs. Le flux spécifique à .NET sur devblogs.microsoft.com/dotnet/feed se concentre spécifiquement sur les versions, les fonctionnalités et les meilleures pratiques de .NET. Le flux Semantic Kernel sur devblogs.microsoft.com/semantic-kernel/feed couvre l’orchestration et l’intégration de l’IA – de plus en plus importantes à mesure que l’IA devient centrale dans le développement moderne.

Le flux Visual Studio sur devblogs.microsoft.com/visualstudio/feed me tient au courant des améliorations de l’IDE et des fonctionnalités de productivité. Le flux DevOps sur devblogs.microsoft.com/devops/feed couvre les sujets Azure DevOps, GitHub et CI/CD. Le flux All Things Azure sur devblogs.microsoft.com/all-things-azure/feed se concentre sur les services cloud et les modèles d’architecture. Enfin, le flux Azure SQL sur devblogs.microsoft.com/azure-sql/feed couvre les innovations et fonctionnalités des bases de données.

Vous vous demandez peut-être pourquoi je vérifie à la fois le flux principal et les flux de catégories individuelles. Le flux principal me donne de l’ampleur : je verrai des articles de n’importe quel blog de développeur Microsoft, y compris ceux que je ne connais peut-être pas. Les flux de catégories me donnent de la profondeur : ils garantissent que je ne manque rien d’important dans mes principaux domaines d’intérêt, même si ces articles sont exclus du flux principal par du contenu plus récent.

Construire la logique de récupération RSS

La fonction de récupération de base

Maintenant, écrivons du code. La base de notre application est la capacité de récupérer et d’analyser les flux RSS. Voici la fonction qui gère cela :

static async Task<SyndicationFeed?> FetchRssFeedAsync(string url)
{
 using var httpClient = new HttpClient();
 httpClient.DefaultRequestHeaders.Add("User-Agent", "VsFeedLinkedin/1.0");

 var response = await httpClient.GetStringAsync(url);

 using var stringReader = new StringReader(response);

 var settings = new XmlReaderSettings
 {
 DtdProcessing = DtdProcessing.Parse,
 MaxCharactersFromEntities = 1024
 };

 using var xmlReader = XmlReader.Create(stringReader, settings);

 return SyndicationFeed.Load(xmlReader);
}

Laissez-moi vous expliquer ce que fait ce code. Nous commençons par créer un HttpClient, qui est la classe intégrée de .NET pour effectuer des requêtes HTTP. Nous définissons un en-tête User-Agent car certains serveurs bloquent les requêtes qui ne s’identifient pas. C’est une bonne pratique de définir cela même lorsque les serveurs ne l’exigent pas.Nous effectuons ensuite une requête GET à l’URL du flux et recevons la réponse sous forme de chaîne. Cette chaîne contient le XML brut du flux RSS.

Pour analyser ce XML, nous créons un StringReader pour envelopper notre chaîne de réponse, puis configurons certains XmlReaderSettings. Le paramètre DtdProcessing est important : les flux RSS incluent parfois des déclarations DTD (Document Type Definition) qui doivent être traitées. Le paramètre MaxCharactersFromEntities est une mesure de sécurité qui empêche les attaques à la bombe XML en limitant le degré d’expansion des entités pouvant se produire.

Enfin, nous créons un XmlReader avec ces paramètres et utilisons SyndicationFeed.Load pour analyser le XML en un objet SyndicationFeed fortement typé. Cela nous donne accès aux métadonnées du flux et à tous ses éléments via de jolies propriétés C# au lieu d’une navigation XML brute.

Récupération de plusieurs flux avec gestion des erreurs

Dans le monde réel, les requêtes réseau échouent. Les serveurs tombent en panne, les connexions expirent et XML peut être mal formé. Nous devons traiter ces cas avec élégance. Voici comment nous récupérons tous nos flux tout en étant résilients aux pannes :

var allArticles = new List<(SyndicationItem item, string feedUrl)>();
var seenUrls = new HashSet<string>();

foreach (var feedUrl in feedUrls)
{
 try
 {
 Console.WriteLine($" 📡 Fetching {feedUrl}...");
 var feed = await FetchRssFeedAsync(feedUrl);

 if (feed?.Items != null && feed.Items.Any())
 {
 foreach (var item in feed.Items)
 {
 var itemUrl = item.Links.FirstOrDefault()?.Uri.ToString() ?? "";
 if (!string.IsNullOrEmpty(itemUrl) && seenUrls.Add(itemUrl))
 {
 allArticles.Add((item, feedUrl));
 }
 }
 }
 }
 catch (Exception ex)
 {
 Console.WriteLine($" ⚠️ Failed to fetch {feedUrl}: {ex.Message}");
 }
}

Nous conservons ici deux collections. La liste allArticles contiendra tous les articles que nous trouvons, ainsi que le flux d’où ils proviennent. Le sawUrls HashSet suit les URL d’articles que nous avons déjà vues, ce qui nous aide à éviter les doublons.

Nous parcourons chaque URL de flux et encapsulons l’opération de récupération dans un bloc try-catch. Si la récupération d’un flux particulier échoue (peut-être que le serveur est temporairement en panne), nous enregistrons un avertissement et passons au flux suivant. Ainsi, un problème sur un flux ne nous empêche pas de traiter les autres.

Pour chaque flux récupéré avec succès, nous parcourons ses éléments. Nous extrayons l’URL de l’article de la collection Links de l’élément. La méthode HashSet.Add renvoie false si l’URL est déjà dans l’ensemble, ce qui est parfait pour notre logique de déduplication. Nous ajoutons l’article à notre liste uniquement s’il est nouveau.

Nous stockons l’URL du flux à côté de chaque article, car ces informations pourraient être utiles ultérieurement. Par exemple, nous pourrions vouloir savoir de quel flux spécifique provient un article à des fins de débogage ou de journalisation.

Gestion des doublons et suivi de l’état

Le défi de la déduplication

Comme je l’ai mentionné plus tôt, Microsoft DevBlogs a une structure de flux hiérarchique qui crée un défi intéressant. Lorsqu’un membre de l’équipe .NET publie un article sur, par exemple, les améliorations des performances dans .NET 10, cet article apparaîtra probablement à la fois dans le flux principal DevBlogs et dans le flux spécifique à .NET. Parfois, il peut même apparaître dans le flux Visual Studio s’il concerne les fonctionnalités de l’EDI.

Si nous traitions naïvement chaque article de chaque flux, nous finirions par analyser et publier plusieurs fois le même article. Cela gaspillerait les appels d’API vers Azure OpenAI, spammerait notre Telegram avec des notifications en double et potentiellement ennuyer nos abonnés si nous publiions des doublons.La solution est la déduplication basée sur les URL. Chaque article a une URL unique, nous pouvons donc l’utiliser comme identifiant. La structure de données HashSet est parfaite pour cela car elle fournit un temps de recherche O(1) et empêche automatiquement les doublons. Lorsque nous essayons d’ajouter une URL qui figure déjà dans l’ensemble, la méthode Add renvoie simplement false, nous indiquant que nous devons ignorer cet article.

État persistant avec Markdown

La déduplication gère les doublons au sein d’une seule exécution, mais qu’en est-il entre les exécutions ? Lorsque notre application s’exécute toutes les six heures, nous devons nous souvenir des articles que nous avons déjà traités afin de ne plus les traiter.

J’ai choisi de stocker cet état dans un fichier markdown appeléposted-articles.md. Pourquoi une démarque ? Quelques raisons. Premièrement, c’est lisible par l’homme. Je peux ouvrir le fichier et voir immédiatement quels articles j’ai partagés. Deuxièmement, il est contrôlé par la version. Étant donné que ce fichier se trouve dans notre référentiel Git, j’ai un historique complet du moment où les articles ont été traités. Troisièmement, il sert de documentation. Quiconque consulte le référentiel peut voir ce que l’application a fait.

Le format de ce fichier est simple. Il comporte un en-tête, un horodatage indiquant la dernière exécution de l’application, puis une liste d’articles au format lien markdown :

# Posted Articles

*Last run: 2025-12-10 15:30:00*

List of articles posted to LinkedIn:

- [Announcing .NET 10](https://devblogs.microsoft.com/dotnet/announcing-dotnet-10?wt.mc_id=DT-MVP-5004972) - Posted on 2025-12-10 15:30:00 (Published: 2025-12-10)
- [Visual Studio 2026 Preview](https://devblogs.microsoft.com/visualstudio/vs-2026-preview?wt.mc_id=DT-MVP-5004972) - Posted on 2025-12-09 10:15:00 (Published: 2025-12-09)

Chargement et analyse du fichier de suivi

Pour vérifier si nous avons déjà traité un article, nous devons charger ce fichier et extraire les URL. Voici la fonction qui fait cela :

static HashSet<string> LoadPostedArticles(string filePath)
{
 var postedUrls = new HashSet<string>();

 if (!File.Exists(filePath))
 {
 return postedUrls;
 }

 var lines = File.ReadAllLines(filePath);
 foreach (var line in lines)
 {
 var match = System.Text.RegularExpressions.Regex.Match(line, @"\(([^)]+)\)");
 if (match.Success)
 {
 var url = match.Groups[1].Value;

 if (url.Contains("?wt.mc_id="))
 {
 url = url.Substring(0, url.IndexOf("?wt.mc_id="));
 }
 else if (url.Contains("?"))
 {
 url = url.Substring(0, url.IndexOf("?"));
 }

 url = url.TrimEnd('/');
 postedUrls.Add(url);
 }
 }

 return postedUrls;
}

Cette fonction renvoie un HashSet contenant toutes les URL que nous avons déjà traitées. Nous commençons par vérifier si le fichier existe – lors de la première exécution, ce ne sera pas le cas, nous renvoyons donc un ensemble vide.

Pour chaque ligne du fichier, nous utilisons une regex pour extraire l’URL du format de lien markdown. L’expression régulière $([^)]+)$ correspond à tout ce qui se trouve entre parenthèses, où les liens de démarque stockent leurs URL.

Vient ensuite une étape importante : la normalisation des URL. Les URL d’un même article peuvent varier en format. Le flux RSS peut nous donner https://devblogs.microsoft.com/dotnet/article, mais notre version enregistrée comporte un paramètre de suivi ajouté : https://devblogs.microsoft.com/dotnet/article?wt.mc_id=DT-MVP-5004972. Certaines URL comportent des barres obliques finales, d’autres non.

Pour gérer cela, nous supprimons tous les paramètres de requête (tout ce qui se trouve après le ?) et supprimons les barres obliques finales. Cette normalisation garantit que nous reconnaissons les articles comme des doublons même si leurs URL diffèrent de manière superficielle.

Sauvegarde des nouveaux articles

Lorsque nous traitons avec succès un article, nous devons l’ajouter à notre fichier de suivi :

static void SavePostedArticle(string filePath, string url, string title, DateTimeOffset publishDate)
{
 var markdownEntry = $"- [{title}]({url}) - Posted on {DateTime.Now:yyyy-MM-dd HH:mm:ss} (Published: {publishDate:yyyy-MM-dd})\n";

 if (!File.Exists(filePath))
 {
 File.WriteAllText(filePath, "# Posted Articles\n\n*Last run: {DateTime.Now:yyyy-MM-dd HH:mm:ss}*\n\nList of articles posted:\n\n");
 }

 File.AppendAllText(filePath, markdownEntry);
}

Cette fonction crée une entrée au format markdown avec le titre de l’article comme lien, suivi d’horodatages indiquant quand nous l’avons publié et quand il a été initialement publié. Si le fichier n’existe pas encore, nous le créons d’abord avec un en-tête.

Le moteur d’analyse de l’IA

Comprendre le noyau sémantiquePassons maintenant à la partie la plus intéressante de notre application : l’analyse de l’IA. Semantic Kernel est le SDK open source de Microsoft permettant d’intégrer de grands modèles de langage dans des applications. C’est plus qu’un simple wrapper autour des appels API. Il fournit un cadre pour créer des applications d’IA sophistiquées avec des fonctionnalités telles que des plugins, des planificateurs et de la mémoire.

Pour notre cas d’utilisation, nous utilisons les capacités de complétion de discussion de Semantic Kernel. Nous enverrons une invite à Azure OpenAI, et le modèle analysera notre article et générera une réponse. Semantic Kernel gère toute la complexité de l’authentification API, du formatage des requêtes et de l’analyse des réponses.

Configuration de l’analyseur d’articles

Voyons comment nous avons configuré notre classe d’analyseur :

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using HtmlAgilityPack;

namespace VsFeedLinkedin.Services;

public class ArticleAnalyzer
{
 private readonly Kernel _kernel;
 private readonly IChatCompletionService _chatService;

 public ArticleAnalyzer(string endpoint, string apiKey, string deploymentName)
 {
 var builder = Kernel.CreateBuilder();

 builder.AddAzureOpenAIChatCompletion(
 deploymentName: deploymentName,
 endpoint: endpoint,
 apiKey: apiKey
 );

 _kernel = builder.Build();
 _chatService = _kernel.GetRequiredService<IChatCompletionService>();
 }

Le noyau sémantique utilise un modèle de générateur pour la configuration. Nous créons un KernelBuilder, ajoutons notre service de complétion de chat Azure OpenAI avec les informations d’identification nécessaires, puis créons le noyau. À partir du noyau construit, nous récupérons l’interface IChatCompletionService, que nous utiliserons pour envoyer des invites et recevoir des réponses.

Le constructeur prend trois paramètres : le point de terminaison Azure OpenAI (quelque chose comme https://your-resource.openai.azure.com/), votre clé API et le nom du déploiement (comme gpt-4o). Celles-ci sont transmises à partir de variables d’environnement, garantissant ainsi la sécurité de nos informations d’identification.

Créer l’invite parfaite

L’invite que nous envoyons à l’IA est cruciale. Une invite bien conçue produit des résultats cohérents et de haute qualité. Une invite vague ou mal structurée produit des résultats incohérents et médiocres. J’ai passé beaucoup de temps à parcourir cette invite pour obtenir des résultats qui me satisfont :

var prompt = $"""
 You are a professional tech content analyst and LinkedIn content creator.
 Analyze the following Microsoft DevBlogs article and create an engaging LinkedIn post.

 Article Title: {title}
 Author: {author}
 URL: {url}
 Tags: {string.Join(", ", tags)}

 Article Content:
 {cleanContent}

 Please provide:
 1. A brief summary (2-3 sentences) of the key points
 2. The main technologies or topics covered
 3. Why this is relevant for developers/tech professionals
 4. An engaging LinkedIn post (max 1300 characters) that:
 - Starts with a hook or attention-grabbing statement
 - Highlights the key value for readers
 - Includes a call to action
 - Uses appropriate emojis (but not too many)
 - Maintains a professional yet approachable tone
 - DO NOT include hashtags in the post (they will be added separately)
 - DO NOT include the URL in the post (it will be added separately)

 Format your response as follows:
 ## Summary
 [Your summary here]

 ## Key Topics
 [List of main topics/technologies]

 ## Relevance
 [Why this matters]

 ## LinkedIn Post
 [Your engaging LinkedIn post here]
 """;

Laissez-moi vous expliquer les décisions de conception ici. Nous commençons par donner un rôle clair à l’IA : « Vous êtes un analyste professionnel de contenu technologique et un créateur de contenu LinkedIn. » Cela prépare le modèle à répondre avec le style et la voix appropriés.

Nous fournissons tout le contexte dont l’IA a besoin : le titre de l’article, l’auteur, l’URL, les balises du flux RSS et le contenu complet de l’article. Plus nous donnons de contexte, meilleure sera l’analyse.

Ensuite, nous précisons exactement ce que nous voulons en retour. Je demande quatre choses : un résumé, des sujets clés, une explication de la pertinence et une publication sur LinkedIn. Pour la publication LinkedIn en particulier, je donne des instructions détaillées sur ce qui fait une bonne publication : elle doit avoir une accroche, mettre en valeur la valeur, inclure un appel à l’action, utiliser les emojis de manière appropriée et conserver un ton professionnel.

Les instructions négatives sont tout aussi importantes. Je dis explicitement à l’IA de NE PAS inclure de hashtags ou d’URL dans la publication. Pourquoi? Parce que je les ajoute séparément, et si l’IA les incluait, j’aurais des doublons. Ce type d’instruction explicite évite les erreurs courantes.

Enfin, je précise le format de sortie exact. En demandant des sections marquées d’en-têtes ##, je rends la réponse facile à analyser par programme. L’IA est très douée pour suivre les instructions de formatage, et cette cohérence rend notre code d’analyse plus simple et plus fiable.

Exécution de l’analyse

Voici comment nous assemblons tout cela :

public async Task<ArticleAnalysis> AnalyzeArticleAsync(
 string title,
 string url,
 string htmlContent,
 string author,
 List<string> tags)
{
 var cleanContent = ExtractTextFromHtml(htmlContent);

 if (cleanContent.Length > 8000)
 {
 cleanContent = cleanContent.Substring(0, 8000) + "...";
 }

 var chatHistory = new ChatHistory();
 chatHistory.AddUserMessage(prompt);

 var response = await _chatService.GetChatMessageContentAsync(chatHistory);
 var responseText = response.Content ?? "";

 return ParseAnalysisResponse(responseText, title, url, author, tags);
}
```Nous extrayons d’abord le texte propre du contenu HTML (j’expliquerai cela dans la section suivante). Ensuite, nous tronquons le contenu s'il est trop long. Les grands modèles de langage ont des limites symboliques, et les articles très longs peuvent les dépasser. En plafonnant à 8 000 caractères, nous nous assurons de rester dans les limites tout en fournissant un contexte substantiel.

Nous créons un objet ChatHistory et ajoutons notre invite en tant que message utilisateur. Il s'agit de l'abstraction de Semantic Kernel pour les interactions basées sur le chat. Nous l'envoyons au service de complétion de chat et obtenons une réponse. Enfin, nous analysons la réponse pour extraire les sections individuelles.

### Analyse de la réponse de l'IA

L'IA renvoie sa réponse sous forme de texte formaté avec la structure demandée. Nous devons analyser cela en champs individuels :

```csharp
private static ArticleAnalysis ParseAnalysisResponse(
 string response,
 string title,
 string url,
 string author,
 List<string> tags)
{
 var analysis = new ArticleAnalysis
 {
 Title = title,
 Url = url,
 Author = author,
 Tags = tags,
 RawAnalysis = response
 };

 var sections = response.Split("##", StringSplitOptions.RemoveEmptyEntries);

 foreach (var section in sections)
 {
 var lines = section.Trim().Split('\n', 2);
 if (lines.Length < 2) continue;

 var sectionTitle = lines[0].Trim().ToLower();
 var sectionContent = lines[1].Trim();

 switch (sectionTitle)
 {
 case "summary":
 analysis.Summary = sectionContent;
 break;
 case "key topics":
 analysis.KeyTopics = sectionContent;
 break;
 case "relevance":
 analysis.Relevance = sectionContent;
 break;
 case "linkedin post":
 analysis.LinkedInPost = sectionContent;
 break;
 }
 }

 return analysis;
}

Nous divisons la réponse par les marqueurs ##, ce qui nous donne chaque section. Pour chaque section, nous divisons par nouvelle ligne pour séparer l’en-tête du contenu. Nous utilisons ensuite une instruction switch pour attribuer le contenu de chaque section à la propriété appropriée.

Nous stockons également la réponse brute et non analysée. Ceci est utile pour le débogage – si quelque chose ne va pas avec l’analyse, nous pouvons regarder ce que l’IA a réellement renvoyé.

Extraction de contenu à partir de HTML

Pourquoi nous devons nettoyer le HTML

Lorsque nous récupérons un article d’un blog, nous obtenons le code HTML complet de la page. Cela inclut bien plus que le contenu de l’article : il existe des menus de navigation, des en-têtes, des pieds de page, des barres latérales, des widgets d’articles associés, des sections de commentaires, des scripts d’analyse et de suivi, des feuilles de style et toutes sortes d’autres éléments.

Si nous envoyions tout cela à notre IA, plusieurs mauvaises choses se produiraient. L’IA devrait traiter beaucoup de texte non pertinent, gaspillant des jetons et potentiellement confondre l’analyse. Le texte de navigation et de pied de page peut être inclus dans le résumé. Les scripts et CSS seraient traités comme du contenu, ce qui polluerait davantage l’analyse.

Nous devons extraire uniquement le contenu de l’article – la partie qu’un lecteur humain lirait réellement.

Utilisation de HtmlAgilityPack

HtmlAgilityPack est une bibliothèque d’analyse HTML robuste pour .NET. Contrairement à XML, le HTML est souvent mal formé : les balises peuvent ne pas être correctement fermées, les attributs peuvent ne pas être correctement cités. HtmlAgilityPack gère tout cela avec élégance, nous donnant une structure de type DOM que nous pouvons interroger et manipuler.

Voici notre fonction d’extraction :

private static string ExtractTextFromHtml(string html)
{
 if (string.IsNullOrWhiteSpace(html))
 return string.Empty;

 var doc = new HtmlDocument();
 doc.LoadHtml(html);

 var nodesToRemove = doc.DocumentNode.SelectNodes("//script|//style|//nav|//footer|//header");
 if (nodesToRemove != null)
 {
 foreach (var node in nodesToRemove)
 {
 node.Remove();
 }
 }

 var text = doc.DocumentNode.InnerText;

 text = System.Text.RegularExpressions.Regex.Replace(text, @"\s+", " ");
 return text.Trim();
}

Nous chargeons le HTML dans un HtmlDocument, qui l’analyse dans une structure arborescente. Ensuite, nous utilisons XPath pour sélectionner tous les nœuds que nous souhaitons supprimer. L’expression XPath //script|//style|//nav|//footer|//header sélectionne tous les éléments de script (code JavaScript dont nous n’avons pas besoin), les éléments de style (CSS dont nous n’avons pas besoin), les éléments de navigation (menus de navigation), les éléments de pied de page et les éléments d’en-tête.

Après avoir supprimé ces nœuds, nous obtenons la propriété InnerText, qui extrait tout le contenu du texte tout en supprimant les balises HTML. Cela nous donne le texte brut de l’article.Enfin, nous nettoyons les espaces. Le HTML comporte souvent de nombreux espaces supplémentaires à des fins de formatage : plusieurs espaces, tabulations, nouvelles lignes. Nous utilisons une expression régulière pour remplacer toute séquence de caractères d’espacement par un seul espace, puis coupons le résultat.

Récupération de l’article complet

Le flux RSS ne nous donne que des résumés, pas le contenu complet de l’article. Pour obtenir le texte complet, nous devons récupérer la page Web de l’article :

public static async Task<string> FetchArticleContentAsync(string url)
{
 using var httpClient = new HttpClient();
 httpClient.DefaultRequestHeaders.Add("User-Agent", "VsFeedLinkedin/1.0");

 try
 {
 return await httpClient.GetStringAsync(url);
 }
 catch (Exception ex)
 {
 Console.WriteLine($"⚠️ Failed to fetch article content: {ex.Message}");
 return string.Empty;
 }
}

C’est simple : nous envoyons une requête HTTP GET à l’URL de l’article et renvoyons la réponse HTML. Nous l’enveloppons dans un try-catch car les requêtes réseau peuvent échouer et nous préférons renvoyer une chaîne vide plutôt que de planter toute l’application.

Création d’une documentation permanente

Pourquoi générer des fichiers Markdown

Chaque fois que nous analysons un article, nous générons un fichier de démarque détaillé documentant cette analyse. Cela répond à plusieurs objectifs.

Premièrement, il crée une archive consultable. Au fil du temps, vous constituerez une collection d’articles analysés. Vous pouvez effectuer une recherche dans ces fichiers pour trouver du contenu antérieur sur des sujets spécifiques.

Deuxièmement, cela assure la transparence. Vous pouvez voir exactement ce que l’IA a généré pour chaque article, y compris l’analyse complète et la publication LinkedIn.

Troisièmement, c’est utile pour le débogage. Si quelque chose ne va pas avec une publication, vous pouvez consulter le fichier de démarque pour comprendre ce qui s’est passé.

La classe du générateur de démarques

public class MarkdownGenerator
{
 private readonly string _outputDirectory;

 public MarkdownGenerator(string outputDirectory)
 {
 _outputDirectory = outputDirectory;

 if (!Directory.Exists(_outputDirectory))
 {
 Directory.CreateDirectory(_outputDirectory);
 }
 }

 public string GenerateMarkdownFile(ArticleAnalysis analysis)
 {
 var sb = new StringBuilder();

 var safeTitle = GenerateSafeFileName(analysis.Title);
 var fileName = $"{analysis.AnalyzedAt:yyyy-MM-dd}_{safeTitle}.md";
 var filePath = Path.Combine(_outputDirectory, fileName);

 sb.AppendLine($"# {analysis.Title}");
 sb.AppendLine();
 sb.AppendLine("## Article Information");
 sb.AppendLine();
 sb.AppendLine($"- **Author:** {analysis.Author}");
 sb.AppendLine($"- **URL:** [{analysis.Url}]({analysis.Url})");
 sb.AppendLine($"- **Published:** {analysis.PublishDate:yyyy-MM-dd}");
 sb.AppendLine($"- **Analyzed:** {analysis.AnalyzedAt:yyyy-MM-dd HH:mm:ss}");
 sb.AppendLine($"- **Tags:** {string.Join(", ", analysis.Tags)}");
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("## AI Analysis");
 sb.AppendLine();
 sb.AppendLine("### Summary");
 sb.AppendLine();
 sb.AppendLine(analysis.Summary);
 sb.AppendLine();
 sb.AppendLine("### Key Topics");
 sb.AppendLine();
 sb.AppendLine(analysis.KeyTopics);
 sb.AppendLine();
 sb.AppendLine("### Relevance for Developers");
 sb.AppendLine();
 sb.AppendLine(analysis.Relevance);
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("## Generated LinkedIn Post");
 sb.AppendLine();
 sb.AppendLine("```");
 sb.AppendLine(analyse.LinkedInPost);
 sb.AppendLine("```");
 sb.AppendLine();
 sb.AppendLine("");
 sb.AppendLine();
 sb.AppendLine("*This analysis was generated using AI (Semantic Kernel with Azure OpenAI)*");

 File.WriteAllText(filePath, sb.ToString());
 return filePath;
 }

Le constructeur prend un chemin de répertoire de sortie et le crée s’il n’existe pas. La méthode GenerateMarkdownFile prend un objet ArticleAnalysis et produit un document markdown bien formaté.

Le nom du fichier comprend la date et une version épurée du titre. Cela facilite le tri chronologique et l’identification des fichiers en un coup d’œil.

Gestion des noms de fichiers dangereux

Les titres d’articles peuvent contenir des caractères qui ne sont pas autorisés dans les noms de fichiers, comme des points, des barres obliques, des points d’interrogation et des guillemets. Nous devons les désinfecter :

private static string GenerateSafeFileName(string title)
{
 var invalidChars = Path.GetInvalidFileNameChars();
 var safeTitle = new string(title
 .Where(c => !invalidChars.Contains(c))
 .ToArray());

 safeTitle = safeTitle.Replace(" ", "-").Replace("--", "-");

 if (safeTitle.Length > 50)
 {
 safeTitle = safeTitle.Substring(0, 50);
 }

 return safeTitle.TrimEnd('-').ToLowerInvariant();
}

Nous utilisons Path.GetInvalidFileNameChars() pour obtenir une liste de caractères qui ne peuvent pas apparaître dans les noms de fichiers sur le système d’exploitation actuel. Nous les filtrons, remplaçons les espaces par des tirets pour plus de lisibilité, limitons la longueur à 50 caractères et convertissons en minuscules pour plus de cohérence.

Configuration des notifications de télégramme

Pourquoi j’ai choisi Telegram

Pour le composant de notification, j’ai envisagé plusieurs options : e-mail, SMS, Slack, Discord et Telegram. J’ai finalement choisi Telegram pour plusieurs raisons.

L’API est entièrement gratuite, sans limite de débit pour une utilisation raisonnable. De nombreux services de notification imposent des limites au nombre de messages que vous pouvez envoyer gratuitement, mais Telegram ne limite pas les messages de robots à des utilisateurs individuels.

L’API du bot est incroyablement simple. Ce ne sont que des requêtes HTTP avec des charges utiles JSON. Aucun flux d’authentification complexe, aucun webhook requis pour les fonctionnalités de base.Telegram fonctionne partout : sur mon téléphone, sur mon bureau, dans mon navigateur Web. Je peux recevoir des notifications où que je sois et répondre immédiatement.

Les messages prennent en charge un formatage riche. Je peux utiliser du texte en gras, en italique et même des blocs de code pour rendre mes notifications plus lisibles.

Création de votre robot Telegram

Configurer un bot Telegram est étonnamment simple. Ouvrez Telegram et recherchez @BotFather – il s’agit du bot officiel de Telegram pour créer et gérer des robots. Démarrez une conversation avec BotFather et envoyez la commande /newbot. BotFather vous demandera un nom pour votre bot (c’est le nom d’affichage) et un nom d’utilisateur (celui-ci doit être unique et se terminer par « bot »). Une fois que vous les aurez fournis, BotFather créera votre bot et vous donnera un jeton API. Ce jeton est comme un mot de passe : gardez-le secret et ne le confiez pas à des référentiels publics.

Pour trouver votre identifiant de chat afin que le bot sache où envoyer des messages, démarrez une conversation avec votre nouveau bot en le recherchant et en appuyant sur Démarrer. Accédez ensuite à l’URL https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates dans votre navigateur ou en utilisant curl. Recherchez l’objet chat dans la réponse – le champ id est votre identifiant de chat.

Envoi de messages via l’API

Voici notre fonction pour envoyer des messages Telegram :

static async Task SendToTelegramAsync(string botToken, string chatId, string message)
{
 using var httpClient = new HttpClient();

 var telegramApiUrl = $"https://api.telegram.org/bot{botToken}/sendMessage";

 var payload = new
 {
 chat_id = chatId,
 text = message,
 parse_mode = "HTML"
 };

 var jsonContent = JsonSerializer.Serialize(payload);
 var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");

 var response = await httpClient.PostAsync(telegramApiUrl, content);

 if (!response.IsSuccessStatusCode)
 {
 var errorContent = await response.Content.ReadAsStringAsync();
 throw new Exception($"Telegram API error: {response.StatusCode} - {errorContent}");
 }
}

L’API Telegram Bot est basée sur REST. Nous envoyons une requête POST au point de terminaison sendMessage avec un corps JSON contenant l’ID de discussion (où envoyer), le texte du message (quoi envoyer) et éventuellement un mode d’analyse (pour le formatage).

Définir parse_mode sur “HTML” nous permet d’utiliser des balises HTML de base dans nos messages – des éléments comme <b>bold</b> et <i>italic</i>. Cela peut rendre les notifications plus lisibles, même si pour notre cas d’utilisation actuel, nous envoyons du texte brut.

Si la requête échoue, nous générons une exception avec des détails sur ce qui n’a pas fonctionné. Cela aide au débogage si quelque chose ne fonctionne pas.

Configuration de l’application

Variables d’environnement

Notre application a besoin de plusieurs informations sensibles : clés API, jetons de bot et URL de point de terminaison. Nous ne devrions jamais les coder en dur ni les soumettre au contrôle de version. Au lieu de cela, nous utilisons des variables d’environnement, qui peuvent être définies de manière sécurisée dans chaque environnement dans lequel l’application s’exécute.

Pour Telegram, nous avons besoin de TELEGRAM_BOT_TOKEN (le jeton que BotFather vous a donné) et de TELEGRAM_CHAT_ID (votre identifiant de chat où les messages doivent être envoyés).

Pour Azure OpenAI, nous avons besoin de AZURE_OPENAI_ENDPOINT (l’URL de votre ressource), AZURE_OPENAI_API_KEY (votre clé API) et AZURE_OPENAI_DEPLOYMENT (le nom de votre modèle déployé, comme « gpt-4o »).

Chargement de la configuration dans le code

Voici comment nous chargeons ces valeurs au démarrage de l’application :

var telegramBotToken = Environment.GetEnvironmentVariable("TELEGRAM_BOT_TOKEN");
var telegramChatId = Environment.GetEnvironmentVariable("TELEGRAM_CHAT_ID");

var azureOpenAiEndpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");
var azureOpenAiKey = Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY");
var azureOpenAiDeployment = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT") ?? "gpt-4o";

var aiAnalysisEnabled = !string.IsNullOrWhiteSpace(azureOpenAiEndpoint) &&
 !string.IsNullOrWhiteSpace(azureOpenAiKey);

Nous utilisons Environment.GetEnvironmentVariable pour lire chaque valeur. Pour le nom du déploiement, nous fournissons la valeur par défaut “gpt-4o” si aucune valeur n’est définie.

Nous vérifions ensuite si l’analyse IA doit être activée en vérifiant que nous disposons à la fois d’un point de terminaison et d’une clé API. Cela permet à l’application de s’exécuter en mode dégradé si Azure OpenAI n’est pas configuré : elle récupérera toujours les flux et suivra les articles, juste sans l’analyse de l’IA.### Dégradation gracieuse

Ce concept de dégradation gracieuse est important. Nous ne voulons pas que l’application plante simplement parce qu’une fonctionnalité facultative n’est pas configurée :

ArticleAnalyzer? articleAnalyzer = null;
MarkdownGenerator? markdownGenerator = null;

if (aiAnalysisEnabled)
{
 Console.WriteLine("🤖 AI Analysis enabled - Using Azure OpenAI with Semantic Kernel");
 articleAnalyzer = new ArticleAnalyzer(azureOpenAiEndpoint!, azureOpenAiKey!, azureOpenAiDeployment);
 markdownGenerator = new MarkdownGenerator(articlesOutputDir);
}
else
{
 Console.WriteLine("ℹ️ AI Analysis disabled - Set AZURE_OPENAI_ENDPOINT and AZURE_OPENAI_API_KEY to enable");
}

Si l’IA est activée, nous créons l’analyseur et le générateur de démarques. Sinon, nous les laissons nuls et ignorons les étapes liées à l’IA lors du traitement. L’application offre toujours de la valeur en récupérant des flux et en envoyant des notifications de base, même sans l’amélioration de l’IA.

Automatisation avec les actions GitHub

Pourquoi les actions GitHub

Le véritable pouvoir de cette solution vient de l’automatisation. Nous ne voulons pas exécuter manuellement l’application toutes les quelques heures – nous voulons qu’elle s’exécute automatiquement en arrière-plan.

GitHub Actions est parfait pour cela. Il est intégré à GitHub, il n’y a donc aucun service supplémentaire à configurer. C’est gratuit pour les référentiels publics et comprend de généreuses minutes gratuites pour les référentiels privés. Il peut s’exécuter selon un calendrier, déclenchant notre application à intervalles réguliers. Il dispose d’une gestion intégrée des secrets pour stocker nos clés API en toute sécurité. Et il peut renvoyer les modifications dans le référentiel, gardant ainsi notre fichier de suivi à jour.

Le fichier de workflow

Créez un fichier sur .github/workflows/fetch-and-notify.yml avec le contenu suivant :

name: Fetch DevBlogs and Notify

on:
 schedule:
 - cron: '0 */6 * * *'
 workflow_dispatch:

jobs:
 fetch-and-notify:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout repository
 uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '9.0.x'

 - name: Restore dependencies
 run: dotnet restore src/VsFeedLinkedin.csproj

 - name: Build
 run: dotnet build src/VsFeedLinkedin.csproj --no-restore

 - name: Run application
 env:
 TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
 TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
 AZURE_OPENAI_ENDPOINT: ${{ secrets.AZURE_OPENAI_ENDPOINT }}
 AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
 AZURE_OPENAI_DEPLOYMENT: ${{ secrets.AZURE_OPENAI_DEPLOYMENT }}
 run: dotnet run --project src/VsFeedLinkedin.csproj

 - name: Commit and push changes
 run: |
 git config user.name "GitHub Actions Bot"
 git config user.email "actions@github.com"

 if [[ -n $(git status --porcelain posted-articles.md generated-posts/) ]]; then
 TIMESTAMP=$(date +%Y%m%d_%H%M%S)
 git add posted-articles.md generated-posts/
 git commit -m "chore($TIMESTAMP): processed new articles"
 git push
 else
 echo "No changes to commit"
 fi

Laissez-moi vous expliquer chaque partie. La section on définit le moment où le flux de travail s’exécute. Le déclencheur de planification utilise la syntaxe cron – 0 */6 * * * signifie « à la minute 0 de toutes les 6 heures ». Ainsi, le flux de travail s’exécute à minuit, 6 heures du matin, midi et 18 heures UTC. Le déclencheur workflow_dispatch permet des exécutions manuelles à partir de l’interface utilisateur GitHub, ce qui est utile pour les tests.

Le travail s’exécute sur Ubuntu-latest, qui est une machine virtuelle Linux. Nous vérifions notre référentiel, configurons .NET 9, restaurons les packages NuGet et construisons le projet.

L’étape Exécuter l’application est l’endroit où la magie opère. Nous transmettons nos secrets sous forme de variables d’environnement en utilisant la syntaxe ${{ secrets.SECRET_NAME }}. Ces secrets sont stockés en toute sécurité dans GitHub et ne sont jamais exposés dans les journaux.

Enfin, nous validons toutes les modifications dans le référentiel. Nous configurons Git avec une identité de bot, vérifions s’il y a des modifications dans notre fichier de suivi ou dans le répertoire des publications générées, et si c’est le cas, créons un commit et le poussons.

Configuration des secrets

Pour ajouter des secrets à votre référentiel GitHub, accédez aux Paramètres de votre référentiel, puis Secrets et variables, puis Actions. Cliquez sur “Nouveau secret du référentiel” et ajoutez chacune de vos variables d’environnement. Les noms doivent correspondre exactement à ce que nous référençons dans le fichier de workflow.

Conclusion

Ce que nous avons construit

En repensant à tout ce que nous avons couvert, nous avons créé un agrégateur de flux RSS complet, alimenté par l’IA, qui automatise ce qui était autrefois un processus manuel fastidieux. L’application surveille automatiquement sept flux Microsoft DevBlogs, capturant chaque nouvel article dès sa publication. Il gère les complexités de la déduplication, en reconnaissant le moment où le même article apparaît dans plusieurs flux.L’analyse IA optimisée par Semantic Kernel et Azure OpenAI lit et comprend le contenu des articles, génère des résumés, identifie les sujets clés et explique la pertinence, le tout automatiquement. Plus important encore, il crée des publications LinkedIn attrayantes que je peux partager avec un minimum de modifications.

L’intégration de Telegram signifie que je suis averti sur mon téléphone chaque fois qu’il y a un nouveau contenu à consulter. Je peux consulter le message, décider si je souhaite le partager et agir immédiatement.

Et comme il s’exécute sur GitHub Actions selon un calendrier, je n’ai pas besoin de me rappeler de faire quoi que ce soit. Le système fonctionne en arrière-plan et je ne m’engage que lorsqu’il y a quelque chose qui mérite d’être partagé.

Les technologies qui ont rendu cela possible

Ce projet a regroupé plusieurs technologies qui ont chacune joué un rôle crucial. .NET 9 a fourni une base solide avec ses fonctionnalités de langage moderne et ses excellentes performances. Semantic Kernel a simplifié l’intégration de l’IA, en gérant toute la complexité des appels d’API et de la gestion des réponses. Azure OpenAI a fourni l’intelligence : la capacité de réellement comprendre et analyser le contenu technique. HtmlAgilityPack a résolu le problème compliqué de l’extraction de texte propre à partir de pages Web. System.ServiceModel.Syndication a facilité l’analyse RSS. L’API Telegram Bot nous a fourni des notifications gratuites et fiables. Et GitHub Actions a tout lié avec une exécution automatisée et planifiée.

Penser aux coûts

Une question que vous pourriez vous poser est la suivante : combien cela coûte-t-il de fonctionner ? La réponse est : pas grand-chose du tout.

Telegram est entièrement gratuit – aucun frais pour l’envoi de messages via votre bot.

GitHub Actions est gratuit pour les référentiels publics. Pour les référentiels privés, vous bénéficiez de 2 000 minutes par mois sur l’offre gratuite, ce qui est plus que suffisant pour notre cas d’utilisation.

Azure OpenAI est le seul composant payant et les coûts sont minimes. Avec GPT-4o, l’analyse d’un article de blog typique coûte entre un et trois centimes. Même si vous traitez des dizaines d’articles par mois, les coûts de l’IA sont inférieurs à un dollar.

Où vous pourriez prendre ceci ensuite

Bien que cette solution réponde parfaitement à mes besoins, il existe de nombreuses façons de l’étendre. Vous pouvez ajouter la prise en charge de plusieurs plateformes sociales – peut-être publier sur Twitter/X, Mastodon ou Bluesky en plus de LinkedIn. Vous pouvez mettre en œuvre une analyse des sentiments pour suivre le ton des articles au fil du temps et repérer les tendances. Vous pouvez autoriser différents modèles d’invites pour différents flux, générant ainsi différents styles de publications pour différents sujets. Vous pouvez créer un tableau de bord Web pour examiner et gérer les publications au lieu d’utiliser Telegram. Vous pouvez suivre les mesures d’engagement pour le contenu publié afin de voir quels sujets trouvent le plus d’écho auprès de votre public.

Réflexions finalesCe que j’aime le plus dans ce projet, c’est qu’il incarne une philosophie à laquelle je crois fermement : l’automatisation doit gérer les parties fastidieuses tout en laissant les parties créatives et décisionnelles aux humains. Le système fait tout le gros du travail – récupérer, analyser, analyser, générer – mais je vérifie toujours tout avant de partager. Les publications générées par l’IA sont des points de départ que je peux personnaliser et personnaliser.

En combinant la puissance de .NET, Semantic Kernel et Azure OpenAI, nous avons créé un outil qui permet d’économiser des heures de travail manuel chaque semaine tout en maintenant la qualité et la cohérence. C’est le genre d’automatisation pratique qui fait une réelle différence dans la vie quotidienne.

Si vous construisez quelque chose de similaire ou si vous avez des idées d’améliorations, j’aimerais en entendre parler. N’hésitez pas à nous contacter sur LinkedIn !

Bon codage et joyeux Noël ! 🎄

Créer des systèmes d'IA multi-agents avec le framework d'agents de Microsoft

Mon, 01 Dec 2025 00:00:00 +0000

##Présentation

Nous sommes entrés dans l’ère des systèmes d’IA multi-agents. Au lieu d’une seule IA monolithique gérant tout, l’industrie s’oriente vers des agents spécialisés qui collaborent pour résoudre des problèmes complexes – un peu comme une équipe d’experts bien organisée. Un agent fait des recherches, un autre analyse, un troisième écrit et un coordinateur maintient tout le monde sur la bonne voie.

Si vous avez travaillé avec de grands modèles de langage, vous avez probablement atteint le plafond de ce qu’une seule invite peut faire. Les fenêtres contextuelles se remplissent, les instructions s’emmêlent et la qualité se dégrade. Les architectures multi-agents résolvent ce problème en décomposant les tâches complexes en responsabilités ciblées, où chaque agent est un expert dans un domaine particulier.

L’Agent Framework de Microsoft, qui fait partie de l’écosystème plus large du noyau sémantique, offre aux développeurs .NET une boîte à outils de premier ordre pour créer exactement ce type de systèmes. Dans cet article, nous passerons de zéro à un pipeline multi-agent pleinement fonctionnel, couvrant les concepts de base, les modèles d’orchestration et le code pratique dont vous avez besoin pour commencer.

Qu’est-ce que l’Agent Framework de Microsoft ?

L’Agent Framework est la réponse de Microsoft à la création, à l’orchestration et au déploiement d’agents IA et de systèmes multi-agents dans .NET. Il s’associe – et s’intègre profondément – au noyau sémantique, qui est le SDK open source de Microsoft pour l’orchestration de l’IA depuis 2023.

Pensez-y de cette façon : Semantic Kernel vous fournit les primitives (noyaux, plugins, mémoire, planificateurs), tandis que Agent Framework vous propose des abstractions de niveau supérieur spécialement conçues pour la communication et la coordination d’agent à agent.

Le framework prend en charge plusieurs fournisseurs de modèles, notamment Azure OpenAI, OpenAI et les modèles hébergés sur Azure AI Foundry. Sa conception est indépendante du modèle mais profondément intégrée à l’écosystème Azure, ce qui la rend particulièrement intéressante pour les scénarios d’entreprise.

Les fonctionnalités clés incluent :

Plusieurs types d’agents : ChatCompletionAgent, OpenAIAssistantAgent et AzureAIAgent pour différents backends
Modèles d’orchestration : workflows séquentiels, simultanés, de transfert et de discussion de groupe
Écosystème de plugins : étendez les agents avec des fonctions C# natives, des spécifications OpenAPI et des outils Model Context Protocol (MCP).
Gestion des conversations : stratégies intégrées de threading, de gestion de l’historique et de terminaison
Observabilité : Intégration avec OpenTelemetry pour le traçage des interactions des agents

Concepts clés

Avant d’écrire du code, établissons le vocabulaire. L’Agent Framework s’articule autour de quelques abstractions principales.

###Agents

Un agent est une entité soutenue par un modèle d’IA, configurée avec des instructions spécifiques (une invite système), un nom et éventuellement un ensemble de plugins ou d’outils. Chaque agent est un spécialiste : vous définissez ce qu’il sait, ce qu’il peut faire et comment il doit se comporter.

ChatCompletionAgentLe type d’agent le plus simple. Il enveloppe un point de terminaison de discussion (Azure OpenAI, OpenAI, etc.) et maintient une conversation. Il est sans état entre les invocations : vous fournissez l’historique et il répond. Cela le rend léger et facile à raisonner.

ChatCompletionAgent agent = new()
{
 Name = "Reviewer",
 Instructions = "You are a senior code reviewer. Analyze the provided code for bugs, security issues, and style violations. Be concise and actionable.",
 Kernel = kernel
};

OuvrirAIAssistantAgent

Ce type d’agent exploite l’API OpenAI Assistants, qui fournit l’état de conversation côté serveur, la gestion des fichiers et l’interprétation du code. Il est plus lourd mais vous offre des threads persistants et des outils intégrés tels que l’interpréteur de code et la recherche de fichiers.

OpenAIAssistantAgent agent = await OpenAIAssistantAgent.CreateAsync(
 clientProvider: clientProvider,
 definition: new OpenAIAssistantDefinition("gpt-4o")
 {
 Name = "DataAnalyst",
 Instructions = "You analyze datasets and produce statistical summaries."
 }
);

AgentGroupChat

C’est l’orchestrateur. AgentGroupChat gère les conversations à plusieurs tours entre plusieurs agents, en contrôlant qui parle ensuite, quand la conversation se termine et comment l’historique est partagé. C’est là que la magie de la collaboration multi-agents opère.

Modèles d’orchestration

Le framework prend en charge quatre modèles d’orchestration principaux, chacun adapté à différents problèmes.

Séquentiel

Les agents s’exécutent les uns après les autres dans un ordre défini. La sortie de l’agent A alimente l’agent B, dont la sortie alimente l’agent C. Ceci est idéal pour les pipelines : brouillon → révision → édition → publication.

// Conceptual flow
var draft = await writerAgent.InvokeAsync("Write a blog post about .NET 9");
var reviewed = await reviewerAgent.InvokeAsync($"Review this: {draft}");
var edited = await editorAgent.InvokeAsync($"Edit based on feedback: {reviewed}");

Concurrent

Plusieurs agents travaillent simultanément sur la même entrée. Vous répartissez le travail, puis regroupez les résultats. Idéal pour obtenir des perspectives diverses, par exemple si trois évaluateurs examinent la même pull request.

Transfert

Un agent décide de transférer le contrôle à un autre agent en fonction du contexte de la conversation. Cela imite le fonctionnement d’une équipe de service client : l’agent de première ligne traite les requêtes de base et les transmet aux spécialistes en cas de besoin.

Discussion de groupe

Plusieurs agents participent à une conversation ouverte, à tour de rôle en fonction d’une stratégie de sélection. La classe AgentGroupChat implémente ce modèle avec une logique de tour de rôle et de terminaison configurable.

Créer votre premier agent

Soyons pratiques. Voici comment créer votre premier agent étape par étape.

Prérequis

Vous aurez besoin de :

SDK .NET 9
Une ressource Azure OpenAI avec un modèle déployé (par exemple, gpt-4o)
Visual Studio ou VS Code

Configuration du projet

Créez une nouvelle application console et installez les packages requis :

dotnet new console -n AgentDemo
cd AgentDemo
dotnet add package Microsoft.SemanticKernel --prerelease
dotnet add package Microsoft.SemanticKernel.Agents.Core --prerelease
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity

Création d’un agent simple

Tout d’abord, configurez le noyau avec votre configuration Azure OpenAI :

using Azure.Identity;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.ChatCompletion;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 credentials: new DefaultAzureCredential()
);

Kernel kernel = builder.Build();

Créez maintenant un agent et invoquez-le :

ChatCompletionAgent agent = new()
{
 Name = "TechWriter",
 Instructions = """
 You are a technical writer specializing in software documentation.
 Write clear, concise content aimed at experienced developers.
 Use code examples when appropriate.
 Always structure your output with headings and bullet points.
 """,
 Kernel = kernel
};

ChatHistory history = new();
history.AddUserMessage("Explain dependency injection in .NET in 200 words.");

await foreach (ChatMessageContent response in agent.InvokeAsync(history))
{
 Console.WriteLine(response.Content);
}

C’est tout. Vous avez un agent qui travaille. Mais le véritable pouvoir vient lorsque les agents travaillent ensemble.

Orchestration multi-agents avec AgentGroupChat

Créons quelque chose de plus intéressant : une discussion de groupe où plusieurs agents collaborent. La classe AgentGroupChat gère le flux de la conversation, y compris qui parle ensuite et quand s’arrêter.

Définir les agents

Nous allons créer trois agents : un rédacteur, un réviseur et un éditeur.

ChatCompletionAgent writer = new()
{
 Name = "Writer",
 Instructions = """
 You are a content writer. When given a topic, produce a well-structured
 draft. Focus on clarity and technical accuracy.
 When you receive feedback from the Reviewer, incorporate it into a
 revised draft.
 """,
 Kernel = kernel
};

ChatCompletionAgent reviewer = new()
{
 Name = "Reviewer",
 Instructions = """
 You are a content reviewer. Analyze drafts for technical accuracy,
 clarity, and completeness. Provide specific, actionable feedback.
 Do NOT rewrite the content — only provide feedback.
 When the content meets your standards, respond with: APPROVED
 """,
 Kernel = kernel
};

ChatCompletionAgent editor = new()
{
 Name = "Editor",
 Instructions = """
 You are an editor. Once content is approved by the Reviewer,
 polish it for grammar, tone, and formatting.
 Output only the final polished version.
 When you have produced the final version, respond with: COMPLETE
 """,
 Kernel = kernel
};

Configuration de la discussion de groupe

Le AgentGroupChat nécessite deux configurations clés : une stratégie de sélection (qui parle ensuite) et une stratégie de terminaison (quand s’arrêter).

AgentGroupChat chat = new(writer, reviewer, editor)
{
 ExecutionSettings = new()
 {
 SelectionStrategy = new SequentialSelectionStrategy(),
 TerminationStrategy = new ApprovalTerminationStrategy()
 {
 Agents = [editor],
 MaximumIterations = 12
 }
 }
};

Stratégie de résiliation personnaliséeLa stratégie de terminaison définit le moment où la conversation se termine. En voici un personnalisé qui recherche le mot-clé « COMPLETE » :

class ApprovalTerminationStrategy : TerminationStrategy
{
 protected override Task<bool> ShouldAgentTerminateAsync(
 Agent agent,
 IReadOnlyList<ChatMessageContent> history,
 CancellationToken cancellationToken = default)
 {
 bool isComplete = history
 .Last()
 .Content?
 .Contains("COMPLETE", StringComparison.OrdinalIgnoreCase) ?? false;

 return Task.FromResult(isComplete);
 }
}

Exécuter la conversation

Lancez la conversation avec un message utilisateur et laissez les agents collaborer :

chat.AddChatMessage(
 new ChatMessageContent(AuthorRole.User,
 "Write a 300-word technical overview of gRPC vs REST for microservices.")
);

await foreach (ChatMessageContent message in chat.InvokeAsync())
{
 Console.WriteLine($"[{message.AuthorName}]: {message.Content}");
 Console.WriteLine("---");
}

Le flux ressemblera à ceci :

Writer produit un brouillon
Le réviseur fournit des commentaires
Writer révise en fonction des commentaires
Le réviseur dit « APPROUVÉ »
Éditeur peaufine et dit “COMPLET”
La conversation se termine

Ce va-et-vient se poursuit automatiquement jusqu’à ce que la condition de terminaison soit remplie ou que MaximumIterations soit atteint.

Plugins et outils

Les agents deviennent véritablement puissants lorsqu’ils peuvent interagir avec des systèmes externes. Agent Framework prend en charge trois mécanismes d’extension principaux.

Fonctions natives (plugins du noyau)

Vous pouvez donner aux agents l’accès aux méthodes C# en tant qu’outils. L’agent appellera ces fonctions lorsqu’il déterminera qu’elles sont nécessaires :

public class ContentToolsPlugin
{
 [KernelFunction("word_count")]
 [Description("Counts the number of words in the provided text.")]
 public int WordCount([Description("The text to count words in")] string text)
 {
 return text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
 }

 [KernelFunction("check_readability")]
 [Description("Calculates a readability score for the given text.")]
 public string CheckReadability([Description("The text to analyze")] string text)
 {
 var words = text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
 var sentences = text.Split(['.', '!', '?'], StringSplitOptions.RemoveEmptyEntries).Length;

 if (sentences == 0) return "Unable to calculate — no sentences found.";

 double avgWordsPerSentence = (double)words / sentences;

 return avgWordsPerSentence switch
 {
 < 15 => $"Easy to read (avg {avgWordsPerSentence:F1} words/sentence)",
 < 25 => $"Moderate difficulty (avg {avgWordsPerSentence:F1} words/sentence)",
 _ => $"Difficult to read (avg {avgWordsPerSentence:F1} words/sentence). Consider shorter sentences."
 };
 }
}

Enregistrez le plugin sur le noyau avant de créer l’agent :

kernel.Plugins.AddFromType<ContentToolsPlugin>();

ChatCompletionAgent analyst = new()
{
 Name = "ContentAnalyst",
 Instructions = "Analyze content using available tools. Report word count and readability.",
 Kernel = kernel,
 Arguments = new KernelArguments(
 new PromptExecutionSettings
 {
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
 })
};

Protocole de contexte de modèle (MCP)

MCP est un standard ouvert permettant de connecter des modèles d’IA à des outils et sources de données externes. Agent Framework prend en charge MCP, ce qui signifie que vos agents peuvent utiliser les outils exposés par n’importe quel serveur compatible MCP. Cela ouvre la porte aux systèmes de fichiers, aux bases de données, aux API et bien plus encore, le tout via une interface standardisée.

// Example: Adding an MCP server for file operations
kernel.Plugins.AddFromMcpServer("filesystem",
 new Uri("http://localhost:3000/mcp"));

C’est particulièrement intéressant car cela signifie que vos agents ne sont pas limités à ce que vous créez : ils peuvent accéder à un écosystème d’outils MCP que d’autres développent et partagent.

Exemple concret : pipeline de révision de contenu

Rassemblons le tout avec un scénario pratique. Imaginez que vous créez un outil interne qui automatise la révision du contenu pour une équipe de documentation. Le pipeline comporte quatre étapes :

Chercheur — Rassemble les informations techniques pertinentes
Écrivain — Produit un brouillon basé sur la recherche
Examinateur — Vérifie l’exactitude et l’exhaustivité
Publisher — Formate et prépare le résultat final

Voici une implémentation condensée :

using Azure.Identity;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.ChatCompletion;

// Build the kernel
var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 credentials: new DefaultAzureCredential()
);
Kernel kernel = builder.Build();

// Define specialized agents
ChatCompletionAgent researcher = new()
{
 Name = "Researcher",
 Instructions = """
 You are a technical researcher. Given a topic, identify the key
 concepts, recent developments, and important details that should
 be covered. Output a structured research brief.
 """,
 Kernel = kernel
};

ChatCompletionAgent writer = new()
{
 Name = "Writer",
 Instructions = """
 You are a technical writer. Using the research brief provided,
 write a comprehensive, well-structured article. Include code
 examples where relevant. Target audience: experienced developers.
 """,
 Kernel = kernel
};

ChatCompletionAgent reviewer = new()
{
 Name = "Reviewer",
 Instructions = """
 You are a senior technical reviewer. Check the article for:
 - Technical accuracy
 - Completeness relative to the research brief
 - Code correctness
 - Clarity and structure
 If everything looks good, respond with APPROVED.
 Otherwise, provide specific feedback for revision.
 """,
 Kernel = kernel
};

ChatCompletionAgent publisher = new()
{
 Name = "Publisher",
 Instructions = """
 You are a content publisher. Once the article is approved,
 format it with proper markdown, add a summary at the top,
 and ensure consistent formatting throughout.
 End your response with COMPLETE.
 """,
 Kernel = kernel
};

// Configure the group chat
AgentGroupChat chat = new(researcher, writer, reviewer, publisher)
{
 ExecutionSettings = new()
 {
 SelectionStrategy = new SequentialSelectionStrategy(),
 TerminationStrategy = new ApprovalTerminationStrategy()
 {
 Agents = [publisher],
 MaximumIterations = 15
 }
 }
};

// Start the pipeline
chat.AddChatMessage(new ChatMessageContent(
 AuthorRole.User,
 "Create a technical article about implementing health checks in ASP.NET Core microservices."
));

await foreach (ChatMessageContent message in chat.InvokeAsync())
{
 Console.ForegroundColor = message.AuthorName switch
 {
 "Researcher" => ConsoleColor.Cyan,
 "Writer" => ConsoleColor.Green,
 "Reviewer" => ConsoleColor.Yellow,
 "Publisher" => ConsoleColor.Magenta,
 _ => ConsoleColor.White
 };

 Console.WriteLine($"\n{'='new string('=', 60)}");
 Console.WriteLine($"[{message.AuthorName}]");
 Console.WriteLine(new string('=', 60));
 Console.WriteLine(message.Content);
}

Console.ResetColor();

Ce pipeline produit un article entièrement recherché, écrit, révisé et formaté, le tout grâce à la collaboration d’agents. Chaque agent se concentre sur ce qu’il fait de mieux et le AgentGroupChat coordonne le flux de travail.

## meilleures pratiques

Après avoir construit plusieurs systèmes multi-agents, voici les modèles et pratiques que j’ai trouvés les plus utiles.

Gestion des erreurs

Définissez toujours MaximumIterations sur votre stratégie de résiliation. Sans cela, les agents peuvent entrer dans des boucles infinies, en particulier lorsqu’un réviseur continue de trouver des problèmes et qu’un rédacteur continue de réviser sans amélioration.

TerminationStrategy = new ApprovalTerminationStrategy()
{
 MaximumIterations = 12 // Safety net
}

Enveloppez les invocations de vos agents dans des blocs try-catch. Les limites de débit des API, les problèmes de réseau et les erreurs de modèle sont autant de réalités des systèmes de production :

try
{
 await foreach (var message in chat.InvokeAsync(cancellationToken))
 {
 // Process messages
 }
}
catch (HttpOperationException ex) when (ex.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
{
 // Implement retry with exponential backoff
 await Task.Delay(TimeSpan.FromSeconds(30), cancellationToken);
}

ObservabilitéAgent Framework s’intègre à OpenTelemetry, ce qui signifie que vous pouvez tracer chaque interaction d’agent, appel d’outil et utilisation de jeton. Ceci est essentiel pour le débogage des flux de travail multi-agents où il n’est pas toujours évident de savoir quel agent a causé le problème.

Configurez la télémétrie de base en ajoutant les packages de télémétrie Semantic Kernel et en configurant votre exportateur préféré (Application Insights, Jaeger, etc.) :

builder.Services.AddOpenTelemetry()
 .WithTracing(tracing =>
 {
 tracing.AddSource("Microsoft.SemanticKernel*");
 tracing.AddOtlpExporter();
 });

Gestion des coûts

Les systèmes multi-agents multiplient vos coûts API : chaque tour d’agent est un appel API, et les discussions de groupe peuvent générer de nombreux tours. Quelques stratégies pour maîtriser les coûts :

Utilisez des modèles moins chers pour les agents plus simples : tous les agents n’ont pas besoin de GPT-4o. Un critique peut fonctionner correctement avec un modèle plus petit, alors que seul l’écrivain a besoin du gros frappeur.
Limiter l’historique : utilisez ReducedHistoryCount dans vos paramètres d’exécution pour limiter la quantité de contexte de conversation que chaque agent reçoit.
Définissez des limites d’itération strictes : évitez les conversations incontrôlables avec des valeurs MaximumIterations raisonnables.
Cache lorsque cela est possible : si un agent effectue la même recherche à plusieurs reprises, mettez les résultats en cache dans un plugin.

Conception d’agents

Gardez les instructions ciblées : chaque agent doit avoir une responsabilité unique et claire. Des instructions générales conduisent à des performances médiocres dans toutes les tâches.
Soyez explicite sur le format de sortie : indiquez aux agents exactement comment structurer leurs réponses. Cela rend l’analyse en aval fiable.
Utiliser des mots-clés de fin : définissez des signaux clairs (comme « APPROUVÉ » ou « COMPLET ») que les agents utilisent pour indiquer qu’ils ont terminé. Cela rend les stratégies de résiliation simples et prévisibles.

Conclusion

Les systèmes d’IA multi-agents représentent un changement fondamental dans la façon dont nous construisons des applications intelligentes. Au lieu de nous battre avec une seule invite pour tout gérer, nous pouvons décomposer les problèmes en rôles spécialisés et laisser les agents collaborer.

L’Agent Framework de Microsoft rend cela pratique pour les développeurs .NET. Les abstractions sont claires – agents, discussions de groupe, stratégies de sélection et de terminaison – et elles se composent naturellement. Combiné avec l’écosystème de plugins de Semantic Kernel et l’hébergement de modèles d’Azure, vous disposez d’une pile complète pour créer des systèmes multi-agents de niveau production.

Le framework est encore en évolution (de nombreux packages sont en avant-première), mais les modèles de base sont solides et la direction est claire. Si vous créez des applications basées sur l’IA dans .NET, le moment est venu de commencer à expérimenter des architectures multi-agents.

Commencez petit : créez deux agents qui collaborent sur une tâche simple. Une fois que vous constaterez l’amélioration de la qualité par rapport aux approches à agent unique, vous souhaiterez tout décomposer en équipes d’agents.

Bon codage !

Rendu du HTML brut dans Blazor avec MarkupString

Sat, 22 Nov 2025 00:00:00 +0000

L’autre jour, je construisais un composant qui devait restituer du HTML provenant d’un CMS. J’avais la chaîne HTML dans une variable et je l’ai simplement déposée dans le modèle comme @myHtml. Et bien sûr, Blazor a échappé à tout et a rendu les balises réelles sous forme de texte sur la page. Pas ce que je voulais.

Le problème

Par défaut, Blazor encode toute chaîne que vous restituez dans un modèle. Alors si vous avez :

@code {
 private string content = "<strong>Hello</strong> <em>world</em>";
}

Et tu fais ceci :

<div>@content</div>

Vous verrez le texte littéral <strong>Hello</strong> <em>world</em> sur la page au lieu de Hello world. Blazor le fait exprès pour empêcher les attaques XSS, ce qui est le bon comportement par défaut.

La solution : MarkupString

Si vous avez réellement besoin de restituer du HTML brut, vous enveloppez votre chaîne dans un MarkupString :

<div>@((MarkupString)content)</div>

Et c’est tout ! Maintenant, Blazor rendra le HTML sous forme de balisage réel. Vous pouvez également l’affecter à une variable :

@code {
 private string rawHtml = "<strong>Hello</strong> <em>world</em>";
 private MarkupString HtmlContent => (MarkupString)rawHtml;
}

<div>@HtmlContent</div>

Un exemple concret

J’extraisais le contenu du blog à partir d’une API et je devais le restituer dans un composant de prévisualisation. Le contenu contenait toutes sortes de HTML : titres, blocs de code, liens, images. Voici à peu près à quoi cela ressemblait :

@inject HttpClient Http

@if (article is not null)
{
 <article>
 <h1>@article.Title</h1>
 <div class="content">
 @((MarkupString)article.HtmlBody)
 </div>
 </article>
}

@code {
 [Parameter]
 public int ArticleId { get; set; }

 private ArticleDto? article;

 protected override async Task OnInitializedAsync()
 {
 article = await Http.GetFromJsonAsync<ArticleDto>($"api/articles/{ArticleId}");
 }
}

Fonctionne parfaitement. Le code HTML de l’API est rendu sous forme de balisage réel.

Soyez prudent avec le contenu non fiable

C’est important : MarkupString ne nettoie pas le code HTML. Il restitue tout ce que vous lui donnez, y compris les balises <script>. Ainsi, si le contenu provient d’une entrée d’utilisateur ou d’une source non fiable, vous devez d’abord le nettoyer.

Il n’y a pas de désinfectant HTML intégré dans Blazor, mais vous pouvez utiliser une bibliothèque comme HtmlSanitizer :

using Ganss.Xss;

@code {
 private HtmlSanitizer sanitizer = new();

 private MarkupString SafeHtml(string html)
 {
 var clean = sanitizer.Sanitize(html);
 return (MarkupString)clean;
 }
}

<div>@SafeHtml(untrustedContent)</div>

Cela supprime les éléments dangereux tels que les gestionnaires <script>, onclick et d’autres éléments que vous ne souhaitez pas rendre à partir du contenu fourni par l’utilisateur.

Quand l’utiliser

J’utilise MarkupString pour :

Contenu CMS ou démarque converti en HTML côté serveur
Sortie de l’éditeur de texte enrichi
Aperçu des modèles d’e-mails
Tout code HTML prédéfini provenant de sources fiables

Pour tout ce qui provient de la saisie de l’utilisateur, nettoyez toujours en premier. Mieux vaut prévenir que guérir.

J’espère que vous avez aimé le message ! N’hésitez pas à me contacter sur tous les réseaux sociaux à @emimontesdeoca.

Ressources

Quoi de neuf dans EF Core 9 : les fonctionnalités que vous devez connaître

Tue, 18 Nov 2025 00:00:00 +0000

Entity Framework Core 9 a été livré avec .NET 9 en novembre 2024, et après avoir passé beaucoup de temps à travailler avec lui sur plusieurs projets, je peux dire que c’est l’une des versions les plus significatives depuis un certain temps. Non pas parce qu’il réinvente la roue, mais parce qu’il peaufine les domaines dans lesquels EF Core a historiquement causé le plus de frictions : la traduction des requêtes, les performances et l’utilisation de modèles de données modernes.

Dans cet article, je passerai en revue les fonctionnalités qui ont eu le plus grand impact sur mon travail quotidien. Si vous utilisez toujours EF Core 8 (ou même 7), cela devrait vous donner une idée claire de ce qui vous attend de l’autre côté de la mise à niveau.

EF Core 9 dans l’écosystème .NET 9

EF Core 9 cible .NET 8 et .NET 9, ce qui signifie que vous n’avez pas nécessairement besoin de mettre à niveau l’intégralité de votre application vers .NET 9 pour profiter de la plupart de ces fonctionnalités. Cela dit, certaines améliorations de l’AOT et des performances sont étroitement liées aux modifications du runtime .NET 9, vous en tirerez donc le meilleur parti en allant jusqu’au bout.

La version suit la cadence impaire/pair établie par Microsoft : les versions impaires (comme .NET 9) bénéficient d’un support à terme standard (STS) avec 18 mois de support, tandis que les versions paires (comme .NET 8) bénéficient d’un support à long terme (LTS). Gardez cela à l’esprit lors de la planification de votre calendrier de mise à niveau.

Améliorations de la traduction LINQ

C’est là que la plupart des développeurs ressentiront immédiatement la différence. EF Core 9 a fait des progrès significatifs dans la traduction d’expressions LINQ en SQL qui ont réellement du sens.

Meilleures traductions GroupBy

Si vous avez déjà écrit une requête GroupBy dans EF Core et que vous vous êtes retrouvé avec des avertissements d’évaluation côté client ou du SQL bizarre, vous connaissez la douleur. EF Core 9 gère un ensemble beaucoup plus large de scénarios GroupBy directement dans SQL.

var salesByCategory = await context.Products
 .GroupBy(p => p.Category.Name)
 .Select(g => new
 {
 Category = g.Key,
 TotalRevenue = g.Sum(p => p.Price * p.UnitsSold),
 AveragePrice = g.Average(p => p.Price),
 ProductCount = g.Count()
 })
 .OrderByDescending(x => x.TotalRevenue)
 .ToListAsync();

Dans les versions précédentes, les requêtes impliquant des agrégations sur les propriétés de navigation à l’intérieur de GroupBy revenaient parfois à l’évaluation du client. EF Core 9 traduit cela proprement en une seule requête SQL avec GROUP BY, SUM, AVG et COUNT.

Projections et sous-requêtes complexes

Les sous-requêtes imbriquées et les projections complexes ont également bénéficié d’une sérieuse mise à niveau. Considérez quelque chose comme ceci :

var orderSummaries = await context.Customers
 .Select(c => new CustomerSummaryDto
 {
 Name = c.FullName,
 TotalOrders = c.Orders.Count(),
 MostRecentOrder = c.Orders
 .OrderByDescending(o => o.OrderDate)
 .Select(o => new OrderBriefDto
 {
 Id = o.Id,
 Date = o.OrderDate,
 Total = o.LineItems.Sum(li => li.Quantity * li.UnitPrice)
 })
 .FirstOrDefault(),
 TopCategory = c.Orders
 .SelectMany(o => o.LineItems)
 .GroupBy(li => li.Product.Category.Name)
 .OrderByDescending(g => g.Count())
 .Select(g => g.Key)
 .FirstOrDefault()
 })
 .ToListAsync();

EF Core 9 peut désormais traduire l’intégralité de cette expression en SQL sans déclencher une évaluation côté client. La requête générée utilise des sous-requêtes corrélées et des jointures latérales, le cas échéant, et le plan SQL est considérablement plus efficace que ce que produisaient les versions antérieures.

Collections primitives paramétrées

L’une des améliorations remarquables de LINQ est la possibilité de transmettre des collections de valeurs primitives directement dans les requêtes :

var statusFilter = new List<string> { "Active", "Pending", "Review" };

var filteredOrders = await context.Orders
 .Where(o => statusFilter.Contains(o.Status))
 .ToListAsync();

Dans EF Core 8, cela a été traduit à l’aide de clauses IN avec des valeurs intégrées, ce qui signifiait que le cache du plan de requête ne pouvait pas être réutilisé lorsque la liste était modifiée. EF Core 9 paramétre correctement ces collections, en les envoyant sous forme de paramètre structuré. C’est un gros problème pour la mise en cache du plan de requête sur SQL Server et PostgreSQL.## Opérations groupées – ExecuteUpdate et ExecuteDelete

ExecuteUpdate et ExecuteDelete ont été introduits dans EF Core 7, mais EF Core 9 étend ce que vous pouvez en faire de manière significative.

Expressions de mise à jour plus complexes

Vous pouvez désormais utiliser des expressions plus complexes dans ExecuteUpdate, y compris des références à d’autres tables via les propriétés de navigation :

await context.Products
 .Where(p => p.Category.IsDiscontinued)
 .ExecuteUpdateAsync(setters => setters
 .SetProperty(p => p.IsAvailable, false)
 .SetProperty(p => p.DiscontinuedDate, DateTimeOffset.UtcNow)
 .SetProperty(p => p.Price, p => p.Price * 0.5m));

Cela génère une seule instruction UPDATE avec un JOIN dans la table des catégories — pas besoin de charger des entités en mémoire, pas de surcharge de suivi des modifications.

Suppressions groupées conditionnelles avec sous-requêtes

Les suppressions groupées avec des filtres de sous-requête sont désormais entièrement prises en charge :

await context.AuditLogs
 .Where(log => log.CreatedAt < DateTime.UtcNow.AddYears(-2))
 .Where(log => !context.ProtectedRecords
 .Any(pr => pr.AuditLogId == log.Id))
 .ExecuteDeleteAsync();

Cela se traduit par un DELETE avec une sous-requête NOT EXISTS, exactement ce que vous écririez à la main. Aucune entité chargée, aucun aller-retour.

Améliorations des colonnes JSON

Les colonnes JSON sont l’une des fonctionnalités les plus intéressantes des récentes versions d’EF Core, et EF Core 9 les pousse encore plus loin.

Interrogation dans JSON

Vous pouvez désormais filtrer et projeter des données à partir de colonnes JSON avec une meilleure prise en charge de la traduction :

public class Order
{
 public int Id { get; set; }
 public string CustomerName { get; set; }
 public ShippingAddress Address { get; set; } // Stored as JSON
 public List<OrderNote> Notes { get; set; } // Stored as JSON
}

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

public class OrderNote
{
 public DateTime CreatedAt { get; set; }
 public string Text { get; set; }
 public string Author { get; set; }
}

Configuration dans votre DbContext :

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Order>(builder =>
 {
 builder.OwnsOne(o => o.Address, ab =>
 {
 ab.ToJson();
 });

 builder.OwnsMany(o => o.Notes, nb =>
 {
 nb.ToJson();
 });
 });
}

Vous pouvez désormais interroger directement dans JSON :

var newYorkOrders = await context.Orders
 .Where(o => o.Address.State == "NY")
 .OrderByDescending(o => o.Notes.Count)
 .Select(o => new
 {
 o.CustomerName,
 o.Address.City,
 LatestNote = o.Notes
 .OrderByDescending(n => n.CreatedAt)
 .Select(n => n.Text)
 .FirstOrDefault()
 })
 .ToListAsync();

EF Core 9 génère des appels JSON_VALUE et JSON_QUERY appropriés sur SQL Server (ou équivalent sur d’autres fournisseurs), et la traduction couvre une gamme beaucoup plus large d’opérations LINQ sur les éléments JSON qu’auparavant.

Mise à jour des propriétés JSON

L’un des points de friction dans EF Core 8 était que la mise à jour d’une seule propriété dans une colonne JSON entraînerait la réécriture de l’intégralité du document JSON. EF Core 9 améliore cela avec un suivi des modifications plus granulaire pour les types mappés JSON, générant des mises à jour plus ciblées lorsque cela est possible.

var order = await context.Orders.FindAsync(orderId);
order.Address.ZipCode = "10001";
await context.SaveChangesAsync();

Sur les fournisseurs pris en charge, cela peut générer une modification JSON plus ciblée plutôt que de réécrire l’intégralité du blob.

Types complexes — Objets de valeur sans identité

Les types complexes sont l’une des fonctionnalités attendues par les praticiens du Domain-Driven Design. Contrairement aux types détenus, les types complexes n’ont pas d’identité : ce sont de purs objets de valeur.

[ComplexType]
public record Money(decimal Amount, string Currency);

[ComplexType]
public record DateRange(DateTime Start, DateTime End);

public class Project
{
 public int Id { get; set; }
 public string Name { get; set; }
 public Money Budget { get; set; }
 public DateRange Timeline { get; set; }
}

Ceux-ci sont stockés sous forme de colonnes aplaties dans la table parent — Budget_Amount, Budget_Currency, Timeline_Start, Timeline_End — sans nécessiter de table séparée ni aucun type de clé.

La principale différence avec les types détenus : les types complexes sont comparés par valeur et non par référence. Deux instances de Money avec les mêmes Amount et Currency sont considérées comme égales, quelle que soit l’entité à laquelle elles appartiennent.

var expensiveProjects = await context.Projects
 .Where(p => p.Budget.Amount > 100_000m && p.Budget.Currency == "USD")
 .OrderByDescending(p => p.Budget.Amount)
 .ToListAsync();

Cela se traduit directement par un filtrage sur les colonnes aplaties : propre, efficace et exactement ce à quoi vous vous attendez.

Prise en charge de HierarchyId pour SQL Server

Si vous avez déjà travaillé avec des données hiérarchiques dans SQL Server (organigrammes, arborescences de catégories, systèmes de fichiers), vous savez que HierarchyId est le type intégré pour cela. EF Core 9 lui apporte un support de première classe.

public class Employee
{
 public int Id { get; set; }
 public string Name { get; set; }
 public string Title { get; set; }
 public HierarchyId PathFromCeo { get; set; }
}

Vous pouvez désormais interroger directement les relations hiérarchiques :

var managerId = HierarchyId.Parse("/1/3/");

// All direct and indirect reports
var allReports = await context.Employees
 .Where(e => e.PathFromCeo.IsDescendantOf(managerId))
 .Where(e => e.PathFromCeo != managerId) // exclude the manager
 .OrderBy(e => e.PathFromCeo)
 .ToListAsync();

// Direct reports only (one level down)
var directReports = await context.Employees
 .Where(e => e.PathFromCeo.GetAncestor(1) == managerId)
 .ToListAsync();

// Get an employee's depth in the hierarchy
var employeesWithDepth = await context.Employees
 .Select(e => new
 {
 e.Name,
 e.Title,
 Level = e.PathFromCeo.GetLevel()
 })
 .OrderBy(e => e.Level)
 .ToListAsync();
```Tous ces éléments se traduisent par les méthodes `HierarchyId` natives de SQL Server. Si vous avez implémenté des structures arborescentes avec des clés étrangères auto-référencées et des CTE récursives, il s'agit d'une approche beaucoup plus propre.

## Modèles compilés et prise en charge AOT

Les développeurs soucieux des performances apprécieront l'investissement continu dans les modèles compilés et la prise en charge de la compilation anticipée (AOT).

### Modèles compilés

Les modèles compilés prégénérent les métadonnées du modèle qu’EF Core génère normalement au démarrage. Pour les grands modèles (pensez à des centaines d’entités), cela peut réduire considérablement le temps de démarrage à froid.

```bash
dotnet ef dbcontext optimize --output-dir CompiledModels --namespace MyApp.CompiledModels

Puis câblez-le :

builder.Services.AddDbContext<AppDbContext>(options =>
 options
 .UseSqlServer(connectionString)
 .UseModel(MyApp.CompiledModels.AppDbContextModel.Instance));

Dans EF Core 9, les modèles compilés sont plus complets : ils prennent en charge davantage de fonctionnalités de mappage et génèrent une sortie plus petite. Pour un modèle comportant environ 400 entités, le temps de démarrage peut passer de quelques secondes à quasi-instantané.

Progression de la compilation AOT

La prise en charge native complète de l’AOT pour EF Core est toujours en cours, mais EF Core 9 fait des progrès significatifs. De nombreux chemins de code nécessitant beaucoup de réflexion ont été refactorisés pour être faciles à découper, et les modèles compilés sont un élément clé de l’histoire d’AOT. Si vous ciblez des scénarios comme Azure Functions ou des microservices où le démarrage à froid est important, ces améliorations sont directement pertinentes.

Mises à jour du fournisseur Cosmos DB

Le fournisseur Azure Cosmos DB continue de mûrir avec EF Core 9. Quelques améliorations notables :

Gestion des clés de partition

Le fournisseur prend désormais en charge les clés de partition hiérarchiques et gère les filtres de clés de partition de manière plus intelligente :

public class TenantDocument
{
 public string Id { get; set; }
 public string TenantId { get; set; } // Partition key
 public string Region { get; set; } // Sub-partition key
 public string Content { get; set; }
}

// This query now correctly uses the partition key for routing
var docs = await context.TenantDocuments
 .Where(d => d.TenantId == "tenant-42" && d.Region == "us-east")
 .Where(d => d.Content.Contains("important"))
 .ToListAsync();

Traduction améliorée de LINQ vers NoSQL

Un plus grand nombre d’opérations LINQ se traduisent désormais dans le dialecte SQL de Cosmos DB, notamment une meilleure prise en charge de Contains, Any, des opérations sur tableaux imbriqués et des fonctions mathématiques. Les requêtes qui revenaient auparavant à l’évaluation du client sont désormais traitées côté serveur.

Prise en charge de la recherche de vecteurs

EF Core 9 introduit une prise en charge anticipée de la recherche de similarité vectorielle avec Cosmos DB, ce qui est utile si vous créez des applications qui s’intègrent aux intégrations ou à la recherche basée sur l’IA :

var results = await context.Documents
 .OrderBy(d => EF.Functions.VectorDistance(d.Embedding, queryVector))
 .Take(10)
 .ToListAsync();

## Améliorations de la migration

Les migrations ont bénéficié d’améliorations en matière de qualité de vie qui rendent leur utilisation moins pénible dans des environnements d’équipe.

Tables temporelles dans les migrations

Les migrations gèrent désormais la configuration des tables temporelles de manière plus gracieuse, avec une prise en charge appropriée des colonnes de période et de la dénomination des tables d’historique :

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 modelBuilder.Entity<Employee>()
 .ToTable("Employees", b => b.IsTemporal(t =>
 {
 t.HasPeriodStart("ValidFrom");
 t.HasPeriodEnd("ValidTo");
 t.UseHistoryTable("EmployeeHistory");
 }));
}

Scripts idempotents

La commande Script-Migration (et son équivalent CLI) produit par défaut de meilleurs scripts idempotents, avec une gestion améliorée des cas extrêmes autour des modifications de schéma qui dépendent des données existantes dans certains états.

Offres groupées de migration

Les bundles de migration, qui regroupent vos migrations dans un exécutable autonome pour le déploiement, sont plus fiables dans EF Core 9 avec un meilleur rapport d’erreurs et une logique de nouvelle tentative pour les échecs transitoires.

dotnet ef migrations bundle --self-contained -r linux-x64

Cela produit un binaire que vous pouvez exécuter dans votre pipeline CI/CD sans avoir besoin du SDK .NET installé sur votre cible de déploiement.

## Benchmarks de performancesVoici quelques repères approximatifs issus de mes propres tests. Il s’agit d’un projet comprenant environ 200 entités, exécuté sur SQL Server 2022, mesuré avec BenchmarkDotNet. Vos chiffres varieront, mais les améliorations relatives devraient être similaires.

Scénario	EF Core 8	EF Core 9	Amélioration
Construction du modèle (démarrage à froid)	1 850 ms	320 ms	~5,8x plus rapide (compilé)
Requête simple (entité unique par PK)	0,42 ms	0,38 ms	~10 % plus rapide
Requête complexe (jointures + agrégation)	3,1 ms	2,4 ms	~23 % plus rapide
Mise à jour groupée (10 000 lignes)	145 ms	118 ms	~19 % plus rapide
Requête de colonne JSON	2,8 ms	1,9 ms	~32% plus rapide
SaveChanges (100 entités)	48 ms	41 ms	~15 % plus rapide

L’amélioration du modèle compilé est la plus spectaculaire, mais les améliorations constantes à tous les niveaux s’additionnent, en particulier dans les scénarios à haut débit où vous exécutez des milliers de requêtes par seconde.

Mise à niveau depuis EF Core 8

Si vous utilisez EF Core 8, le chemin de mise à niveau est relativement fluide. Voici une liste de contrôle :

1. Mettez à jour vos forfaits :

<PackageReference Include="Microsoft.EntityFrameworkCore" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="9.0.0" />

2. Vérifiez les modifications majeures. La liste d’EF Core 9 est relativement courte par rapport à certaines versions précédentes. Les plus notables :

Certaines API précédemment obsolètes ont été supprimées
Modifications dans la façon dont certaines requêtes GroupBy sont traduites (elles passent désormais côté serveur, ce qui change le comportement si vous comptiez sur l’évaluation du client)
Modifications mineures dans la sortie de l’échafaudage de migration

3. Regénérez les modèles compilés si vous les utilisez. Le format a changé, donc les anciens modèles compilés ne fonctionneront pas avec EF Core 9.

4. Exécutez votre suite de tests. Portez une attention particulière aux requêtes qui ont été précédemment évaluées sur le client : elles peuvent désormais être évaluées sur le serveur, ce qui est généralement meilleur mais peut faire apparaître des différences de données.

5. Vérifiez vos requêtes Cosmos DB si vous utilisez ce fournisseur. Les traductions améliorées signifient que certaines requêtes s’exécuteront différemment (généralement plus rapidement), mais il vaut la peine de vérifier que les résultats sont identiques.

Une mise à niveau minimale pour un projet typique ressemble à ceci :

dotnet add package Microsoft.EntityFrameworkCore --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.Design --version 9.0.0
dotnet build
dotnet test

Si tout se compile et que les tests réussissent, vous êtes probablement en bonne forme. Si vous rencontrez des problèmes, la documentation sur les modifications avec rupture d’EF Core 9 contient des conseils de migration détaillés pour chaque modification.

Conclusion

EF Core 9 n’est pas une version révolutionnaire, c’est une version évolutive, et c’est exactement ce qu’elle devait être. Les améliorations de LINQ justifient à elles seules la mise à niveau pour la plupart des projets, et des fonctionnalités telles que les améliorations des colonnes JSON, les types complexes et la prise en charge de HierarchyId ouvrent des modèles qui étaient auparavant gênants ou impossibles.

Si je devais retenir les trois fonctionnalités qui ont eu le plus d’impact sur mes projets :

Collections primitives paramétrées — parce que l’efficacité du cache du plan de requête est importante à grande échelle
Améliorations des colonnes JSON — parce que le modèle de document relationnel hybride est incroyablement utile
Modèles compilés — car le temps de démarrage affecte directement la productivité des développeurs et la vitesse de déploiementL’équipe EF Core est sur une trajectoire solide depuis EF Core 5, et la version 9 poursuit cette tendance. Si vous utilisez déjà EF Core 8, la mise à niveau est à faible risque et très rémunératrice. Si vous utilisez quelque chose de plus ancien, il n’y a jamais eu de meilleur moment pour faire le saut.

Bon codage – et bonnes requêtes.

Premiers pas avec le noyau sémantique : orchestration de l'IA en C#

Sun, 05 Oct 2025 00:00:00 +0000

Si vous avez créé des applications .NET et observé l’évolution du paysage de l’IA, vous vous êtes probablement demandé : quel est le meilleur moyen d’intégrer de grands modèles de langage dans mes projets C# sans transformer ma base de code en spaghetti ? C’est exactement le problème que le noyau sémantique de Microsoft résout, et après avoir passé l’année dernière à créer des applications de production avec lui, je peux vous dire qu’il est devenu l’un des outils les plus importants de ma boîte à outils de développement.

Dans cet article, je vais vous expliquer tout ce dont vous avez besoin pour démarrer avec Semantic Kernel, de la compréhension des concepts de base à la création d’un assistant d’IA du monde réel. Que vous vous lancez simplement dans le développement de l’IA ou que vous recherchiez un moyen structuré d’orchestrer les appels LLM dans vos applications .NET existantes, ce guide est là pour vous.

Qu’est-ce que le noyau sémantique ?

Semantic Kernel (SK) est un SDK open source de Microsoft qui agit comme une couche d’orchestration entre le code de votre application et les grands modèles de langage comme GPT-4o, Azure OpenAI ou d’autres services d’IA. Considérez-le comme un middleware léger qui vous permet de combiner le code C# traditionnel avec des capacités d’IA de manière propre et composable.

Mais pourquoi ne pas simplement appeler directement l’API OpenAI ? Vous pouvez tout à fait le faire – et pour les cas d’utilisation simples, c’est très bien. Mais à ce moment-là, vous devez :

Laissez l’IA décider quelles fonctions appeler en fonction de la saisie de l’utilisateur
Combinez plusieurs appels IA avec du code traditionnel dans un pipeline
Ajoutez de la mémoire et du contexte pour que l’IA se souvienne des interactions précédentes
Créez des agents en plusieurs étapes qui raisonnent à travers des tâches complexes

… vous vous retrouverez à réinventer la roue. Semantic Kernel vous offre tout cela immédiatement, avec une prise en charge .NET de première classe, une intégration par injection de dépendances et une architecture de plugin qui semble naturelle à tout développeur C#.

Le projet réside sur GitHub sous le référentiel microsoft/semantic-kernel et dispose de SDK pour C#, Python et Java. Le SDK C# est le plus mature et c’est celui sur lequel nous nous concentrerons ici.

Concepts de base

Avant d’écrire du code, comprenons les éléments constitutifs.

Le noyau

Le Kernel est l’objet central du noyau sémantique. C’est l’orchestrateur, l’élément qui relie vos services d’IA, vos plugins et votre configuration. Vous en créez un, vous y enregistrez vos services et plugins, puis vous l’utilisez pour exécuter des invites ou appeler des fonctions. Si vous êtes familier avec l’injection de dépendances dans ASP.NET Core, le noyau vous semblera très familier : il s’agit essentiellement d’un conteneur de services doté de super pouvoirs d’IA.

Plugins et fonctions

Un plugin est un ensemble de fonctions associées que le noyau peut invoquer. Les fonctions sont disponibles en deux versions :

Fonctions d’invite — définies comme des modèles en langage naturel envoyés au LLM
Fonctions natives — méthodes C# classiques décorées d’attributs que le noyau peut découvrir et appeler

Par exemple, vous pourriez avoir un WeatherPlugin avec une fonction native GetCurrentWeather(string city) et une fonction d’invite qui résume les données météorologiques de manière conviviale.### Connecteurs IA

Les connecteurs permettent au noyau sémantique de communiquer avec les services d’IA. Les plus courants sont :

AzureOpenAIChatCompletion — pour Azure OpenAI Service
OpenAIChatCompletion — pour l’API d’OpenAI directement
Intégration de connecteurs pour la recherche vectorielle et la mémoire

Vous les enregistrez sur le noyau au démarrage, et tout le reste fonctionne.

Configurer votre projet

Mettons-nous les mains dans le cambouis. Commencez par créer une nouvelle application console :

dotnet new console -n SemanticKernelDemo
cd SemanticKernelDemo

Ajoutez maintenant les packages Semantic Kernel NuGet :

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Connectors.AzureOpenAI

Si vous utilisez OpenAI directement au lieu d’Azure OpenAI :

dotnet add package Microsoft.SemanticKernel.Connectors.OpenAI

Pour la prise en charge de la mémoire et des intégrations (nous l’utiliserons plus tard) :

dotnet add package Microsoft.SemanticKernel.Plugins.Memory
dotnet add package Microsoft.Extensions.VectorData.Abstractions

Votre .csproj doit cibler .NET 8 ou version ultérieure. Les dernières versions de Semantic Kernel tirent pleinement parti des fonctionnalités modernes de .NET.

Votre premier noyau

Commençons par l’exemple le plus simple possible : créer un noyau, le connecter à un service d’IA et lui poser une question.

using Microsoft.SemanticKernel;

// Build the kernel with Azure OpenAI
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

var kernel = builder.Build();

// Invoke a simple prompt
var result = await kernel.InvokePromptAsync(
 "Explain dependency injection in C# in three sentences."
);

Console.WriteLine(result);

Si vous utilisez OpenAI directement, échangez l’enregistrement du service :

builder.AddOpenAIChatCompletion(
 modelId: "gpt-4o",
 apiKey: "your-openai-api-key"
);

C’est tout. Exécutez-le et vous obtiendrez une explication concise de l’injection de dépendances. Mais cela ne fait qu’effleurer la surface.

Utilisation de modèles d’invite

Les modèles d’invites vous permettent de paramétrer vos invites avec des variables en utilisant la syntaxe de style guidon :

var prompt = """
 You are a technical writer. Write a brief summary of {{$topic}}
 aimed at developers with {{$experienceLevel}} experience.
 Keep it under 200 words.
 """;

var function = kernel.CreateFunctionFromPrompt(prompt);

var arguments = new KernelArguments
{
 ["topic"] = "gRPC in .NET",
 ["experienceLevel"] = "intermediate"
};

var result = await kernel.InvokeAsync(function, arguments);
Console.WriteLine(result);

C’est là que le noyau sémantique commence à briller : vous pouvez définir des modèles d’invites réutilisables, les versionner et les composer dans des flux de travail plus vastes.

Plugins et fonctions natives

Les plugins sont l’endroit où Semantic Kernel comble le fossé entre l’IA et votre code C# existant. Une fonction native n’est qu’une méthode standard que vous exposez au noyau.

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class TimePlugin
{
 [KernelFunction("get_current_time")]
 [Description("Gets the current date and time in UTC")]
 public string GetCurrentTime()
 {
 return DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss UTC");
 }

 [KernelFunction("get_time_in_timezone")]
 [Description("Gets the current time in a specific timezone")]
 public string GetTimeInTimezone(
 [Description("The IANA timezone identifier, e.g. 'America/New_York'")] string timezone)
 {
 var tz = TimeZoneInfo.FindSystemTimeZoneById(timezone);
 var time = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz);
 return time.ToString("yyyy-MM-dd HH:mm:ss");
 }
}

Notez les attributs [KernelFunction] et [Description]. Celles-ci sont essentielles : les descriptions sont ce que l’IA lit pour comprendre quand et comment appeler vos fonctions. De bonnes descriptions font la différence entre une IA qui utilise efficacement vos outils et une IA confuse.

Enregistrez le plugin sur votre noyau :

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromType<TimePlugin>();

var kernel = builder.Build();

Vous pouvez également créer des plugins plus complexes qui injectent des services. Puisque Semantic Kernel s’intègre à Microsoft.Extensions.DependencyInjection, vos plugins peuvent recevoir des dépendances de constructeur comme n’importe quel autre service :

public class OrderPlugin
{
 private readonly IOrderRepository _repository;

 public OrderPlugin(IOrderRepository repository)
 {
 _repository = repository;
 }

 [KernelFunction("get_order_status")]
 [Description("Retrieves the status of an order by its ID")]
 public async Task<string> GetOrderStatus(
 [Description("The order ID to look up")] string orderId)
 {
 var order = await _repository.GetByIdAsync(orderId);
 return order is null
 ? $"No order found with ID {orderId}"
 : $"Order {orderId}: {order.Status}, placed on {order.CreatedAt:d}";
 }
}

Appel de fonction et invocation automatique

C’est là que les choses deviennent vraiment intéressantes. Avec l’appel de fonction (également appelé appel d’outil), vous laissez le modèle d’IA décider laquelle de vos fonctions enregistrées appeler en fonction du contexte de la conversation. Le modèle n’exécute pas de code : il renvoie une requête structurée indiquant “Je veux appeler la fonction X avec ces arguments”, et le noyau gère l’invocation proprement dite.

Voici comment activer l’appel automatique de fonction :

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.OpenAI;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromType<TimePlugin>();
builder.Plugins.AddFromType<WeatherPlugin>();

var kernel = builder.Build();

// Enable automatic function calling
var settings = new OpenAIPromptExecutionSettings
{
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};

var result = await kernel.InvokePromptAsync(
 "What time is it in Tokyo and what's the weather like there?",
 new KernelArguments(settings)
);

Console.WriteLine(result);

Avec FunctionChoiceBehavior.Auto(), le noyau va :

Envoyez votre invite à l’IA avec des descriptions de toutes les fonctions disponibles
L’IA décide qu’elle doit appeler get_time_in_timezone et get_weather
Le noyau exécute automatiquement ces fonctions
Les résultats sont renvoyés à l’IA
L’IA compose une réponse en langage naturel en utilisant les résultats de la fonctionCette boucle peut se produire plusieurs fois au cours d’un seul appel : l’IA peut appeler plusieurs fonctions en séquence pour rassembler toutes les informations dont elle a besoin. Vous pouvez également utiliser FunctionChoiceBehavior.Required() pour forcer l’IA à appeler au moins une fonction, ou fournir une liste spécifique de fonctions qu’elle est autorisée à utiliser.

Fin du chat avec historique

Pour les applications conversationnelles, vous souhaiterez utiliser le ChatCompletionService directement avec un objet ChatHistory :

using Microsoft.SemanticKernel.ChatCompletion;

var chatService = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory();

history.AddSystemMessage("""
 You are a helpful developer assistant. You have access to tools
 for checking the time and weather. Be concise and friendly.
 """);

while (true)
{
 Console.Write("You: ");
 var input = Console.ReadLine();
 if (string.IsNullOrWhiteSpace(input)) break;

 history.AddUserMessage(input);

 var response = await chatService.GetChatMessageContentAsync(
 history,
 executionSettings: settings,
 kernel: kernel
 );

 history.AddAssistantMessage(response.Content ?? "");
 Console.WriteLine($"Assistant: {response.Content}");
}

Cela vous donne un chatbot entièrement interactif qui conserve l’historique des conversations et peut appeler vos plugins si nécessaire.

Mémoire et intégrations

L’un des modèles les plus puissants dans les applications d’IA est la Génération augmentée par récupération (RAG) : elle permet à l’IA d’accéder à vos propres données en les intégrant dans l’espace vectoriel et en récupérant les morceaux pertinents au moment de la requête.

Semantic Kernel fournit des abstractions pour travailler avec des magasins de vecteurs et des intégrations. Voici comment configurer un magasin de vecteurs en mémoire pour le développement :

using Microsoft.Extensions.VectorData;
using Microsoft.SemanticKernel.Connectors.AzureOpenAI;
using Microsoft.SemanticKernel.Embeddings;

#pragma warning disable SKEXP0010

// Create an embedding generation service
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAITextEmbeddingGeneration(
 deploymentName: "text-embedding-ada-002",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

var kernel = builder.Build();
var embeddingService = kernel.GetRequiredService<ITextEmbeddingGenerationService>();

// Generate embeddings for your documents
var documents = new[]
{
 "Semantic Kernel is an open-source SDK for AI orchestration.",
 "Azure OpenAI provides enterprise-grade AI models.",
 "Plugins in SK allow you to expose C# methods to AI models."
};

var embeddings = await embeddingService.GenerateEmbeddingsAsync(documents);

Pour les scénarios de production, vous stockeriez ces intégrations dans une base de données vectorielles dédiée comme Azure AI Search, Qdrant ou Pinecone. Le noyau sémantique a des connecteurs pour tout cela via les abstractions Microsoft.Extensions.VectorData .

Un flux RAG typique ressemble à ceci :

Ingérer : regroupez vos documents, générez des intégrations, stockez-les dans une base de données vectorielle
Récupérer : lorsqu’un utilisateur pose une question, intégrez la requête et recherchez les documents les plus similaires
Générer : Transmettez les documents récupérés comme contexte au LLM avec la question de l’utilisateur

[KernelFunction("search_knowledge_base")]
[Description("Searches the internal knowledge base for relevant information")]
public async Task<string> SearchKnowledgeBase(
 [Description("The search query")] string query)
{
 var queryEmbedding = await _embeddingService.GenerateEmbeddingAsync(query);

 var results = await _vectorStore.SearchAsync(queryEmbedding, limit: 3);

 return string.Join("\n\n", results.Select(r => r.Text));
}

En exposant votre pipeline RAG en tant que fonction du noyau, l’IA peut décider automatiquement quand elle doit effectuer une recherche dans votre base de connaissances, gardant ainsi l’orchestration propre et laissant le modèle faire ce qu’il fait de mieux.

Planificateurs et agents

À mesure que vos applications d’IA deviennent plus complexes, vous aurez besoin de l’IA pour planifier et exécuter des tâches en plusieurs étapes. C’est là qu’intervient le cadre d’agent de Semantic Kernel.

Les bases : agent de complétion de chat

Le type d’agent le plus simple enveloppe un modèle de complétion de chat avec des instructions et des plugins :

using Microsoft.SemanticKernel.Agents;

#pragma warning disable SKEXP0110

var agent = new ChatCompletionAgent
{
 Name = "DevAssistant",
 Instructions = """
 You are a senior .NET developer assistant. Help users with code
 reviews, architecture decisions, and debugging. Always provide
 code examples when relevant. Use your available tools to look up
 current information when needed.
 """,
 Kernel = kernel,
 Arguments = new KernelArguments(settings)
};

var history = new ChatHistory();

history.AddUserMessage("How should I structure a clean architecture project in .NET 8?");

await foreach (var message in agent.InvokeAsync(history))
{
 Console.WriteLine(message.Content);
 history.Add(message);
}

Collaboration multi-agents

Là où les choses deviennent vraiment puissantes, c’est lorsque vous avez plusieurs agents travaillant ensemble. Semantic Kernel prend en charge les modèles de discussion de groupe dans lesquels des agents de différentes spécialisations collaborent :

#pragma warning disable SKEXP0110

var codeReviewer = new ChatCompletionAgent
{
 Name = "CodeReviewer",
 Instructions = """
 You review C# code for bugs, performance issues, and best practices.
 Be specific about what you find and suggest concrete fixes.
 """,
 Kernel = kernel
};

var securityAuditor = new ChatCompletionAgent
{
 Name = "SecurityAuditor",
 Instructions = """
 You focus exclusively on security vulnerabilities in code.
 Look for injection attacks, authentication issues, data exposure,
 and OWASP Top 10 violations.
 """,
 Kernel = kernel
};

var groupChat = new AgentGroupChat(codeReviewer, securityAuditor)
{
 ExecutionSettings = new AgentGroupChatSettings
 {
 TerminationStrategy = new MaximumIterationTerminationStrategy(4)
 }
};

groupChat.AddChatMessage(
 new ChatMessageContent(AuthorRole.User, "Review this code: ...")
);

await foreach (var message in groupChat.InvokeAsync())
{
 Console.WriteLine($"[{message.AuthorName}]: {message.Content}");
}

Ce modèle est incroyablement utile pour les tâches complexes où différentes perspectives ou domaines d’expertise doivent intervenir. Chaque agent fonctionne avec sa propre invite système et peut disposer de son propre ensemble de plugins.

Exemple concret : création d’un assistant de documentation de projet

Relions le tout avec un exemple pratique : un assistant IA qui aide les développeurs à comprendre une base de code en lisant des fichiers et en répondant aux questions.

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;
using System.ComponentModel;

// Define our plugins
public class FileSystemPlugin
{
 private readonly string _rootPath;

 public FileSystemPlugin(string rootPath)
 {
 _rootPath = rootPath;
 }

 [KernelFunction("read_file")]
 [Description("Reads the contents of a file from the project directory")]
 public async Task<string> ReadFile(
 [Description("Relative path to the file")] string path)
 {
 var fullPath = Path.Combine(_rootPath, path);

 if (!File.Exists(fullPath))
 return $"File not found: {path}";

 var content = await File.ReadAllTextAsync(fullPath);

 // Truncate very large files
 if (content.Length > 8000)
 content = content[..8000] + "\n... [truncated]";

 return content;
 }

 [KernelFunction("list_files")]
 [Description("Lists files in a directory, optionally filtered by extension")]
 public string ListFiles(
 [Description("Relative directory path")] string directory,
 [Description("File extension filter like '.cs' or '.json'")] string? extension = null)
 {
 var fullPath = Path.Combine(_rootPath, directory);

 if (!Directory.Exists(fullPath))
 return $"Directory not found: {directory}";

 var files = Directory.GetFiles(fullPath, "*.*", SearchOption.AllDirectories)
 .Select(f => Path.GetRelativePath(_rootPath, f))
 .Where(f => extension is null || f.EndsWith(extension))
 .Take(50);

 return string.Join("\n", files);
 }
}

public class DocumentationPlugin
{
 [KernelFunction("generate_summary")]
 [Description("Generates a structured markdown summary for documentation")]
 public string GenerateSummaryTemplate(
 [Description("Name of the component")] string componentName,
 [Description("Brief description")] string description,
 [Description("Key responsibilities as comma-separated values")] string responsibilities)
 {
 var items = responsibilities.Split(',', StringSplitOptions.TrimEntries);
 var bullets = string.Join("\n", items.Select(r => $"- {r}"));

 return $"""
 ## {componentName}

 {description}

 ### Responsibilities
 {bullets}

 ---
 *Generated documentation — review and expand as needed.*
 """;
 }
}

// Wire it all up
var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: "https://your-resource.openai.azure.com/",
 apiKey: "your-api-key"
);

builder.Plugins.AddFromObject(new FileSystemPlugin("./src"));
builder.Plugins.AddFromType<DocumentationPlugin>();

var kernel = builder.Build();

var chatService = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory();

history.AddSystemMessage("""
 You are a codebase documentation assistant. You help developers understand
 projects by reading source files and explaining architecture, patterns,
 and design decisions.

 When asked about code, use your tools to read the actual files rather
 than guessing. Be specific and reference actual code when possible.
 Generate documentation artifacts when asked.
 """);

var settings = new OpenAIPromptExecutionSettings
{
 FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};

Console.WriteLine("Documentation Assistant ready. Ask me about your codebase!");
Console.WriteLine("Type 'exit' to quit.\n");

while (true)
{
 Console.Write("You: ");
 var input = Console.ReadLine();

 if (string.IsNullOrWhiteSpace(input) || input.Equals("exit", StringComparison.OrdinalIgnoreCase))
 break;

 history.AddUserMessage(input);

 var response = await chatService.GetChatMessageContentAsync(
 history,
 executionSettings: settings,
 kernel: kernel
 );

 Console.WriteLine($"\nAssistant: {response.Content}\n");
 history.AddAssistantMessage(response.Content ?? "");
}

Cet assistant peut :- Liste et lis les fichiers de votre répertoire de projet

Répondez aux questions sur la base de code en lisant les fichiers sources réels
Générer de la documentation au format markdown
Maintenir le contexte de la conversation pour que les questions de suivi fonctionnent naturellement

L’IA décide automatiquement quand appeler read_file, list_files ou generate_summary en fonction de ce que vous demandez. Demandez-lui « Que fait OrderService ? » et il lira le fichier, l’analysera et l’expliquera. Demandez-lui de « Générer la documentation pour le module d’authentification » et il explorera les fichiers, comprendra la structure et produira un résumé formaté.

Conseils pour la production

Avant de livrer votre application Semantic Kernel, quelques choses que j’ai apprises à mes dépens :

Utilisez correctement l’injection de dépendances. Dans les applications ASP.NET Core, enregistrez le noyau et les services dans votre conteneur DI plutôt que de les créer en ligne :

builder.Services.AddKernel()
 .AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: configuration["AzureOpenAI:Endpoint"]!,
 apiKey: configuration["AzureOpenAI:ApiKey"]!
 )
 .Plugins.AddFromType<TimePlugin>()
 .AddFromType<OrderPlugin>();

Gérez les erreurs avec élégance. Les appels LLM peuvent échouer, expirer ou renvoyer des résultats inattendus. Enveloppez vos invocations dans des blocs try-catch et implémentez des politiques de nouvelle tentative avec Polly ou les fonctionnalités de résilience intégrées.

Surveillez l’utilisation des jetons. Chaque invite, chaque description de fonction et chaque élément de l’historique des discussions consomme des jetons. Utilisez des filtres pour enregistrer et suivre l’utilisation :

kernel.FunctionInvocationFilters.Add(new LoggingFilter());

Gardez les descriptions de vos fonctions précises. Des descriptions vagues conduisent à des appels incorrects des fonctions de l’IA. Testez vos descriptions en demandant : « Si je lisais seulement la description, saurais-je exactement quand et comment utiliser cette fonction ? »

Conclusion

Semantic Kernel est l’une de ces bibliothèques qui change fondamentalement votre façon de concevoir la création d’applications. Il ne s’agit pas simplement d’un wrapper d’API : il s’agit d’un cadre d’orchestration qui vous permet de composer des fonctionnalités d’IA avec du code traditionnel d’une manière maintenable, testable et prête pour la production.

Ce que j’aime le plus, c’est qu’il respecte l’écosystème .NET. Il utilise des modèles que vous connaissez déjà (injection de dépendances, attributs, asynchrone/attente, interfaces) et les étend au monde de l’IA. Vous n’êtes pas obligé d’apprendre un paradigme complètement nouveau ; vous ajoutez simplement l’IA comme autre fonctionnalité dans votre boîte à outils.

Si vous créez des applications .NET et n’avez pas encore exploré le noyau sémantique, c’est le moment. Le SDK est stable, la communauté est active et les modèles qu’il permet (de la simple orchestration rapide à la collaboration multi-agents) deviennent des compétences essentielles pour les développeurs modernes.

Commencez petit. Créez un noyau, enregistrez un plugin et regardez l’IA appeler votre code. Une fois que vous aurez cliqué, vous commencerez à voir des opportunités d’ajouter de l’intelligence partout dans vos applications.

La documentation officielle et le dépôt GitHub sont d’excellentes ressources pour poursuivre votre voyage. Bonne construction !

Héritage de composants dans Blazor

Thu, 04 Sep 2025 00:00:00 +0000

Je construisais un projet qui comportait un tas de pages de formulaire, et chacune avait la même logique d’état de chargement, la même gestion des erreurs et les mêmes notifications toast. Copier-coller tout cela me semblait faux, alors j’ai examiné l’héritage des composants dans Blazor. Il s’avère que c’est assez simple puisque les composants Blazor ne sont que des classes C#.

Les bases

Chaque composant Blazor hérite de ComponentBase par défaut. Vous pouvez créer votre propre classe de base qui étend ComponentBase, puis en faire hériter vos composants.

Disons que la plupart de nos pages nécessitent un état de chargement et une gestion des erreurs. Nous pouvons créer une classe de base :

using Microsoft.AspNetCore.Components;

public abstract class PageBase : ComponentBase
{
 protected bool IsLoading { get; set; } = true;
 protected string? ErrorMessage { get; set; }

 protected async Task LoadDataAsync(Func<Task> action)
 {
 try
 {
 IsLoading = true;
 ErrorMessage = null;
 await action();
 }
 catch (Exception ex)
 {
 ErrorMessage = ex.Message;
 }
 finally
 {
 IsLoading = false;
 StateHasChanged();
 }
 }
}

Utiliser la classe de base

Désormais, dans n’importe quel composant de page, au lieu d’hériter de ComponentBase, nous héritons de notre PageBase :

@page "/users"
@inherits PageBase

@if (IsLoading)
{
 <div class="spinner"></div>
}
else if (ErrorMessage is not null)
{
 <div class="alert alert-danger">@ErrorMessage</div>
}
else
{
 <ul>
 @foreach (var user in users)
 {
 <li>@user.Name</li>
 }
 </ul>
}

@code {
 private List<User> users = new();

 protected override async Task OnInitializedAsync()
 {
 await LoadDataAsync(async () =>
 {
 users = await Http.GetFromJsonAsync<List<User>>("api/users");
 });
 }
}

La directive @inherits PageBase est la clé. Il indique à Blazor d’utiliser notre classe de base au lieu de la classe par défaut ComponentBase. Nous obtenons désormais IsLoading, ErrorMessage et LoadDataAsync() gratuitement dans chaque page qui en hérite.

Injection de services dans la classe de base

Vous pouvez également injecter des services dans la classe de base afin qu’ils soient disponibles pour tous les composants enfants :

public abstract class PageBase : ComponentBase
{
 [Inject]
 protected NavigationManager Navigation { get; set; } = default!;

 [Inject]
 protected IToastService Toast { get; set; } = default!;

 protected bool IsLoading { get; set; } = true;
 protected string? ErrorMessage { get; set; }

 protected void NavigateBack() => Navigation.NavigateTo("javascript:history.back()");

 protected void ShowSuccess(string message) => Toast.ShowSuccess(message);
}

Chaque composant qui hérite de PageBase a désormais accès à Navigation, Toast, NavigateBack() et ShowSuccess() sans avoir à injecter quoi que ce soit.

Aller plus loin avec les classes de base génériques

Vous pouvez même créer des classes de base génériques pour les modèles CRUD courants :

public abstract class CrudPageBase<T> : PageBase
{
 protected List<T> Items { get; set; } = new();
 protected T? SelectedItem { get; set; }

 protected abstract Task<List<T>> FetchItems();
 protected abstract Task DeleteItem(T item);

 protected override async Task OnInitializedAsync()
 {
 await LoadDataAsync(async () =>
 {
 Items = await FetchItems();
 });
 }

 protected async Task OnDelete(T item)
 {
 await LoadDataAsync(async () =>
 {
 await DeleteItem(item);
 Items = await FetchItems();
 ShowSuccess("Item deleted.");
 });
 }
}

Ensuite, votre page réelle devient super propre :

@page "/products"
@inherits CrudPageBase<Product>

@* just the markup, all logic lives in the base class *@

@code {
 protected override Task<List<Product>> FetchItems()
 => Http.GetFromJsonAsync<List<Product>>("api/products");

 protected override Task DeleteItem(Product item)
 => Http.DeleteAsync($"api/products/{item.Id}");
}

Quand l’utiliser et quand ne pas l’utiliser

L’héritage de composants est idéal pour les comportements partagés tels que les états de chargement, la gestion des erreurs, les contrôles d’authentification ou les modèles CRUD. Mais n’allez pas trop loin avec les hiérarchies d’héritage profondes - si vous vous retrouvez à plus de deux niveaux de profondeur, vous êtes probablement mieux loti avec la composition (comme l’approche LoadingComponent d’un article précédent).

Je le garde généralement à une classe de base par “type” de page : PageBase pour les pages normales, FormPageBase pour les formulaires, et c’est tout.

J’espère que vous avez aimé le message ! N’hésitez pas à me contacter sur tous les réseaux sociaux à @emimontesdeoca.

Ressources

Héritage du composant ASP.NET Core Razor

.NET Aspire : créer des applications cloud natives de la bonne manière

Wed, 20 Aug 2025 00:00:00 +0000

Si vous avez déjà créé une application distribuée dans .NET, vous connaissez le principe. Vous lancez une API Web, ajoutez un travailleur en arrière-plan, ajoutez Redis pour la mise en cache, PostgreSQL pour la persistance, peut-être RabbitMQ pour la messagerie - et tout à coup, vous passez plus de temps à câbler l’infrastructure qu’à écrire une logique métier. Chaînes de connexion dispersées dans les fichiers appsettings.json, vérifications de l’état que vous avez oublié de configurer, observabilité qui est toujours “le problème du prochain sprint”.

J’y suis allé. Plus de fois que je voudrais l’admettre.

C’est exactement le problème pour lequel .NET Aspire a été conçu. Après l’avoir utilisé en production pendant plusieurs mois maintenant, je souhaite partager ce que j’ai appris : les bons, les grands et les pièges.

Qu’est-ce que .NET Aspire ?

.NET Aspire est une pile avisée permettant de créer des applications distribuées observables, prêtes pour la production avec .NET. Ce n’est pas un framework au sens traditionnel du terme : il ne remplace pas ASP.NET Core et ne vous oblige pas à adopter un nouveau modèle de programmation. Au lieu de cela, il s’ajoute à ce que vous savez déjà et comble les lacunes qui ont toujours existé lors de la création d’applications cloud natives.

À la base, Aspire vous offre quatre choses :

AppHost — Un projet qui définit l’intégralité de la topologie de votre application distribuée. Quels services existent, de quoi ils dépendent et comment ils se connectent.
Paramètres par défaut du service — Un projet partagé qui configure les préoccupations transversales telles que les contrôles de santé, les politiques de résilience et OpenTelemetry — une fois, pour tous vos services.
Composants — Packages NuGet qui fournissent des intégrations standardisées avec des services de support tels que Redis, PostgreSQL, RabbitMQ, Azure Storage, etc.
Tableau de bord du développeur : une interface utilisateur en temps réel qui affiche les journaux, les traces et les métriques pour l’ensemble de votre application distribuée pendant le développement local.

La philosophie est simple : si chaque application cloud .NET a besoin de ces éléments, pourquoi les implémentons-nous tous à partir de zéro à chaque fois ?

Configurer votre premier projet Aspire

La mise en route est simple. Vous aurez besoin de .NET 8 ou version ultérieure et de la charge de travail Aspire installée :

dotnet workload update
dotnet workload install aspire

Créez maintenant un nouveau projet de démarrage Aspire :

dotnet new aspire-starter -n MyCloudApp

Cela génère une solution avec quatre projets :

MyCloudApp.AppHost — L’orchestrateur
MyCloudApp.ServiceDefaults — Configuration partagée
MyCloudApp.ApiService — Un exemple d’API Web
MyCloudApp.Web — Une interface Blazor

Exécutez AppHost et vous verrez immédiatement le tableau de bord Aspire ouvert dans votre navigateur, affichant tous vos services, leurs journaux et leur état de santé. Aucun fichier Docker Compose. Pas de gestion manuelle des ports. Cela fonctionne.

dotnet run --project MyCloudApp.AppHost

C’est cette première expérience qui m’a accroché. En moins d’une minute, vous disposez d’une application distribuée entièrement orchestrée avec observabilité intégrée.

Le modèle AppHost

L’AppHost est l’endroit où la magie vit. Il s’agit d’une petite application console qui utilise un modèle de générateur pour définir la topologie de votre application distribuée : quelles ressources existent et comment les services s’y connectent.

Voici à quoi ressemble un AppHost réaliste :

var builder = DistributedApplication.CreateBuilder(args);

// Infrastructure resources
var postgres = builder.AddPostgres("postgres")
 .WithPgAdmin()
 .AddDatabase("catalogdb");

var redis = builder.AddRedis("cache");

var rabbitmq = builder.AddRabbitMQ("messaging")
 .WithManagementPlugin();

// Application services
var catalogApi = builder.AddProject<Projects.CatalogApi>("catalog-api")
 .WithReference(postgres)
 .WithReference(redis)
 .WithReference(rabbitmq);

var orderApi = builder.AddProject<Projects.OrderApi>("order-api")
 .WithReference(postgres)
 .WithReference(rabbitmq);

var frontend = builder.AddProject<Projects.WebFrontend>("frontend")
 .WithExternalHttpEndpoints()
 .WithReference(catalogApi)
 .WithReference(orderApi);

builder.Build().Run();
```Lisez ce code à voix haute. Il se documente pratiquement. "L'API du catalogue fait référence à PostgreSQL, Redis et RabbitMQ. Le frontend fait référence à l'API du catalogue et à l'API de commande." C'est votre architecture, exprimée en code.

Quelques points à noter :

- **`WithReference`** fait le gros du travail. Il injecte automatiquement les chaînes de connexion et les URL de service dans le projet consommateur via les variables d'environnement et la configuration. Vos services n'ont pas besoin de savoir *où* Redis s'exécute - Aspire s'en charge.
- **`WithPgAdmin()`** et **`WithManagementPlugin()`** lancent des interfaces utilisateur d'administration pour PostgreSQL et RabbitMQ parallèlement aux services réels. Pendant le développement, ceux-ci sont inestimables.
- **`WithExternalHttpEndpoints()`** marque un service comme accessible de l'extérieur, ce qui est important au moment du déploiement.

### Configuration des ressources

Vous pouvez configurer des ressources avec un contrôle précis :

```csharp
var postgres = builder.AddPostgres("postgres")
 .WithEnvironment("POSTGRES_MAX_CONNECTIONS", "200")
 .WithDataVolume("postgres-data")
 .AddDatabase("catalogdb");

var redis = builder.AddRedis("cache")
 .WithDataVolume("redis-data");

Les volumes de données garantissent que vos données de développement locales survivent aux redémarrages des conteneurs. Petit détail, grande amélioration de la qualité de vie.

Paramètres par défaut du service : le héros méconnu

Le projet ServiceDefaults est la partie la plus sous-estimée d’Aspire. Il s’agit d’une bibliothèque partagée à laquelle chaque service de votre solution fait référence et qui configure toutes les préoccupations transversales que vous auriez autrement oubliées ou mises en œuvre de manière incohérente.

Voici à quoi ressemble un Extensions.cs typique dans ServiceDefaults :

public static class Extensions
{
 public static IHostApplicationBuilder AddServiceDefaults(
 this IHostApplicationBuilder builder)
 {
 builder.ConfigureOpenTelemetry();
 builder.AddDefaultHealthChecks();
 builder.Services.AddServiceDiscovery();

 builder.Services.ConfigureHttpClientDefaults(http =>
 {
 http.AddStandardResilienceHandler();
 http.AddServiceDiscovery();
 });

 return builder;
 }

 public static IHostApplicationBuilder ConfigureOpenTelemetry(
 this IHostApplicationBuilder builder)
 {
 builder.Logging.AddOpenTelemetry(logging =>
 {
 logging.IncludeFormattedMessage = true;
 logging.IncludeScopes = true;
 });

 builder.Services.AddOpenTelemetry()
 .WithMetrics(metrics =>
 {
 metrics.AddAspNetCoreInstrumentation()
 .AddHttpClientInstrumentation()
 .AddRuntimeInstrumentation();
 })
 .WithTracing(tracing =>
 {
 tracing.AddAspNetCoreInstrumentation()
 .AddHttpClientInstrumentation()
 .AddGrpcClientInstrumentation();
 });

 builder.AddOpenTelemetryExporters();
 return builder;
 }

 public static IHostApplicationBuilder AddDefaultHealthChecks(
 this IHostApplicationBuilder builder)
 {
 builder.Services.AddHealthChecks()
 .AddCheck("self", () => HealthCheckResult.Healthy(),
 ["live"]);

 return builder;
 }
}

Ensuite, dans le Program.cs de chaque service, une seule ligne fait tout :

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();

// Your service-specific configuration...

var app = builder.Build();
app.MapDefaultEndpoints();
app.Run();

Cet unique appel AddServiceDefaults() vous donne :

OpenTelemetry avec journalisation structurée, métriques et traçage distribué
Bilans de santé avec points de terminaison d’activité et de préparation
Découverte de services afin que les services puissent se trouver par leur nom
Politiques de résilience sur tous les appels HTTP sortants (nouvelles tentatives, disjoncteurs, délais d’attente)

C’est ce qui différencie une démo “fonctionne sur ma machine” d’un système prêt pour la production. Et Aspire en fait la valeur par défaut, pas une réflexion après coup.

Composants Aspirer

Les composants Aspire sont des packages NuGet qui standardisent la façon dont vos services se connectent à l’infrastructure de support. Il s’agit bien plus que de simples bibliothèques client : elles incluent des vérifications de l’état, la journalisation, le traçage et une résilience configurable prête à l’emploi.

Redis

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
builder.AddRedisDistributedCache("cache");

C’est tout. La chaîne de connexion provient de l’AppHost via WithReference. Le composant enregistre un IDistributedCache soutenu par Redis, avec des contrôles de santé et une instrumentation OpenTelemetry déjà câblés.

Vous pouvez également utiliser Redis pour la mise en cache des sorties :

builder.AddRedisOutputCache("cache");

PostgreSQL avec Entity Framework Core

builder.AddNpgsqlDbContext<CatalogDbContext>("catalogdb", settings =>
{
 settings.DisableRetry = false;
});

Cela enregistre votre DbContext avec une connexion à la base de données catalogdb définie dans AppHost. Il comprend le regroupement de connexions, les vérifications de l’état et les politiques de nouvelle tentative.

LapinMQ

builder.AddRabbitMQClient("messaging");

Enregistre un IConnection de la bibliothèque client RabbitMQ, entièrement configuré et vérifié.

Intégrations Azure

Aspire dispose également de composants de première classe pour les services Azure :

// Azure Blob Storage
builder.AddAzureBlobClient("blobs");

// Azure Service Bus
builder.AddAzureServiceBusClient("servicebus");

// Azure Key Vault
builder.AddAzureKeyVaultClient("secrets");
```Le schéma est toujours le même : une ligne dans l'AppHost pour définir la ressource, une ligne dans le service consommateur pour l'utiliser. Les détails de connexion circulent automatiquement.

## Le tableau de bord du développeur

Le tableau de bord Aspire est l'une de ces fonctionnalités qui semblent utiles jusqu'à ce que vous l'utilisiez réellement - alors vous ne pouvez pas imaginer travailler sans lui.

Lorsque vous exécutez votre AppHost localement, le tableau de bord se lance et vous donne :

- **Aperçu des ressources** — Tous vos services et infrastructures en un coup d'œil, avec des indicateurs d'état
- **Journaux structurés** – Diffusion en temps réel des journaux de chaque service, filtrables et consultables
- **Traces distribuées** — Traces de requêtes de bout en bout couvrant plusieurs services, visualisées sous forme de diagrammes en flammes
- **Metrics** — Taux de requêtes HTTP, taux d'erreur, latences et métriques personnalisées en temps réel
- **Journaux de la console** – Stdout/stderr brut de chaque conteneur et projet

Le traçage distribué est particulièrement précieux. Lorsqu'une requête arrive sur votre frontend, traverse l'API du catalogue, touche Redis et PostgreSQL — vous voyez la chaîne entière avec le timing pour chaque saut. Plus besoin de deviner où se situe le goulot d’étranglement.

J'ai trouvé le tableau de bord le plus utile lors du débogage. Au lieu de suivre plusieurs fenêtres de terminal ou de passer d'un fichier journal à l'autre, tout est au même endroit avec des ID de corrélation reliant les événements associés entre les services.

Le tableau de bord est également disponible sous forme de conteneur autonome, ce qui signifie que vous pouvez l'utiliser dans des environnements de test ou des pipelines CI :

```bash
docker run --rm -p 18888:18888 \
 mcr.microsoft.com/dotnet/aspire-dashboard:latest

Déploiement

Aspire aide pendant le développement, mais qu’en est-il de la production ? C’est là que les choses deviennent pratiques.

Applications de conteneur Azure

Le chemin de déploiement le plus simple est Azure Container Apps (ACA), qui bénéficie d’un support Aspire de première classe. Vous pouvez déployer directement à l’aide d’Azure Developer CLI :

azd init
azd up

La commande azd init détecte votre Aspire AppHost et génère l’infrastructure en tant que code nécessaire. azd up provisionne tout (registre de conteneurs, applications de conteneurs, bases de données, instances Redis) en fonction de votre topologie AppHost.

Votre AppHost devient essentiellement votre manifeste de déploiement. Le même code qui définit « l’API du catalogue dépend de PostgreSQL et Redis » pilote le provisionnement de l’infrastructure.

Kubernetes

Pour les déploiements Kubernetes, Aspire ne génère pas de manifeste directement, mais votre topologie AppHost correspond clairement aux ressources Kubernetes. L’outil communautaire aspirate (Aspir8) peut générer des graphiques Helm ou des manifestes Kubernetes à partir de votre AppHost :

dotnet tool install -g aspirate
aspirate generate
aspirate apply

Considérations relatives au déploiement

Quelques points à garder à l’esprit :- Les chaînes de connexion changent entre les environnements. Localement, Aspire fait tourner les conteneurs et injecte automatiquement les chaînes de connexion. En production, vous indiquerez les services gérés. Aspire utilise une configuration .NET standard, de sorte que les variables d’environnement et Azure Key Vault fonctionnent comme prévu.

L’AppHost ne s’exécute pas en production. Il s’agit d’un outil d’orchestration de développement et de déploiement. En production, vos services s’exécutent de manière indépendante, configurés via des variables d’environnement et des orchestrateurs.
Les ressources d’infrastructure deviennent des services gérés. Votre conteneur PostgreSQL local devient Azure Database pour PostgreSQL. Votre conteneur Redis local devient Azure Cache pour Redis. Le code consommateur ne change pas.

Conseils du monde réel

Après avoir utilisé Aspire en production pendant un certain temps, voici les leçons qui nous ont permis de gagner du temps :

1. Utilisez des vérifications personnalisées du cycle de vie des ressources

Ne comptez pas uniquement sur le démarrage du conteneur pour déterminer si une ressource est prête. PostgreSQL peut accepter les connexions TCP avant d’être réellement prêt à répondre aux requêtes.

var postgres = builder.AddPostgres("postgres")
 .AddDatabase("catalogdb")
 .WithHealthCheck();

Aspire peut effectuer des contrôles de santé sur les ressources et conserver les services dépendants jusqu’à ce qu’ils soient réellement prêts.

2. Extraire les modèles courants dans les extensions

Si plusieurs services partagent des configurations similaires, créez des méthodes d’extension :

public static class AppHostExtensions
{
 public static IResourceBuilder<ProjectResource> AddWorkerService(
 this IDistributedApplicationBuilder builder,
 string name,
 IResourceBuilder<IResourceWithConnectionString> db,
 IResourceBuilder<IResourceWithConnectionString> messaging)
 {
 return builder.AddProject<Projects.WorkerService>(name)
 .WithReference(db)
 .WithReference(messaging)
 .WithReplicas(3);
 }
}

3. Tirez parti de WithReplicas pour les tests de charge

var catalogApi = builder.AddProject<Projects.CatalogApi>("catalog-api")
 .WithReference(postgres)
 .WithReference(redis)
 .WithReplicas(5);

WithReplicas lance plusieurs instances d’un service localement. C’est idéal pour tester l’équilibrage de charge, les bogues de concurrence et le comportement de la mise en cache distribuée sans déployer sur un cluster.

4. Utiliser les paramètres pour les valeurs sensibles

Ne codez pas en dur les identifiants, même pour le développement local :

var dbPassword = builder.AddParameter("db-password", secret: true);

var postgres = builder.AddPostgres("postgres", password: dbPassword)
 .AddDatabase("catalogdb");

Lors de l’exécution locale, Aspire demandera la valeur ou la lira à partir des secrets d’utilisateur. En CI/CD, cela provient des variables d’environnement.

5. Les tests d’intégration deviennent triviaux

Aspire comprend un package de tests qui rend les tests d’intégration des applications distribuées remarquablement simples :

[Fact]
public async Task CatalogApiReturnsProducts()
{
 var appHost = await DistributedApplicationTestingBuilder
 .CreateAsync<Projects.MyCloudApp_AppHost>();

 await using var app = await appHost.BuildAsync();
 await app.StartAsync();

 var httpClient = app.CreateHttpClient("catalog-api");
 var response = await httpClient.GetAsync("/api/products");

 response.EnsureSuccessStatusCode();

 var products = await response.Content
 .ReadFromJsonAsync<List<Product>>();
 Assert.NotEmpty(products);
}

Cela fait tourner votre application distribuée toute – y compris les bases de données et les courtiers de messages – exécute votre test sur elle et la détruit. De vrais tests d’intégration sur une infrastructure réelle, dans votre pipeline CI. Pas de moqueries.

6. Surveiller l’utilisation des ressources localement

Lorsque vous exécutez plusieurs conteneurs localement, gardez un œil sur la consommation des ressources. Une instance PostgreSQL, Redis et RabbitMQ avec interface utilisateur de gestion peut facilement consommer 2 à 3 Go de RAM. Si vous utilisez une machine limitée, envisagez d’utiliser des configurations de ressources plus légères :

var redis = builder.AddRedis("cache")
 .WithContainerRuntimeArgs("--memory=256m");

Conclusion

.NET Aspire a fondamentalement changé la façon dont je crée des applications distribuées. Non pas parce qu’il introduit des concepts révolutionnaires : les contrôles de santé, OpenTelemetry et l’orchestration de conteneurs ne sont pas nouveaux. Mais parce que cela les rend par défaut. Il prend les centaines de petites décisions que vous auriez normalement à prendre, les met en œuvre avec des valeurs par défaut raisonnables et vous permet de les ignorer en cas de besoin.Le modèle AppHost est, à mon avis, la plus grande victoire. Le fait que la topologie de votre application distribuée soit exprimée sous forme de code (et non dispersée dans les fichiers Docker Compose, les manifestes Kubernetes et les documents README) rend le système compréhensible. Les nouveaux membres de l’équipe peuvent ouvrir Program.cs dans AppHost et comprendre l’ensemble de l’architecture en quelques minutes.

Si vous créez des applications distribuées avec .NET, examinez sérieusement Aspire. Commencez avec le modèle aspire-starter, explorez le tableau de bord et adoptez progressivement les composants selon vos besoins. Vous n’êtes pas obligé d’y aller à fond dès le premier jour : Aspire est additif par conception.

L’époque où vous passiez votre premier sprint à câbler une infrastructure passe-partout est révolue. Laissez Aspire s’occuper de la plomberie afin que vous puissiez vous concentrer sur ce qui compte vraiment : votre application.

Authentification et autorisation dans Blazor : un guide pratique

Sat, 12 Jul 2025 00:00:00 +0000

Si vous avez travaillé avec ASP.NET MVC ou Razor Pages, vous avez probablement un modèle mental sur le fonctionnement de l’authentification : le middleware intercepte la demande, vérifie un cookie ou un jeton, remplit HttpContext.User et c’est parti pour les courses. Blazor modifie ce modèle mental de manière subtile mais importante – et si vous ne comprenez pas ces différences dès le début, vous finirez par déboguer des problèmes d’authentification qui semblent impossibles.

Dans cet article, je souhaite expliquer comment l’authentification et l’autorisation fonctionnent réellement dans Blazor, couvrant à la fois les modèles d’hébergement Server et WebAssembly. Nous passerons des principes fondamentaux jusqu’aux fournisseurs personnalisés, à OAuth externe et aux pièges que j’ai vus qui font trébucher même les développeurs .NET expérimentés.

Pourquoi l’authentification dans Blazor est différente

Dans ASP.NET traditionnel, chaque interaction utilisateur est une requête HTTP. Le serveur valide les informations d’identification, définit un cookie et chaque demande ultérieure transporte ce cookie. Le pipeline d’authentification est linéaire et prévisible.

Blazor Server fonctionne sur une connexion SignalR persistante. Une fois la requête HTTP initiale chargée, toutes les interactions ultérieures se produisent via WebSockets. Il n’y a pas de nouvelle requête HTTP pour chaque clic sur un bouton, donc le middleware ne se réexécute pas à chaque interaction. Le HttpContext est disponible lors de la connexion initiale, mais s’appuyer sur lui tout au long de la durée de vie d’un circuit est une recette pour les bugs.

Blazor WebAssembly s’exécute entièrement dans le navigateur. Il n’y a aucun HttpContext côté serveur. L’état d’authentification doit être récupéré à partir d’une API, stocké côté client et géré via des jetons (généralement des JWT). Le serveur ne fait confiance au client qu’en ce qui concerne la validation du jeton.

Cela signifie que Blazor a besoin de sa propre abstraction pour l’état d’authentification, qui fonctionne quel que soit le modèle d’hébergement. Cette abstraction est le AuthenticationStateProvider.

État d’authentification : La Fondation

Au cœur du système d’authentification de Blazor se trouve AuthenticationStateProvider. Il s’agit d’une classe abstraite qui expose une seule méthode critique :

public abstract Task<AuthenticationState> GetAuthenticationStateAsync();

L’objet AuthenticationState enveloppe un ClaimsPrincipal — le même modèle d’identité utilisé dans .NET. Les composants ne communiquent pas directement avec les cookies ou les jetons ; ils demandent au AuthenticationStateProvider l’état actuel.

Pour rendre cet état disponible pour l’ensemble de votre arborescence de composants, Blazor fournit CascadingAuthenticationState. Vous enveloppez généralement votre routeur avec celui-ci dans App.razor ou dans votre mise en page :

<CascadingAuthenticationState>
 <Router AppAssembly="@typeof(App).Assembly">
 <Found Context="routeData">
 <AuthorizeRouteView RouteData="@routeData"
 DefaultLayout="@typeof(MainLayout)">
 <NotAuthorized>
 <p>You're not authorized to view this page.</p>
 </NotAuthorized>
 </AuthorizeRouteView>
 </Found>
 <NotFound>
 <LayoutView Layout="@typeof(MainLayout)">
 <p>Page not found.</p>
 </LayoutView>
 </NotFound>
 </Router>
</CascadingAuthenticationState>

Le AuthorizeRouteView fait ici une double tâche : il vérifie si l’utilisateur est authentifié et autorisé avant de restituer le composant de page correspondant, et il fournit une interface utilisateur de secours lorsqu’il ne l’est pas.

Dans .NET 8 et versions ultérieures avec le modèle Blazor unifié, vous configurerez cela dans votre App.razor et le framework gère automatiquement le paramètre en cascade lorsque vous utilisez AddCascadingAuthenticationState() dans votre enregistrement de service.

Intégration d’identité ASP.NET

Pour la plupart des projets, vous n’avez pas besoin de créer une authentification à partir de zéro. ASP.NET Identity vous offre une gestion des utilisateurs, un hachage de mot de passe, une authentification à deux facteurs et une confirmation de compte prête à l’emploi.La configuration avec Blazor commence dans Program.cs :

builder.Services.AddDbContext<ApplicationDbContext>(options =>
 options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddDefaultIdentity<IdentityUser>(options =>
 {
 options.SignIn.RequireConfirmedAccount = true;
 options.Password.RequireDigit = true;
 options.Password.RequiredLength = 8;
 })
 .AddRoles<IdentityRole>()
 .AddEntityFrameworkStores<ApplicationDbContext>();

builder.Services.AddAuthentication(options =>
 {
 options.DefaultScheme = IdentityConstants.ApplicationScheme;
 options.DefaultSignInScheme = IdentityConstants.ExternalScheme;
 });

Avec le modèle Blazor Web App dans .NET 8+, l’interface utilisateur d’identité échafaudée utilise directement les composants Razor. Vous obtenez des pages de connexion, d’inscription et de gestion de compte qui s’intègrent naturellement au reste de votre application Blazor – plus de mélange gênant de composants Razor Pages et Blazor.

Le ApplicationDbContext hérite de IdentityDbContext et vous devrez exécuter des migrations pour créer les tables d’identité :

public class ApplicationDbContext : IdentityDbContext<IdentityUser>
{
 public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
 : base(options) { }
}

dotnet ef migrations add InitialIdentity
dotnet ef database update

Le composant AuthorizeView

Une fois que l’état d’authentification circule dans votre arborescence de composants, AuthorizeView vous permet d’afficher l’interface utilisateur de manière conditionnelle :

<AuthorizeView>
 <Authorized>
 <p>Welcome, @context.User.Identity?.Name!</p>
 <a href="/account/manage">Manage Account</a>
 <form method="post" action="/account/logout">
 <button type="submit">Log Out</button>
 </form>
 </Authorized>
 <NotAuthorized>
 <a href="/account/login">Log In</a>
 <a href="/account/register">Register</a>
 </NotAuthorized>
</AuthorizeView>

Le paramètre context à l’intérieur de <Authorized> vous donne accès au AuthenticationState, afin que vous puissiez inspecter les revendications, les rôles et l’identité de l’utilisateur directement dans votre balisage.

Vous pouvez également utiliser AuthorizeView avec des rôles et des stratégies :

<AuthorizeView Roles="Admin,Moderator">
 <Authorized>
 <button @onclick="DeletePost">Delete Post</button>
 </Authorized>
</AuthorizeView>

<AuthorizeView Policy="CanEditArticles">
 <Authorized>
 <button @onclick="EditArticle">Edit</button>
 </Authorized>
</AuthorizeView>

Une chose à garder à l’esprit : AuthorizeView est un problème d’interface utilisateur. Il masque ou affiche des éléments, mais ne protège pas la logique sous-jacente. Si quelqu’un peut appeler votre point de terminaison API ou appeler votre méthode directement, il contourne entièrement AuthorizeView. Appliquez toujours l’autorisation côté serveur également.

L’attribut [Autoriser]

Pour protéger une page entière, appliquez l’attribut [Authorize] :

@page "/admin/dashboard"
@attribute [Authorize(Roles = "Admin")]

<h1>Admin Dashboard</h1>
<p>Only administrators can see this page.</p>

Lorsqu’un utilisateur non authentifié accède à cette page, le AuthorizeRouteView entre en jeu et restitue le modèle <NotAuthorized> que vous avez défini précédemment. Vous pouvez plutôt rediriger vers une page de connexion en gérant le cas NotAuthorized avec la navigation :

<NotAuthorized>
 @if (!context.User.Identity?.IsAuthenticated ?? true)
 {
 <RedirectToLogin />
 }
 else
 {
 <p>You don't have permission to access this page.</p>
 }
</NotAuthorized>

Un simple composant RedirectToLogin pourrait ressembler à :

@inject NavigationManager Navigation

@code {
 protected override void OnInitialized()
 {
 var returnUrl = Uri.EscapeDataString(Navigation.Uri);
 Navigation.NavigateTo($"/account/login?returnUrl={returnUrl}", forceLoad: true);
 }
}

Le forceLoad: true est important ici : vous souhaitez une véritable navigation HTTP afin que le middleware d’authentification côté serveur puisse gérer correctement le flux de connexion.

Autorisation basée sur les rôles et basée sur les règles

Les rôles constituent le modèle le plus simple : affectez les utilisateurs à des groupes tels que “Administrateur” ou “Éditeur”, puis vérifiez l’adhésion. Mais les politiques vous offrent beaucoup plus de flexibilité.

Enregistrez les stratégies dans Program.cs :

builder.Services.AddAuthorizationCore(options =>
{
 options.AddPolicy("CanPublish", policy =>
 policy.RequireClaim("Permission", "Publish"));

 options.AddPolicy("MinimumAge", policy =>
 policy.Requirements.Add(new MinimumAgeRequirement(18)));

 options.AddPolicy("PremiumUser", policy =>
 policy.RequireRole("Premium")
 .RequireClaim("Subscription", "Active"));
});

Les exigences personnalisées nécessitent un gestionnaire :

public class MinimumAgeRequirement : IAuthorizationRequirement
{
 public int MinimumAge { get; }
 public MinimumAgeRequirement(int minimumAge) => MinimumAge = minimumAge;
}

public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
{
 protected override Task HandleRequirementAsync(
 AuthorizationHandlerContext context,
 MinimumAgeRequirement requirement)
 {
 var dateOfBirthClaim = context.User.FindFirst("DateOfBirth");

 if (dateOfBirthClaim is null)
 return Task.CompletedTask;

 var dateOfBirth = DateOnly.Parse(dateOfBirthClaim.Value);
 var age = DateOnly.FromDateTime(DateTime.Today).Year - dateOfBirth.Year;

 if (age >= requirement.MinimumAge)
 context.Succeed(requirement);

 return Task.CompletedTask;
 }
}

Enregistrez le gestionnaire :

builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeHandler>();

Dans les composants, vous pouvez également vérifier l’autorisation par programme lorsque vous avez besoin d’une logique dynamique :

@inject IAuthorizationService AuthorizationService
@inject AuthenticationStateProvider AuthStateProvider

@code {
 private bool canPublish;

 protected override async Task OnInitializedAsync()
 {
 var authState = await AuthStateProvider.GetAuthenticationStateAsync();
 var result = await AuthorizationService.AuthorizeAsync(
 authState.User, "CanPublish");
 canPublish = result.Succeeded;
 }
}

Fournisseurs OAuth externes

La prise en charge de « Connectez-vous avec Google » ou « Connectez-vous avec GitHub » est simple avec le middleware d’authentification ASP.NET. Ceux-ci sont configurés côté serveur puisque le flux OAuth nécessite des redirections HTTP.

builder.Services.AddAuthentication()
 .AddGoogle(options =>
 {
 options.ClientId = builder.Configuration["Auth:Google:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:Google:ClientSecret"]!;
 options.Scope.Add("profile");
 })
 .AddMicrosoftAccount(options =>
 {
 options.ClientId = builder.Configuration["Auth:Microsoft:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:Microsoft:ClientSecret"]!;
 })
 .AddGitHub(options =>
 {
 options.ClientId = builder.Configuration["Auth:GitHub:ClientId"]!;
 options.ClientSecret = builder.Configuration["Auth:GitHub:ClientSecret"]!;
 });

Pour GitHub, vous aurez besoin du package NuGet AspNet.Security.OAuth.GitHub, car il n’est pas inclus dans les bibliothèques ASP.NET par défaut.

L’interface utilisateur de connexion fournit ensuite des liens qui déclenchent le défi externe :

@page "/account/external-login"

<h2>Sign in with an external provider</h2>

<form method="post" action="/api/auth/external-login">
 <button type="submit" name="provider" value="Google">
 Sign in with Google
 </button>
 <button type="submit" name="provider" value="Microsoft">
 Sign in with Microsoft
 </button>
 <button type="submit" name="provider" value="GitHub">
 Sign in with GitHub
 </button>
</form>

Le point de terminaison de l’API déclenche le défi et gère le rappel :

app.MapPost("/api/auth/external-login", (string provider, HttpContext context) =>
{
 var properties = new AuthenticationProperties
 {
 RedirectUri = "/api/auth/external-callback"
 };
 return Results.Challenge(properties, [provider]);
});

L’authentification externe dans Blazor nécessite toujours une navigation sur une page entière : vous ne pouvez pas effectuer une redirection OAuth à l’intérieur d’un circuit SignalR ou d’une application WebAssembly sans passer par le serveur.

Authentification basée sur des jetons dans Blazor WebAssemblyBlazor WebAssembly s’exécute sur le client, donc l’authentification basée sur les cookies ne s’applique pas de la même manière. Au lieu de cela, vous utilisez généralement des JWT stockés en mémoire et attachés aux requêtes HTTP sortantes.

Le framework fournit AuthorizationMessageHandler pour attacher automatiquement les jetons :

builder.Services.AddHttpClient("API",
 client => client.BaseAddress = new Uri("https://api.example.com"))
 .AddHttpMessageHandler<AuthorizationMessageHandler>();

builder.Services.AddScoped(sp =>
 sp.GetRequiredService<IHttpClientFactory>().CreateClient("API"));

Pour les applications Blazor WASM autonomes qui s’authentifient auprès de leur propre API, vous implémenterez un AuthenticationStateProvider personnalisé qui analyse le JWT :

public class JwtAuthenticationStateProvider : AuthenticationStateProvider
{
 private readonly ILocalStorageService _localStorage;
 private readonly HttpClient _httpClient;

 public JwtAuthenticationStateProvider(
 ILocalStorageService localStorage,
 HttpClient httpClient)
 {
 _localStorage = localStorage;
 _httpClient = httpClient;
 }

 public override async Task<AuthenticationState> GetAuthenticationStateAsync()
 {
 var token = await _localStorage.GetItemAsync<string>("authToken");

 if (string.IsNullOrWhiteSpace(token))
 return new AuthenticationState(new ClaimsPrincipal(new ClaimsIdentity()));

 _httpClient.DefaultRequestHeaders.Authorization =
 new AuthenticationHeaderValue("Bearer", token);

 var claims = ParseClaimsFromJwt(token);
 var identity = new ClaimsIdentity(claims, "jwt");

 return new AuthenticationState(new ClaimsPrincipal(identity));
 }

 public void NotifyAuthStateChanged()
 {
 NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
 }

 private IEnumerable<Claim> ParseClaimsFromJwt(string jwt)
 {
 var payload = jwt.Split('.')[1];

 var padded = payload.Length % 4 switch
 {
 2 => payload + "==",
 3 => payload + "=",
 _ => payload
 };

 var bytes = Convert.FromBase64String(padded);
 var json = JsonSerializer.Deserialize<Dictionary<string, JsonElement>>(bytes);

 return json?.Select(kvp => new Claim(kvp.Key, kvp.Value.ToString()))
 ?? Enumerable.Empty<Claim>();
 }
}

Après une connexion réussie, vous stockez le jeton et notifiez l’état d’authentification :

public class AuthService
{
 private readonly HttpClient _httpClient;
 private readonly ILocalStorageService _localStorage;
 private readonly JwtAuthenticationStateProvider _authStateProvider;

 public AuthService(
 HttpClient httpClient,
 ILocalStorageService localStorage,
 AuthenticationStateProvider authStateProvider)
 {
 _httpClient = httpClient;
 _localStorage = localStorage;
 _authStateProvider = (JwtAuthenticationStateProvider)authStateProvider;
 }

 public async Task<bool> LoginAsync(string email, string password)
 {
 var response = await _httpClient.PostAsJsonAsync("/api/auth/login",
 new { Email = email, Password = password });

 if (!response.IsSuccessStatusCode)
 return false;

 var result = await response.Content
 .ReadFromJsonAsync<LoginResponse>();

 await _localStorage.SetItemAsync("authToken", result!.Token);
 _authStateProvider.NotifyAuthStateChanged();

 return true;
 }

 public async Task LogoutAsync()
 {
 await _localStorage.RemoveItemAsync("authToken");
 _authStateProvider.NotifyAuthStateChanged();
 }
}

Un mot d’avertissement : stocker les JWT dans localStorage les expose aux attaques XSS. Pour les applications plus sécurisées, envisagez de conserver les jetons en mémoire uniquement et d’utiliser des jetons d’actualisation, ou d’adopter le modèle Backend-for-Frontend (BFF) dans lequel le serveur gère les jetons et le client utilise des cookies HTTP uniquement.

Blazor Server vs WebAssembly : considérations de sécurité

Le modèle d’hébergement modifie fondamentalement votre posture de sécurité.

Blazor Server conserve toute la logique de vos composants sur le serveur. Le client ne voit que les différences HTML rendues sur SignalR. Cela signifie :

La logique sensible ne quitte jamais le serveur
Vous pouvez accéder aux bases de données et aux services internes directement depuis les composants
L’état d’authentification provient du HttpContext du serveur lors de la connexion initiale
Le circuit peut survivre au cookie d’authentification : si le cookie d’un utilisateur expire, le circuit reste actif jusqu’à sa déconnexion.
Vous devez gérer la déconnexion du circuit avec élégance et revalider l’état d’authentification lors de la reconnexion

Blazor WebAssembly s’exécute entièrement dans le navigateur. Cela signifie :

Tout le code de votre composant est téléchargeable et inspectable
Ne mettez jamais de secrets, de chaînes de connexion ou de logique métier sensible dans les composants WASM
L’authentification n’est appliquée sur le client que pour l’UX ; la véritable application doit avoir lieu au niveau de votre couche API
La gestion des jetons est de votre responsabilité
Envisagez d’utiliser le modèle hébergé dans lequel un projet de serveur gère l’authentification et sert l’application WASM

Un modèle que je recommande pour les applications WebAssembly consiste à traiter chaque composant comme s’il s’agissait d’une « interface utilisateur non fiable » et chaque point de terminaison d’API comme s’il était appelé par un client inconnu. Validez tout côté serveur, indépendamment de ce que le client vérifie.

Création d’un AuthenticationStateProvider personnalisé

Parfois, les fournisseurs intégrés ne correspondent pas à votre architecture. Peut-être que vous intégrez un ancien système d’authentification ou que vous devez interroger les changements d’état d’authentification. Voici un fournisseur personnalisé plus complet pour Blazor Server :

public class CustomAuthStateProvider : AuthenticationStateProvider
{
 private readonly IHttpContextAccessor _httpContextAccessor;
 private readonly IUserService _userService;

 public CustomAuthStateProvider(
 IHttpContextAccessor httpContextAccessor,
 IUserService userService)
 {
 _httpContextAccessor = httpContextAccessor;
 _userService = userService;
 }

 public override async Task<AuthenticationState> GetAuthenticationStateAsync()
 {
 var httpContext = _httpContextAccessor.HttpContext;

 if (httpContext?.User?.Identity?.IsAuthenticated != true)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var userId = httpContext.User.FindFirstValue(ClaimTypes.NameIdentifier);

 if (userId is null)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var user = await _userService.GetUserWithClaimsAsync(userId);

 if (user is null)
 return new AuthenticationState(
 new ClaimsPrincipal(new ClaimsIdentity()));

 var claims = new List<Claim>
 {
 new(ClaimTypes.NameIdentifier, user.Id),
 new(ClaimTypes.Name, user.DisplayName),
 new(ClaimTypes.Email, user.Email)
 };

 claims.AddRange(user.Roles.Select(r => new Claim(ClaimTypes.Role, r)));
 claims.AddRange(user.Permissions.Select(p => new Claim("Permission", p)));

 var identity = new ClaimsIdentity(claims, "Custom");
 return new AuthenticationState(new ClaimsPrincipal(identity));
 }

 public void MarkUserAsAuthenticated(string userId)
 {
 NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
 }

 public void MarkUserAsLoggedOut()
 {
 var anonymous = new ClaimsPrincipal(new ClaimsIdentity());
 var authState = Task.FromResult(new AuthenticationState(anonymous));
 NotifyAuthenticationStateChanged(authState);
 }
}

Enregistrez-le dans Program.cs :

builder.Services.AddScoped<AuthenticationStateProvider, CustomAuthStateProvider>();
builder.Services.AddScoped<CustomAuthStateProvider>();

L’information clé ici est NotifyAuthenticationStateChanged — son appel déclenche la mise à jour du paramètre en cascade, qui réévalue chaque AuthorizeView et AuthorizeRouteView dans votre arborescence de composants. C’est ainsi que vous faites réagir l’interface utilisateur aux événements de connexion/déconnexion sans actualisation complète de la page.

Pièges courants et solutions

Après avoir travaillé avec Blazor Auth sur de nombreux projets, voici les problèmes que je vois le plus souvent :

1. Utilisation de HttpContext dans les composants du serveur Blazor`HttpContext` est disponible lors de la requête HTTP initiale, mais il est `null` ou obsolète lors des interactions SignalR. N’injectez pas `IHttpContextAccessor` dans les composants qui s’exécutent après le rendu initial.

Solution : Capturez ce dont vous avez besoin à partir de HttpContext lors de l’initialisation et stockez-le dans un service étendu :

public class UserContext
{
 public string? UserId { get; set; }
 public string? AccessToken { get; set; }
}

// In a component that renders during the initial HTTP request:
@inject IHttpContextAccessor HttpContextAccessor
@inject UserContext UserContext

@code {
 protected override void OnInitialized()
 {
 var context = HttpContextAccessor.HttpContext;
 UserContext.UserId = context?.User.FindFirstValue(ClaimTypes.NameIdentifier);
 UserContext.AccessToken = context?.Request.Headers.Authorization
 .ToString().Replace("Bearer ", "");
 }
}

2. L’état d’authentification ne se met pas à jour après la connexion

Vous appelez votre API de connexion, elle réussit, mais l’interface utilisateur affiche toujours « Connexion ».

Solution : Vous devez appeler NotifyAuthenticationStateChanged sur votre AuthenticationStateProvider après le changement de l’état d’authentification. Le framework ne détecte pas comme par magie qu’un jeton a été stocké ou qu’un cookie a été défini.

3. Autoriser l’attribut ne fonctionnant pas sur les composants

Vous ajoutez [Authorize] à un composant mais cela ne bloque pas les utilisateurs non authentifiés.

Solution : Assurez-vous d’utiliser AuthorizeRouteView au lieu de RouteView simple dans votre App.razor. La norme RouteView ignore entièrement les attributs d’autorisation.

4. Le prérendu interrompt l’état d’authentification

Lors du prérendu côté serveur dans Blazor WebAssembly, aucun jeton d’authentification n’est disponible. Les composants s’affichent comme non authentifiés, puis passent à l’état authentifié après le chargement de WASM.

Solution : Soit désactivez le prérendu pour les pages sensibles à l’authentification avec @rendermode InteractiveWebAssembly (sans prérendu), soit gérez l’état de chargement avec élégance :

<AuthorizeView>
 <Authorized>
 <p>Welcome back, @context.User.Identity?.Name</p>
 </Authorized>
 <Authorizing>
 <p>Loading...</p>
 </Authorizing>
 <NotAuthorized>
 <a href="/login">Sign in</a>
 </NotAuthorized>
</AuthorizeView>

5. Expiration des jetons dans les circuits de longue durée

Les circuits Blazor Server peuvent rester en vie pendant des heures. Si votre jeton ou votre session expire, l’utilisateur reste « authentifié » dans l’interface utilisateur mais les appels d’API commencent à échouer.

Solution : implémentez une vérification périodique ou utilisez un RevalidatingServerAuthenticationStateProvider :

public class RevalidatingAuthStateProvider
 : RevalidatingServerAuthenticationStateProvider
{
 private readonly IServiceScopeFactory _scopeFactory;

 public RevalidatingAuthStateProvider(
 ILoggerFactory loggerFactory,
 IServiceScopeFactory scopeFactory)
 : base(loggerFactory)
 {
 _scopeFactory = scopeFactory;
 }

 protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(30);

 protected override async Task<bool> ValidateAuthenticationStateAsync(
 AuthenticationState authenticationState, CancellationToken cancellationToken)
 {
 await using var scope = _scopeFactory.CreateAsyncScope();
 var userManager = scope.ServiceProvider
 .GetRequiredService<UserManager<IdentityUser>>();

 var user = await userManager.GetUserAsync(authenticationState.User);
 return user is not null;
 }
}

Cela confirme que l’utilisateur existe toujours (et que son cachet de sécurité n’a pas changé) toutes les 30 minutes.

Conclusion

L’authentification et l’autorisation dans Blazor nécessitent un changement de mentalité par rapport à l’ASP.NET traditionnel demande-réponse. L’abstraction AuthenticationStateProvider est la clé pour comprendre comment tout cela s’articule : une fois que vous avez intériorisé cela, le reste suit naturellement.

Pour la plupart des applications, commencez par ASP.NET Identity et les modèles intégrés. Ils gèrent le gros du travail de la gestion des utilisateurs, du hachage des mots de passe et de la génération de jetons. Ajoutez des politiques et des autorisations basées sur les revendications à mesure que vos besoins augmentent. Ajoutez des fournisseurs OAuth externes lorsque vos utilisateurs les attendent.

Le modèle d’hébergement est important : Blazor Server vous offre une posture de sécurité plus traditionnelle dans laquelle le code reste sur le serveur, tandis que WebAssembly vous pousse vers une réflexion axée sur l’API où le client n’est pas fiable de par sa conception. Ni l’un ni l’autre n’est intrinsèquement plus sûr : ils ont simplement des modèles de menace différents.

Quelle que soit l’approche que vous choisissez, n’oubliez pas la règle d’or : l’autorisation dans l’interface utilisateur est destinée à l’expérience utilisateur, l’autorisation sur le serveur est destinée à la sécurité. Appliquez toujours les deux.

JavaScript isolé dans Blazor avec des fichiers JS colocalisés

Wed, 18 Jun 2025 00:00:00 +0000

Si vous avez déjà travaillé avec Blazor et JS Interop, vous vous êtes probablement retrouvé avec un énorme fichier app.js rempli de fonctions aléatoires pour différents composants. Cela fonctionne, mais ça devient vite compliqué. Heureusement, il existe une approche beaucoup plus propre : les fichiers JavaScript colocalisés.

L’idée

Tout comme l’isolation CSS, Blazor vous permet de placer un fichier .razor.js à côté de votre composant. Le module JavaScript est chargé à la demande, uniquement lorsque le composant en a réellement besoin. Pas de scripts globaux, pas de pollution.

Le configurer

Disons que nous avons un composant Clipboard.razor qui copie le texte dans le presse-papiers. Créez un fichier appelé Clipboard.razor.js juste à côté :

export function copyToClipboard(text) {
 navigator.clipboard.writeText(text).then(() => {
 console.log("Copied to clipboard!");
 });
}

Notez le mot-clé export — c’est important. Blazor le charge comme un module ES standard.

Chargement du module dans Blazor

Dans votre composant, vous utilisez IJSRuntime pour importer le module. Le chemin suit une convention : ./_content/{ASSEMBLY_NAME}/{COMPONENT_PATH}.razor.js pour les bibliothèques, ou simplement le chemin relatif du projet en cours.

@inject IJSRuntime JS
@implements IAsyncDisposable

<button @onclick="Copy">Copy to clipboard</button>

@code {
 [Parameter]
 public string Text { get; set; }

 private IJSObjectReference? module;

 protected override async Task OnAfterRenderAsync(bool firstRender)
 {
 if (firstRender)
 {
 module = await JS.InvokeAsync<IJSObjectReference>(
 "import", "./Components/Clipboard.razor.js");
 }
 }

 private async Task Copy()
 {
 if (module is not null)
 {
 await module.InvokeVoidAsync("copyToClipboard", Text);
 }
 }

 public async ValueTask DisposeAsync()
 {
 if (module is not null)
 {
 await module.DisposeAsync();
 }
 }
}

Quelques points à noter ici :

Nous chargeons le module dans OnAfterRenderAsync car JS Interop n’est pas disponible lors du prérendu côté serveur
On garde une référence au module avec IJSObjectReference
Nous implémentons IAsyncDisposable pour nettoyer le module lorsque le composant est détruit

Pourquoi c’est mieux

Avant, je mettais tout dans un seul wwwroot/js/app.js. Cela a fonctionné, mais trouver des fonctions était pénible, et chaque page chargeait du JavaScript dont elle n’avait pas besoin. Avec les fichiers JS colocalisés :

Chaque composant possède son propre JavaScript
Les modules sont chargés paresseusement, uniquement en cas de besoin
Aucun conflit de nom de fonction global
Plus facile à maintenir et à supprimer — lorsque vous supprimez le composant, vous supprimez le JS avec lui

Un piège avec le chemin

Le chemin que vous transmettez à import dépend si vous vous trouvez dans une application Blazor autonome ou dans une bibliothèque de classes Razor. Pour une application Blazor standard, le chemin est relatif à wwwroot. Le fichier .razor.js y est copié au moment de la construction, vous le référencez donc à partir de l’emplacement du composant dans le projet.

Si vous obtenez un 404 lors du chargement du module, vérifiez le chemin et assurez-vous que le fichier se termine par .razor.js, pas seulement .js.

J’espère que vous avez aimé le message ! N’hésitez pas à me contacter sur tous les réseaux sociaux à @emimontesdeoca.

Ressources

JavaScript ASP.NET Core Blazor avec JS coimplanté

Interactivité Blazor dans .NET 9 et .NET 10 : un guide complet

Sun, 15 Jun 2025 00:00:00 +0000

Si vous avez créé des applications Web avec Blazor au cours des dernières années, vous savez que le framework a parcouru un long chemin. Ce qui a commencé comme un choix entre Blazor Server et Blazor WebAssembly a évolué vers un modèle de rendu unifié et flexible qui vous permet de choisir la bonne stratégie d’interactivité pour chaque composant de votre application.

Avec .NET 8, nous avons obtenu un changement fondamental : l’introduction des modes de rendu et du rendu statique côté serveur (SSR) par défaut. Désormais, .NET 9 et .NET 10 s’appuient sur cette base avec des améliorations qui rendent l’expérience du développeur plus fluide et celle de l’utilisateur final plus rapide.

Dans cet article, je souhaite vous présenter l’image complète de l’interactivité de Blazor telle qu’elle existe aujourd’hui : comment fonctionnent les modes de rendu, ce que le streaming SSR apporte, comment la navigation améliorée et la gestion des formulaires changent le jeu, et les nouveautés des dernières versions. Si vous planifiez un nouveau projet Blazor ou envisagez une mise à niveau, c’est le guide que j’aurais aimé avoir lorsque j’ai commencé à approfondir tout cela.

Un rapide retour en arrière : comment nous en sommes arrivés là

Avant .NET 8, vous deviez vous engager dans un modèle d’hébergement au niveau du projet. Blazor Server signifiait que tout fonctionnait sur le serveur via une connexion SignalR. Blazor WebAssembly signifiait que tout fonctionnait dans le navigateur. Chacun avait des compromis, et les mélanger était douloureux.

.NET 8 a changé la donne en introduisant un modèle de projet unique – la Blazor Web App – qui unifie les deux modèles. Le concept clé est les modes de rendu : vous décidez par composant comment il doit être rendu et où l’interactivité se produit. La valeur par défaut est devenue SSR statique, ce qui signifie que les composants s’affichent sur le serveur et envoient du HTML brut au navigateur - pas de SignalR, pas de WebAssembly, juste du HTML rapide.

.NET 9 a peaufiné ces concepts, amélioré l’expérience des développeurs et optimisé les performances. .NET 10 va plus loin avec une meilleure gestion des reconnexions, un état persistant des composants dans tous les modes de rendu et des améliorations dans la façon dont le script Blazor lui-même est fourni.

Décomposons tout cela.

Modes de rendu dans .NET 9

Au cœur du Blazor moderne se trouve le concept de modes de rendu. Il existe quatre modes que vous devez connaître :

1. SSR statique (par défaut)

Lorsque vous créez une nouvelle application Web Blazor, les composants s’affichent par défaut de manière statique sur le serveur. Le serveur traite le composant Razor, génère du HTML et l’envoie au navigateur. Il n’y a pas de connexion persistante, pas de runtime WebAssembly - juste une requête/réponse traditionnelle.

C’est parfait pour les pages riches en contenu, les tableaux de bord qui affichent principalement des données ou toute page sur laquelle vous n’avez pas besoin d’interaction en temps réel.

@page "/products"

<h1>Our Products</h1>

@foreach (var product in products)
{
 <div class="product-card">
 <h3>@product.Name</h3>
 <p>@product.Description</p>
 <span class="price">@product.Price.ToString("C")</span>
 </div>
}

@code {
 private List<Product> products = new();

 protected override async Task OnInitializedAsync()
 {
 products = await ProductService.GetAllAsync();
 }
}

Ce composant s’affiche sur le serveur, produit du HTML, et c’est tout. Aucune connexion continue. Chargement initial rapide, idéal pour le référencement, utilisation minimale des ressources du serveur.

2. Serveur interactifLorsque vous avez besoin d’interactivité en temps réel (gestion des clics sur les boutons, traitement des entrées utilisateur, mise à jour dynamique de l’interface utilisateur), vous pouvez opter pour le mode Serveur interactif. Cela établit une connexion SignalR entre le navigateur et le serveur, et les mises à jour de l’interface utilisateur s’effectuent via cette connexion.

@page "/counter"
@rendermode InteractiveServer

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
 private int currentCount = 0;

 private void IncrementCount()
 {
 currentCount++;
 }
}

La directive @rendermode InteractiveServer suffit. Le composant s’affiche initialement sur le serveur, puis une connexion SignalR est établie pour gérer les interactions ultérieures. Vos gestionnaires d’événements C# s’exécutent sur le serveur et les différences d’interface utilisateur sont envoyées au navigateur.

Quand l’utiliser : Lorsque vous avez besoin d’interactivité, vos composants doivent accéder aux ressources côté serveur (bases de données, API, systèmes de fichiers) et vous souhaitez un chargement initial rapide sans attendre le téléchargement de WebAssembly.

3. WebAssembly interactif

Si vous souhaitez une interactivité sans maintenir une connexion serveur, Interactive WebAssembly exécute la logique de votre composant directement dans le navigateur à l’aide du runtime .NET WebAssembly.

@page "/search"
@rendermode InteractiveWebAssembly

<h1>Product Search</h1>

<input @bind="searchTerm" @bind:event="oninput" placeholder="Search products..." />

@if (filteredProducts.Any())
{
 <ul>
 @foreach (var product in filteredProducts)
 {
 <li>@product.Name — @product.Price.ToString("C")</li>
 }
 </ul>
}

@code {
 private string searchTerm = string.Empty;
 private List<Product> allProducts = new();
 private IEnumerable<Product> filteredProducts => allProducts
 .Where(p => p.Name.Contains(searchTerm, StringComparison.OrdinalIgnoreCase));

 protected override async Task OnInitializedAsync()
 {
 allProducts = await Http.GetFromJsonAsync<List<Product>>("api/products") ?? new();
 }
}

Le compromis : il existe un coût de téléchargement initial pour le runtime .NET et vos assemblys. Mais une fois chargé, le composant s’exécute entièrement dans le navigateur, sans allers-retours entre le serveur et les interactions avec l’interface utilisateur.

Quand l’utiliser : Pour les composants hautement interactifs où la latence est importante (pensez : éditeurs de texte enrichi, outils de dessin, filtrage en temps réel), lorsque vous souhaitez réduire la charge du serveur ou lorsque vous créez une application Web progressive (PWA).

4. Automatique interactif

C’est le juste milieu pragmatique et l’une de mes fonctionnalités préférées. Interactive Auto commence par le rendu côté serveur via SignalR pour le premier chargement, puis télécharge silencieusement le runtime WebAssembly en arrière-plan. Lors des visites ultérieures, le composant s’exécute sur WebAssembly.

@page "/dashboard"
@rendermode InteractiveAuto

<h1>Dashboard</h1>

<DashboardWidget Title="Sales" Value="@salesTotal" />
<DashboardWidget Title="Users" Value="@activeUsers" />

<button @onclick="RefreshData">Refresh</button>

@code {
 private decimal salesTotal;
 private int activeUsers;

 protected override async Task OnInitializedAsync()
 {
 await RefreshData();
 }

 private async Task RefreshData()
 {
 var data = await DashboardService.GetSummaryAsync();
 salesTotal = data.SalesTotal;
 activeUsers = data.ActiveUsers;
 }
}

Cela vous offre le meilleur des deux mondes : un premier rendu rapide (pas d’attente pour le téléchargement WASM) et finalement le composant s’exécute côté client. L’utilisateur ne remarque pas la transition.

Quand l’utiliser : Lorsque vous souhaitez à la fois des chargements initiaux rapides et une éventuelle exécution côté client. C’est un excellent choix par défaut pour de nombreux composants interactifs.

Streaming SSR : le meilleur des deux mondes

Le streaming SSR est l’une de ces fonctionnalités qui semblent simples mais qui font une énorme différence dans les performances perçues. Voici l’idée : au lieu d’attendre que toutes vos données soient chargées avant d’envoyer du code HTML, le serveur envoie immédiatement le shell de la page, puis diffuse les mises à jour du contenu à mesure que les données deviennent disponibles.

@page "/reports"
@attribute [StreamRendering]

<h1>Monthly Reports</h1>

@if (reports is null)
{
 <div class="loading-spinner">
 <p>Loading reports...</p>
 </div>
}
else
{
 <table class="table">
 <thead>
 <tr>
 <th>Month</th>
 <th>Revenue</th>
 <th>Growth</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var report in reports)
 {
 <tr>
 <td>@report.Month</td>
 <td>@report.Revenue.ToString("C")</td>
 <td class="@(report.Growth >= 0 ? "text-success" : "text-danger")">
 @report.Growth.ToString("P1")
 </td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private List<MonthlyReport>? reports;

 protected override async Task OnInitializedAsync()
 {
 // This might take a couple of seconds
 reports = await ReportService.GetMonthlyReportsAsync();
 }
}

Avec l’attribut [StreamRendering], voici ce qui se passe :

Le serveur envoie immédiatement le code HTML avec la flèche de chargement.
OnInitializedAsync exécute et récupère les données.
Lorsque les données arrivent, le serveur diffuse le code HTML mis à jour (le tableau) vers le navigateur.
Le navigateur corrige le DOM sans recharger la page complète.

L’utilisateur voit la page instantanément avec un indicateur de chargement, puis le contenu se remplit. Aucun framework JavaScript n’est nécessaire. Aucune connexion WebSocket. Juste une utilisation intelligente du streaming HTTP.Quand l’utiliser : Toute page SSR statique qui récupère des données pendant le rendu. Pages de liste de produits, tableaux de bord, rapports — partout où le chargement initial des données peut prendre plus de quelques centaines de millisecondes.

Quand NE PAS l’utiliser : Si les données se chargent extrêmement rapidement (moins de 100 ms), la surcharge de streaming n’en vaut pas la peine. De plus, le streaming SSR ne vous offre pas une interactivité continue – pour cela, vous avez toujours besoin d’un mode de rendu interactif.

L’une des améliorations subtiles mais puissantes du Blazor moderne est la navigation améliorée. Par défaut, Blazor intercepte les clics sur les liens internes et les soumissions de formulaires, récupérant le contenu de la nouvelle page via fetch et corrigeant le DOM plutôt que d’effectuer une navigation complète dans le navigateur.

Cela signifie que la navigation entre les pages SSR statiques ressemble à un SPA : pas de flash de page entière, la position de défilement peut être préservée et l’expérience est douce et soyeuse.

Comment ça marche

Lorsque le script Blazor (blazor.web.js) est chargé, il intercepte automatiquement les clics sur les liens internes. Au lieu d’une navigation traditionnelle dans un navigateur, il :

Effectue une requête fetch à l’URL cible.
Reçoit la réponse HTML.
Fusionne le nouveau contenu dans le DOM existant.
Met à jour l’URL et l’historique du navigateur.

Vous n’avez rien à faire pour l’activer – c’est activé par défaut. Mais vous pouvez le contrôler :

<!-- Disable enhanced navigation for a specific link -->
<a href="/legacy-page" data-enhance-nav="false">Legacy Page</a>

<!-- Force a full page reload for external-like behavior -->
<a href="/downloads/report.pdf" data-enhance-nav="false">Download Report</a>

Gestion améliorée des formulaires

Les formulaires bénéficient du même traitement. Lorsque vous utilisez EditForm ou l’élément standard <form> avec la gestion des formulaires de Blazor, les soumissions sont interceptées et traitées via fetch :

@page "/contact"

<EditForm Model="contactModel" OnValidSubmit="HandleSubmit" FormName="contact" Enhance>
 <DataAnnotationsValidator />

 <div class="mb-3">
 <label for="name">Name</label>
 <InputText id="name" @bind-Value="contactModel.Name" class="form-control" />
 <ValidationMessage For="() => contactModel.Name" />
 </div>

 <div class="mb-3">
 <label for="email">Email</label>
 <InputText id="email" @bind-Value="contactModel.Email" class="form-control" />
 <ValidationMessage For="() => contactModel.Email" />
 </div>

 <div class="mb-3">
 <label for="message">Message</label>
 <InputTextArea id="message" @bind-Value="contactModel.Message" class="form-control" />
 <ValidationMessage For="() => contactModel.Message" />
 </div>

 <button type="submit" class="btn btn-primary">Send</button>
</EditForm>

@code {
 [SupplyParameterFromForm]
 private ContactModel contactModel { get; set; } = new();

 private async Task HandleSubmit()
 {
 await ContactService.SubmitAsync(contactModel);
 contactModel = new ContactModel();
 }
}

L’attribut Enhance sur EditForm indique à Blazor d’intercepter la soumission du formulaire. Le formulaire est publié sur le serveur, le serveur le traite et restitue la page, et le HTML mis à jour est renvoyé, le tout sans navigation sur une page complète. Cela semble interactif, mais c’est entièrement rendu par le serveur.

Notez l’attribut [SupplyParameterFromForm] : c’est ainsi que Blazor lie les données de formulaire publiées à votre modèle dans des scénarios SSR statiques. C’est le pont entre les poteaux de formulaire traditionnels et le modèle de composants de Blazor.

Interactivité par page et par composant

L’un des aspects les plus puissants du nouveau modèle est que vous pouvez mélanger les modes de rendu au sein d’une seule application. Votre page de liste de produits peut être un SSR statique, votre panier peut être un serveur interactif et votre configurateur de produit peut être un WebAssembly interactif, le tout dans la même application.

Définition des modes de rendu au niveau des composants

Vous pouvez définir le mode de rendu directement sur un composant à l’aide de la directive @rendermode :

@* This component is interactive via Server *@
@rendermode InteractiveServer

<h3>Live Chat</h3>
<!-- chat UI here -->

Ou vous pouvez le définir lors de l’utilisation d’un composant d’un parent :

@page "/product/{Id:int}"

<h1>@product?.Name</h1>
<p>@product?.Description</p>

<!-- This child component gets its own interactive render mode -->
<ProductConfigurator Product="product" @rendermode="InteractiveWebAssembly" />

<!-- This stays static -->
<ProductReviews ProductId="Id" />

@code {
 [Parameter] public int Id { get; set; }
 private Product? product;

 protected override async Task OnInitializedAsync()
 {
 product = await ProductService.GetByIdAsync(Id);
 }
}

Dans cet exemple, la page elle-même est un SSR statique. Le composant ProductConfigurator s’exécute sur WebAssembly pour une riche interactivité côté client. Le composant ProductReviews reste statique car il affiche simplement des données.

Définition des modes de rendu globalement

Si vous souhaitez que toutes les pages soient interactives par défaut, vous pouvez définir le mode de rendu au niveau racine dans App.razor :

<Routes @rendermode="InteractiveServer" />
```Cela rend chaque page interactive via le rendu du serveur. Les composants individuels peuvent toujours remplacer cela si nécessaire.

### Règles importantes à retenir

Il y a quelques contraintes à garder à l'esprit lors du mélange des modes de rendu :

- **Un composant enfant ne peut pas avoir un mode de rendu "plus interactif" que son parent.** Si un parent est statique, les enfants peuvent être statiques ou interactifs. Mais si un parent est Interactive Server, un enfant ne peut pas être Interactive WebAssembly (il devra être Server ou Auto).
- **Les composants interactifs ne peuvent pas utiliser directement les services étendus des parents statiques.** Si un composant s'exécute sur WebAssembly, il ne peut pas accéder directement aux instances `DbContext` côté serveur — vous aurez besoin d'une couche API.
- **L'état n'est pas automatiquement transféré entre les modes de rendu.** Si un composant effectue un pré-rendu sur le serveur puis passe à WebAssembly, vous devez gérer explicitement la persistance de l'état - plus d'informations à ce sujet dans la section .NET 10.

## Quoi de neuf dans .NET 10

.NET 10 poursuit l'approche d'amélioration incrémentielle, en se concentrant sur la fiabilité et l'expérience des développeurs. Voici les points forts de l’interactivité de Blazor :

### Expérience de reconnexion améliorée

Si vous avez utilisé le mode Serveur interactif en production, vous avez probablement rencontré la superposition de reconnexion : ce moment où la connexion SignalR est interrompue et l'utilisateur voit un message "Reconnexion...". Dans .NET 10, cette expérience s’améliore considérablement.

La logique de reconnexion est désormais plus intelligente en matière de nouvelle tentative. Au lieu d'un intervalle de nouvelle tentative fixe, il utilise une stratégie d'attente qui s'adapte à la situation. L'interface utilisateur lors de la reconnexion est également plus raffinée et vous disposez de meilleurs crochets pour personnaliser l'expérience :

```razor
<!-- In your App.razor or layout -->
<div id="components-reconnect-modal">
 <div class="reconnect-visible">
 <p>Connection lost. Attempting to reconnect...</p>
 <div class="spinner"></div>
 </div>
 <div class="reconnect-failed">
 <p>Could not reconnect to the server.</p>
 <button onclick="location.reload()">Reload</button>
 </div>
 <div class="reconnect-rejected">
 <p>Your session has expired.</p>
 <a href="/">Return to Home</a>
 </div>
</div>

Le framework tente désormais également de se reconnecter de manière plus agressive en cas de pannes transitoires et peut restaurer l’état du circuit de manière plus fiable. Cela signifie moins de moments « veuillez recharger la page » pour vos utilisateurs.

État persistant des composants dans les modes de rendu

C’est un gros problème. Dans .NET 9, lorsqu’un composant effectue un pré-rendu sur le serveur puis passe à WebAssembly (ou passe d’un mode de rendu à l’autre), l’état du composant est perdu. Le composant se réinitialise efficacement, ce qui peut entraîner des récupérations de données en double et un scintillement de l’interface utilisateur.

.NET 10 améliore le service PersistentComponentState pour fonctionner de manière plus transparente lors des transitions en mode rendu :

@page "/weather"
@rendermode InteractiveWebAssembly
@inject PersistentComponentState ApplicationState

<h1>Weather Forecast</h1>

@if (forecasts is null)
{
 <p>Loading...</p>
}
else
{
 @foreach (var forecast in forecasts)
 {
 <div class="forecast-card">
 <h4>@forecast.Date.ToShortDateString()</h4>
 <p>@forecast.Summary — @forecast.TemperatureC°C</p>
 </div>
 }
}

@code {
 private List<WeatherForecast>? forecasts;
 private PersistingComponentStateSubscription persistingSubscription;

 protected override async Task OnInitializedAsync()
 {
 persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);

 if (!ApplicationState.TryTakeFromJson<List<WeatherForecast>>(
 "weather-forecasts", out var restored))
 {
 // Data wasn't persisted from prerendering — fetch it
 forecasts = await Http.GetFromJsonAsync<List<WeatherForecast>>("api/weather");
 }
 else
 {
 forecasts = restored;
 }
 }

 private Task PersistData()
 {
 ApplicationState.PersistAsJson("weather-forecasts", forecasts);
 return Task.CompletedTask;
 }

 public void Dispose()
 {
 persistingSubscription.Dispose();
 }
}

Avec les améliorations apportées à .NET 10, ce modèle fonctionne de manière plus fiable. L’état sérialisé lors du prérendu est correctement disponible lorsque le composant s’initialise dans son mode interactif, évitant ainsi les doubles récupérations de données et le bref scintillement que les utilisateurs pourraient voir.

Blazor Script en tant qu’actif Web statique

Dans les versions précédentes, le fichier JavaScript Blazor (blazor.web.js) était servi à partir du point de terminaison interne du framework. Dans .NET 10, il est fourni sous forme de ressource Web statique. Cela peut sembler un petit changement, mais il présente des avantages pratiques :- Meilleure mise en cache : Les ressources Web statiques obtiennent des en-têtes de cache appropriés et des URL avec empreintes digitales, afin que les navigateurs les mettent en cache plus efficacement.

Compatible avec les CDN : Puisqu’il s’agit d’un fichier statique standard, les CDN peuvent le mettre en cache et le servir à partir d’emplacements périphériques.
Compression : La compression statique des ressources Web s’applique automatiquement, réduisant ainsi la taille du script sur le fil.

Vous n’avez pas besoin de modifier la façon dont vous le référencez : le framework gère automatiquement le chemin mis à jour.

Bonnes pratiques : choisir le bon mode de rendu

Après avoir travaillé avec tous ces modes sur plusieurs projets, voici mon cadre de décision :

Commencez avec le SSR statique

Faites du SSR statique votre valeur par défaut. La plupart des pages de la plupart des applications concernent principalement l’affichage de données. Pages de produits, articles de blog, profils d’utilisateurs, pages de paramètres : ils n’ont pas besoin d’interactivité en temps réel. Le SSR statique vous offre les meilleures performances, la plus faible utilisation des ressources et le modèle mental le plus simple.

Ajoutez de l’interactivité uniquement là où cela est nécessaire

Identifiez les composants spécifiques qui doivent répondre aux interactions des utilisateurs en temps réel. Un bouton « J’aime », un widget de chat, une interface glisser-déposer : tout cela a besoin d’interactivité. Mais la page qui les entoure ne le fait probablement pas.

Utilisez Interactive Auto comme mode interactif incontournable

Lorsque vous avez besoin d’interactivité, Interactive Auto est souvent le meilleur choix par défaut. Il vous offre des chargements initiaux rapides (rendu serveur) avec une éventuelle exécution côté client (WebAssembly). L’utilisateur obtient le meilleur des deux mondes et vous écrivez votre code une seule fois.

Réserver le serveur interactif pour des cas spécifiques

Utilisez Interactive Server dans les cas suivants :

Votre composant a besoin d’un accès direct aux ressources du serveur (bases de données, système de fichiers, API internes).
La taille du téléchargement de WebAssembly est un problème et vous ne pouvez pas utiliser Auto.
Vous avez besoin que le composant s’exécute toujours sur le serveur pour des raisons de sécurité (par exemple, traitement de données sensibles).

Utilisez généreusement le Streaming SSR

Si vos pages SSR statiques récupèrent des données, ajoutez [StreamRendering]. Le coût est minime et l’amélioration perçue des performances est significative. Les utilisateurs voient le contenu apparaître progressivement plutôt que de regarder une page blanche.

Gérez les transitions d’état avec soin

Si vous utilisez Interactive Auto ou mélangez le pré-rendu avec WebAssembly, utilisez toujours PersistentComponentState pour éviter les récupérations de données en double. Vos utilisateurs vous remercieront pour l’absence de contenu scintillant.

Gardez l’arborescence des composants à l’esprit

N’oubliez pas les règles de hiérarchie du mode de rendu. Planifiez votre arborescence de composants de manière à ce que les limites interactives aient un sens. Un modèle courant consiste à avoir une disposition statique avec des « îlots » interactifs intégrés là où cela est nécessaire :

@* Layout: Static SSR *@
<header>
 <NavMenu />
 <UserMenu @rendermode="InteractiveServer" /> @* Needs real-time auth state *@
</header>

<main>
 @Body
</main>

<footer>
 <ChatWidget @rendermode="InteractiveAuto" /> @* Rich interactivity *@
</footer>

Conclusion

Le modèle d’interactivité de Blazor dans .NET 9 et .NET 10 représente une approche mature et bien pensée pour créer des applications Web. La possibilité de choisir les modes de rendu par composant, la navigation améliorée et transparente, le streaming SSR et les améliorations continues en matière de reconnexion et de gestion de l’état en font un choix incontournable pour un large éventail d’applications.L’idée clé est que l’interactivité est un spectre et non un choix binaire. La plupart de votre application peut être statique. Certaines parties nécessitent une interactivité pilotée par le serveur. Quelques-uns pourraient bénéficier d’une exécution dans le navigateur. Blazor vous permet désormais de faire ce choix avec la granularité la plus fine – le composant individuel – sans combattre le framework.

Si vous démarrez un nouveau projet, mon conseil est simple : créez une application Web Blazor, commencez par un SSR statique, ajoutez [StreamRendering] aux pages riches en données et promouvez les composants individuels vers des modes interactifs uniquement lorsque vous en avez besoin. Vous obtiendrez une application rapide, efficace et bien évolutive.

Bon codage, et comme toujours, n’hésitez pas à nous contacter si vous avez des questions !

API minimales dans .NET : création d'API HTTP légères

Thu, 10 Apr 2025 00:00:00 +0000

Si vous créez des API avec ASP.NET Core depuis un certain temps, vous connaissez probablement très bien l’approche basée sur un contrôleur : créez une classe de contrôleur, décorez-la avec des attributs, injectez vos services via le constructeur et connectez vos routes. Cela fonctionne, et cela fonctionne bien – mais parfois, vous avez l’impression d’écrire beaucoup de cérémonies pour ce qui revient à « accepter cette demande, faire quelque chose, renvoyer une réponse ».

C’est exactement le problème que les API minimales tentent de résoudre. Introduites dans .NET 6, les API minimales vous permettent de définir des points de terminaison HTTP avec très peu de passe-partout. Pas de contrôleurs, pas d’attributs, pas de jonglerie entre les classes de démarrage : il suffit de mapper directement la route vers le gestionnaire dans un style épuré et fonctionnel.

Dans cet article, je souhaite vous expliquer tout ce que vous devez savoir sur les API minimales : depuis votre premier point de terminaison jusqu’à l’organisation des applications volumineuses, en passant par la gestion de l’authentification, de la validation, de la documentation OpenAPI et des considérations de performances. Allons-y.

Pourquoi des API minimales ?

Avant de nous lancer, parlons de pourquoi vous choisiriez les API minimales plutôt que l’approche traditionnelle basée sur les contrôleurs.

Les contrôleurs sont parfaits lorsque vous avez besoin d’un cadre structuré et avisé. Ils vous offrent une liaison de modèle, des filtres, une négociation de contenu et une séparation claire des préoccupations dès le départ. Pour les applications de grande entreprise comptant des dizaines de développeurs, la cohérence assurée par les contrôleurs peut être un réel avantage.

Les API minimales, en revanche, brillent quand vous le souhaitez :

Moins de passe-partout — pas de classes de contrôleur, pas d’attributs [ApiController], pas de configuration de démarrage séparée.
Démarrage plus rapide : moins d’opérations basées sur la réflexion au moment du démarrage.
Modèle mental plus simple — un itinéraire correspond directement à un gestionnaire. C’est ça.
Adapté aux microservices : lorsque votre API comporte 5 à 10 points de terminaison, une configuration complète du contrôleur peut sembler excessive.

La bonne nouvelle est qu’il ne s’agit pas d’une décision à choix. Vous pouvez mélanger des contrôleurs et des API Minimal dans le même projet. Mais une fois que vous serez à l’aise avec l’approche minimale, vous pourriez vous retrouver à l’utiliser plus souvent que prévu.

Pour commencer

Créons une API minimale à partir de zéro. Si le SDK .NET est installé, c’est aussi simple que :

dotnet new web -n MyMinimalApi
cd MyMinimalApi

Cela vous donne un Program.cs qui ressemble à ceci :

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

C’est tout. C’est une API fonctionnelle. Non Startup.cs, pas de classe de contrôleur, pas de configuration de routage. Vous exécutez dotnet run, appuyez sur http://localhost:5000 et vous obtenez « Hello World ! » dos. La simplicité ici est tout l’intérêt.

Rendons-le un peu plus utile avec une API todo classique :

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var todos = new List<Todo>();

app.MapGet("/todos", () => todos);

app.MapGet("/todos/{id:int}", (int id) =>
 todos.FirstOrDefault(t => t.Id == id) is { } todo
 ? Results.Ok(todo)
 : Results.NotFound());

app.MapPost("/todos", (Todo todo) =>
{
 todos.Add(todo);
 return Results.Created($"/todos/{todo.Id}", todo);
});

app.MapDelete("/todos/{id:int}", (int id) =>
{
 var todo = todos.FirstOrDefault(t => t.Id == id);
 if (todo is null) return Results.NotFound();
 todos.Remove(todo);
 return Results.NoContent();
});

app.Run();

record Todo(int Id, string Title, bool IsComplete);

Nous avons un CRUD complet en moins de 30 lignes. C’est le pouvoir de l’approche minimale.

Gestionnaires de routes

Les gestionnaires de routes sont les fonctions qui s’exécutent lorsqu’une requête correspond à une route. Vous disposez de plusieurs options pour les définir.

Expressions Lambda

L’approche la plus courante et ce que vous verrez dans la plupart des exemples :

app.MapGet("/hello", () => "Hello!");
app.MapGet("/hello/{name}", (string name) => $"Hello, {name}!");

Groupes de méthodes

Pour une logique plus complexe, vous pouvez pointer vers une méthode nommée :

app.MapGet("/products", GetProducts);
app.MapPost("/products", CreateProduct);

static IResult GetProducts(AppDbContext db)
 => Results.Ok(db.Products.ToList());

static IResult CreateProduct(Product product, AppDbContext db)
{
 db.Products.Add(product);
 db.SaveChanges();
 return Results.Created($"/products/{product.Id}", product);
}
```C’est mon approche préférée pour tout ce qui va au-delà d’une seule ligne. Il maintient votre section de mappage d'itinéraire propre et lisible : vous pouvez voir en un coup d'œil quels points de terminaison existent sans parcourir les détails de mise en œuvre.

### Fonctions locales

Vous pouvez également utiliser des fonctions locales, ce qui est utile lorsque vous souhaitez garder les gestionnaires proches de leurs définitions de route :

```csharp
app.MapGet("/health", CheckHealth);

IResult CheckHealth()
{
 // Some health check logic
 return Results.Ok(new { Status = "Healthy", Timestamp = DateTime.UtcNow });
}

Liaison de paramètres

L’une des choses que j’apprécie vraiment à propos des API Minimal est la façon dont la liaison des paramètres est intuitive. Le cadre détermine d’où extraire les valeurs en fonction du contexte et du type.

Paramètres d’itinéraire

app.MapGet("/users/{id:int}", (int id) => $"User {id}");
app.MapGet("/files/{*path}", (string path) => $"File: {path}"); // catch-all

Paramètres de chaîne de requête

app.MapGet("/search", (string? query, int page = 1, int pageSize = 20) =>
 Results.Ok(new { query, page, pageSize }));

Les types nullables deviennent des paramètres facultatifs. Les valeurs par défaut fonctionnent exactement comme prévu.

Corps de la demande

app.MapPost("/orders", (Order order) =>
{
 // 'order' is automatically deserialized from the JSON body
 return Results.Created($"/orders/{order.Id}", order);
});

Liaison d’en-tête et de service

app.MapGet("/protected", (
 [FromHeader(Name = "X-Api-Key")] string apiKey,
 [FromServices] ILogger<Program> logger) =>
{
 logger.LogInformation("Request with API key: {Key}", apiKey[..4] + "****");
 return Results.Ok("Authorized");
});

HttpContext et HttpRequest

Lorsque vous avez besoin d’un accès de niveau inférieur :

app.MapGet("/info", (HttpContext context) =>
{
 var userAgent = context.Request.Headers.UserAgent.ToString();
 var ip = context.Connection.RemoteIpAddress?.ToString();
 return Results.Ok(new { userAgent, ip });
});

Liaison personnalisée avec BindAsync

Pour les types complexes, vous pouvez implémenter une méthode statique BindAsync :

public record PaginationParams(int Page, int PageSize)
{
 public static ValueTask<PaginationParams?> BindAsync(HttpContext context)
 {
 int.TryParse(context.Request.Query["page"], out var page);
 int.TryParse(context.Request.Query["pageSize"], out var pageSize);

 var result = new PaginationParams(
 Page: page > 0 ? page : 1,
 PageSize: pageSize > 0 ? Math.Min(pageSize, 100) : 20
 );

 return ValueTask.FromResult<PaginationParams?>(result);
 }
}

app.MapGet("/items", (PaginationParams pagination, AppDbContext db) =>
{
 var items = db.Items
 .Skip((pagination.Page - 1) * pagination.PageSize)
 .Take(pagination.PageSize)
 .ToList();

 return Results.Ok(items);
});

C’est incroyablement puissant. Vous définissez la logique de liaison une fois et la réutilisez sur tous vos points de terminaison.

Validation

Un domaine dans lequel les API minimales ne vous apportent pas autant de choses prêtes à l’emploi que les contrôleurs est la validation des modèles. Il n’y a pas d’application automatique des [Required] ou des [StringLength]. Mais il existe des modèles simples pour le gérer.

Validation manuelle

L’approche la plus simple — il suffit de valider dans le gestionnaire :

app.MapPost("/users", (CreateUserRequest request) =>
{
 if (string.IsNullOrWhiteSpace(request.Email))
 return Results.BadRequest(new { Error = "Email is required" });

 if (request.Name?.Length > 100)
 return Results.BadRequest(new { Error = "Name must be 100 characters or less" });

 // Create user...
 return Results.Created($"/users/{request.Email}", request);
});

Utilisation d’une bibliothèque de validation

Pour tout ce qui n’est pas trivial, je vous recommande de recourir à FluentValidation ou à une bibliothèque similaire :

public class CreateUserValidator : AbstractValidator<CreateUserRequest>
{
 public CreateUserValidator()
 {
 RuleFor(x => x.Email).NotEmpty().EmailAddress();
 RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
 RuleFor(x => x.Age).InclusiveBetween(0, 150);
 }
}

Vous pouvez connecter cela à vos points de terminaison via des filtres de points de terminaison, ce qui nous amène à la section suivante.

Filtres de point de terminaison

Les filtres de point de terminaison sont l’une des meilleures fonctionnalités des API Minimal. Considérez-les comme un middleware, mais limités à des points de terminaison spécifiques plutôt qu’à l’ensemble du pipeline. Ils ont été introduits dans .NET 7 et conviennent parfaitement aux problèmes transversaux.

Filtre de base

app.MapPost("/todos", (Todo todo) =>
{
 // Handle the request
 return Results.Created($"/todos/{todo.Id}", todo);
})
.AddEndpointFilter(async (context, next) =>
{
 var todo = context.GetArgument<Todo>(0);

 if (string.IsNullOrEmpty(todo.Title))
 {
 return Results.BadRequest(new { Error = "Title is required" });
 }

 return await next(context);
});

Filtre de validation avec FluentValidation

Voici où cela devient vraiment puissant : un filtre de validation réutilisable :

public class ValidationFilter<T> : IEndpointFilter where T : class
{
 private readonly IValidator<T> _validator;

 public ValidationFilter(IValidator<T> validator)
 {
 _validator = validator;
 }

 public async ValueTask<object?> InvokeAsync(
 EndpointFilterInvocationContext context,
 EndpointFilterDelegate next)
 {
 var model = context.Arguments
 .OfType<T>()
 .FirstOrDefault();

 if (model is null)
 return Results.BadRequest(new { Error = "Request body is required" });

 var result = await _validator.ValidateAsync(model);

 if (!result.IsValid)
 {
 var errors = result.Errors
 .GroupBy(e => e.PropertyName)
 .ToDictionary(g => g.Key, g => g.Select(e => e.ErrorMessage).ToArray());

 return Results.ValidationProblem(errors);
 }

 return await next(context);
 }
}

// Usage
app.MapPost("/users", (CreateUserRequest request) =>
{
 // Only reached if validation passes
 return Results.Created($"/users/{request.Email}", request);
})
.AddEndpointFilter<ValidationFilter<CreateUserRequest>>();

Filtre de journalisation

app.MapGet("/products", (AppDbContext db) => db.Products.ToList())
 .AddEndpointFilter(async (context, next) =>
 {
 var logger = context.HttpContext
 .RequestServices.GetRequiredService<ILogger<Program>>();

 var sw = Stopwatch.StartNew();
 var result = await next(context);
 sw.Stop();

 logger.LogInformation("Endpoint executed in {Elapsed}ms", sw.ElapsedMilliseconds);

 return result;
 });

Vous pouvez enchaîner plusieurs filtres et ils s’exécutent dans l’ordre dans lequel ils sont ajoutés, tout comme le middleware.

Intégration OpenAPI / Swagger

Une bonne documentation API n’est plus facultative. Heureusement, les API Minimal bénéficient d’un support de première classe pour OpenAPI via le package Microsoft.AspNetCore.OpenApi.

Configuration de base

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();

app.MapGet("/todos", () => new List<Todo>())
 .WithName("GetTodos")
 .WithDescription("Retrieves all todo items")
 .WithTags("Todos");

app.Run();

Métadonnées riches des points de terminaison

Vous pouvez fournir des informations détaillées sur vos points de terminaison :

app.MapPost("/todos", (Todo todo) =>
{
 return Results.Created($"/todos/{todo.Id}", todo);
})
.WithName("CreateTodo")
.WithDescription("Creates a new todo item")
.WithTags("Todos")
.Accepts<Todo>("application/json")
.Produces<Todo>(StatusCodes.Status201Created)
.Produces(StatusCodes.Status400BadRequest)
.ProducesValidationProblem();

Utilisation de WithOpenApi pour la personnalisation

Pour un contrôle précis sur le document OpenAPI généré :

app.MapGet("/todos/{id:int}", (int id) => Results.Ok(new Todo(id, "Sample", false)))
 .WithOpenApi(operation =>
 {
 operation.Summary = "Get a specific todo";
 operation.Description = "Retrieves a single todo item by its unique identifier.";
 operation.Parameters[0].Description = "The unique identifier of the todo item";
 return operation;
 });

Cela vous donne le même niveau de contrôle de la documentation que vous obtiendriez avec les commentaires XML Swashbuckle sur les contrôleurs, mais d’une manière plus explicite, axée d’abord sur le code.

Authentification et autorisation

La sécurisation des points de terminaison de l’API Minimal suit les mêmes modèles que le reste d’ASP.NET Core : vous les appliquez simplement différemment.

Configuration de base```csharp

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.Authority = “https://your-identity-provider.com”; options.Audience = “your-api”; });

builder.Services.AddAuthorizationBuilder() .AddPolicy(“AdminOnly”, policy => policy.RequireRole(“Admin”)) .AddPolicy(“PremiumUser”, policy => policy.RequireClaim(“subscription”, “premium”));

var app = builder.Build();

app.UseAuthentication(); app.UseAuthorization();


### Application de l'autorisation aux points de terminaison

```csharp
// Require any authenticated user
app.MapGet("/profile", (ClaimsPrincipal user) =>
{
 return Results.Ok(new
 {
 Name = user.FindFirstValue(ClaimTypes.Name),
 Email = user.FindFirstValue(ClaimTypes.Email)
 });
}).RequireAuthorization();

// Require a specific policy
app.MapDelete("/admin/users/{id}", (int id) =>
{
 // Delete user logic
 return Results.NoContent();
}).RequireAuthorization("AdminOnly");

// Allow anonymous access
app.MapGet("/public/health", () => Results.Ok(new { Status = "Healthy" }))
 .AllowAnonymous();

Remarquez comment vous pouvez injecter ClaimsPrincipal directement dans les paramètres de votre gestionnaire – le framework s’occupe du reste. C’est l’une de ces petites choses qui rendent les API Minimal vraiment élégantes.

Organisation des grandes API

L’éléphant dans la pièce avec les API minimales est l’organisation. Lorsque votre Program.cs a 50 points de terminaison, cela devient un gâchis. Voici les modèles que j’utilise pour garder les choses gérables.

Groupes de routes

Les groupes de routage (introduits dans .NET 7) vous permettent de partager la configuration entre les points de terminaison associés :

var todos = app.MapGroup("/todos")
 .WithTags("Todos")
 .RequireAuthorization();

todos.MapGet("/", (AppDbContext db) => db.Todos.ToListAsync());
todos.MapGet("/{id:int}", (int id, AppDbContext db) => db.Todos.FindAsync(id));
todos.MapPost("/", (Todo todo, AppDbContext db) =>
{
 db.Todos.Add(todo);
 db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
});

Tous les points de terminaison du groupe partagent le préfixe /todos, la balise Todos et l’exigence d’autorisation. Faire le ménage.

Méthodes d’extension

C’est le modèle qui évolue vraiment. Déplacez chaque groupe de points de terminaison dans sa propre classe statique :

// Endpoints/TodoEndpoints.cs
public static class TodoEndpoints
{
 public static RouteGroupBuilder MapTodoEndpoints(this WebApplication app)
 {
 var group = app.MapGroup("/todos").WithTags("Todos");

 group.MapGet("/", GetAll);
 group.MapGet("/{id:int}", GetById);
 group.MapPost("/", Create);
 group.MapPut("/{id:int}", Update);
 group.MapDelete("/{id:int}", Delete);

 return group;
 }

 private static async Task<IResult> GetAll(AppDbContext db)
 => Results.Ok(await db.Todos.ToListAsync());

 private static async Task<IResult> GetById(int id, AppDbContext db)
 => await db.Todos.FindAsync(id) is { } todo
 ? Results.Ok(todo)
 : Results.NotFound();

 private static async Task<IResult> Create(Todo todo, AppDbContext db)
 {
 db.Todos.Add(todo);
 await db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
 }

 private static async Task<IResult> Update(int id, Todo updated, AppDbContext db)
 {
 var todo = await db.Todos.FindAsync(id);
 if (todo is null) return Results.NotFound();

 todo.Title = updated.Title;
 todo.IsComplete = updated.IsComplete;
 await db.SaveChangesAsync();

 return Results.Ok(todo);
 }

 private static async Task<IResult> Delete(int id, AppDbContext db)
 {
 var todo = await db.Todos.FindAsync(id);
 if (todo is null) return Results.NotFound();

 db.Todos.Remove(todo);
 await db.SaveChangesAsync();

 return Results.NoContent();
 }
}

// Program.cs — stays clean
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapTodoEndpoints();
app.MapUserEndpoints();
app.MapOrderEndpoints();

app.Run();

Votre Program.cs devient une table des matières pour votre API. Chaque groupe de points de terminaison réside dans son propre fichier. C’est l’approche que je recommande pour les applications de production.

La bibliothèque Carter

Si vous souhaitez encore plus de structure, la bibliothèque Carter propose une approche basée sur des modules :

public class TodoModule : ICarterModule
{
 public void AddRoutes(IEndpointRouteBuilder app)
 {
 app.MapGet("/todos", async (AppDbContext db) =>
 await db.Todos.ToListAsync());

 app.MapPost("/todos", async (Todo todo, AppDbContext db) =>
 {
 db.Todos.Add(todo);
 await db.SaveChangesAsync();
 return Results.Created($"/todos/{todo.Id}", todo);
 });
 }
}

Carter découvre et enregistre automatiquement tous les modules. C’est un bon compromis entre l’approche API minimale brute et les contrôleurs complets.

TypedResults et types de réponses

À partir de .NET 7, vous pouvez utiliser TypedResults au lieu de Results pour les réponses de type sécurisé. Cela peut sembler un petit changement, mais il présente de réels avantages pour la documentation et la testabilité d’OpenAPI.

app.MapGet("/todos/{id:int}", async Task<Results<Ok<Todo>, NotFound>> (int id, AppDbContext db) =>
{
 var todo = await db.Todos.FindAsync(id);
 return todo is not null
 ? TypedResults.Ok(todo)
 : TypedResults.NotFound();
});

Le type de retour Results<Ok<Todo>, NotFound> indique explicitement au framework (et à vos documents OpenAPI) exactement quels types de réponse ce point de terminaison peut produire. Plus de devinettes, plus d’appels manuels Produces<>() pour les cas de base.

Pour plusieurs résultats possibles :

app.MapPost("/todos",
 async Task<Results<Created<Todo>, ValidationProblem, Conflict>>
 (Todo todo, AppDbContext db) =>
{
 if (string.IsNullOrEmpty(todo.Title))
 return TypedResults.ValidationProblem(
 new Dictionary<string, string[]>
 {
 { "Title", new[] { "Title is required" } }
 });

 if (await db.Todos.AnyAsync(t => t.Title == todo.Title))
 return TypedResults.Conflict();

 db.Todos.Add(todo);
 await db.SaveChangesAsync();

 return TypedResults.Created($"/todos/{todo.Id}", todo);
});

J’ai commencé à utiliser TypedResults dans tous les nouveaux projets. Le compilateur détecte les inadéquations entre vos types de retour déclarés et ce que vous retournez réellement, ce qui élimine toute une classe de surprises d’exécution.

Considérations sur les performances

L’un des arguments de vente des API Minimal est la performance, et il vaut la peine de comprendre pourquoi elles sont plus rapides.

Réduction des frais de démarrage. Les contrôleurs s’appuient fortement sur la réflexion pour découvrir les points de terminaison, lier les modèles et appliquer des filtres. Les API minimales utilisent des générateurs de sources (à partir de .NET 7) pour générer du code de liaison au moment de la compilation. Cela signifie moins de travail au démarrage et moins d’allocation de mémoire par requête.

Aucun pipeline MVC. Les API basées sur un contrôleur passent par le pipeline MVC complet : sélection d’actions, liaison de modèle, filtres d’actions, exécution des résultats. Les API minimales ignorent tout cela et passent directement du routage à votre gestionnaire.

Compilation RequestDelegate. Le framework compile vos expressions lambda en instances RequestDelegate optimisées. Le code résultant est très proche de ce que vous écririez à la main si vous travailliez directement avec HttpContext.

Voici quelques conseils pratiques pour maximiser les performances :

// Use AsNoTracking for read-only queries
app.MapGet("/products", async (AppDbContext db) =>
 await db.Products.AsNoTracking().ToListAsync());

// Return results directly — avoid unnecessary allocations
app.MapGet("/count", async (AppDbContext db) =>
 await db.Products.CountAsync());

// Use cancellation tokens for long-running operations
app.MapGet("/report", async (AppDbContext db, CancellationToken ct) =>
 await db.Orders
 .AsNoTracking()
 .GroupBy(o => o.Status)
 .Select(g => new { Status = g.Key, Count = g.Count() })
 .ToListAsync(ct));
```Il convient également de mentionner que l'écart de performances entre les contrôleurs et les API Minimal ne cesse de se réduire à chaque version de .NET. Pour la plupart des applications, la différence ne sera pas votre goulot d'étranglement : vos requêtes de base de données et vos appels de service externe le seront. Choisissez en fonction de l'expérience du développeur et des besoins du projet, et non de critères de référence.

## Conclusion

Les API minimales ont parcouru un long chemin depuis leur introduction dans .NET 6. Ce qui a commencé comme une fonctionnalité de démonstration « hello world » est devenu un choix légitime pour les API de production. Avec des filtres de points de terminaison, des groupes de routage, des résultats saisis et une solide prise en charge d'OpenAPI, vous disposez de tout ce dont vous avez besoin pour créer des services bien structurés et maintenables.

Ma recommandation ? Si vous démarrez un nouveau projet d'API, en particulier un microservice ou une API interne ciblée, essayez sérieusement les API minimales. Utilisez le modèle de méthode d'extension pour l'organisation, appuyez-vous sur les filtres de points de terminaison pour les problèmes transversaux et exploitez `TypedResults` pour la sécurité des types.

Pour les projets existants basés sur un contrôleur, il n'y a pas d'urgence à migrer. Les deux approches fonctionnent bien et vous pouvez même les utiliser côte à côte. Mais la prochaine fois que vous aurez besoin d’ajouter un petit service ou une API interne rapide, ignorez les contrôleurs et optez pour le minimum. Vous pourriez ne pas y retourner.

Bon codage !

Utilisation de CSS isolé dans les composants Blazor

Wed, 12 Mar 2025 00:00:00 +0000

Une chose qui m’a toujours dérangé lorsque je travaillais avec Blazor était la facilité avec laquelle il était possible de casser accidentellement des styles entre des composants. Vous ajouteriez une classe dans un composant et tout à coup, quelque chose d’autre sur une page complètement différente semblerait différent. Il s’avère que Blazor a une solution intégrée pour cela : l’isolation CSS.

Qu’est-ce que l’isolation CSS ?

L’isolation CSS vous permet d’étendre les styles à un composant spécifique. Blazor fait cela en générant un attribut unique pour chaque composant au moment de la construction et en l’ajoutant aux sélecteurs CSS. Vos styles s’appliquent donc uniquement au composant auquel ils appartiennent.

Pas besoin de nommage BEM, pas besoin de hacks de spécificité fous. Juste du CSS propre et étendu.

Comment l’utiliser

Disons que vous disposez d’un composant appelé Card.razor :

<div class="card">
 <h3 class="card-title">@Title</h3>
 <p class="card-body">@ChildContent</p>
</div>

@code {
 [Parameter]
 public string Title { get; set; }

 [Parameter]
 public RenderFragment ChildContent { get; set; }
}

Pour ajouter des styles isolés, il vous suffit de créer un fichier du même nom mais avec l’extension .razor.css. Dans ce cas : Card.razor.css.

.card {
 border: 1px solid var(--color-border);
 border-radius: 8px;
 padding: 1rem;
 background: var(--color-bg-secondary);
}

.card-title {
 font-size: 1.1rem;
 font-weight: 600;
 margin-bottom: 0.5rem;
}

.card-body {
 color: var(--color-text-secondary);
 font-size: 0.9rem;
}

Et c’est tout ! Blazor le récupérera automatiquement et étendra ces styles au composant Card uniquement. Si vous avez une autre classe .card ailleurs, elle ne sera pas affectée.

Comment ça marche sous le capot

Lorsque vous créez votre projet, Blazor réécrit le HTML et le CSS. Votre composant obtient un attribut unique tel que b-3x8qz7k2f1, et les sélecteurs CSS obtiennent cet attribut ajouté :

.card[b-3x8qz7k2f1] {
 border: 1px solid var(--color-border);
 /* ... */
}

Le bundle CSS généré est servi en tant que {ProjectName}.styles.css. Assurez-vous d’avoir ceci dans votre index.html ou _Host.cshtml :

<link href="YourApp.styles.css" rel="stylesheet" />

Si vous manquez ce lien, vos styles isolés n’apparaîtront pas et vous passerez 30 minutes à vous demander ce qui se passe. Croyez-moi, j’y suis allé.

Ciblage des éléments enfants

Une chose à garder à l’esprit est que par défaut, le CSS isolé ne s’applique qu’aux éléments du composant actuel. Si vous souhaitez styliser des éléments à l’intérieur d’un composant enfant, vous avez besoin du combinateur ::deep :

::deep .child-element {
 color: red;
}

Cela indique à Blazor d’appliquer également le style aux éléments correspondants dans les composants enfants. Assez pratique lorsque vous avez un composant wrapper qui doit styliser ses enfants.

Quand l’utiliser

J’utilise désormais l’isolation CSS pour presque tous les composants. Cela garde les choses propres et prévisibles. La seule fois où je ne l’utilise pas, c’est pour des styles véritablement globaux comme les réinitialisations, la typographie ou les variables de thème – ceux-ci sont stockés dans un fichier CSS partagé.

J’espère que vous avez aimé le message ! N’hésitez pas à me contacter sur tous les réseaux sociaux à @emimontesdeoca.

Ressources

Isolement CSS ASP.NET Core Blazor

Contrôler les dépenses de Noël avec Semantic Kernel

Sat, 28 Dec 2024 00:00:00 +0000

## Présentation

À l’approche des fêtes de fin d’année, la gestion des dépenses peut devenir un défi, surtout avec le tourbillon de magasinages et d’achats de cadeaux. Dans cet article de blog, nous explorerons comment tirer parti de l’intelligence artificielle pour vous aider à suivre vos dépenses de Noël à l’aide des technologies .NET. En analysant les reçus grâce à la puissance du noyau sémantique et de l’IA, nous pouvons extraire efficacement des détails clés tels que les noms des magasins, les dates, les listes d’articles et les montants totaux. Cette solution vous permet de surveiller et de gérer sans effort vos dépenses de Noël, vous garantissant ainsi de rester maître de votre budget sans avoir à examiner manuellement les reçus.

Calendrier d’Adviento de Inteligencia Artificial 2024 en Español

Ce projet a été inspiré par ma participation au Calendario de Adviento de Inteligencia Artificial 2024 en Español, un événement en ligne dédié à l’IA. Vous pouvez en savoir plus sur l’événement sur ce lien Dev.to.

Le projet

Pour ce projet, nous utiliserons Azure OpenAI, un service qui nous permet d’utiliser de puissants modèles d’IA tels que GPT-4 pour traiter et analyser des images. Le processus comporte plusieurs étapes, de la configuration du service API backend à l’intégration avec un frontal Blazor pour le téléchargement d’images. Nous utiliserons également .NET Aspire, un composant qui permet de tout connecter de manière transparente.

Prérequis

Avant de plonger dans le code, assurez-vous d’avoir les prérequis suivants :

-.NET 9

Accès Azure OpenAI (clé API)
Visual Studio ou Visual Studio Code
Connaissance de base de Blazor, des clients HTTP et du développement d’API

La solution Visual Studio

Nous finirons par avoir quelque chose comme ça, j’aime garder les choses séparées et avec des noms sympas, alors voici à quoi ça ressemble :

Mais allons-y étape par étape pour créer des choses !

Étape 0 : Les modèles

Le cœur de l’application Receipt Scanner repose sur plusieurs modèles clés qui facilitent l’interaction entre les services front-end, API et IA. Voici les principaux modèles utilisés dans ce projet :

AnalyzeReceiptRequest
Ce modèle représente la structure de demande d’analyse d’un reçu. Il contient la propriété ImageBytes, qui contient le tableau d’octets de l’image du reçu qui sera traitée.
```
public class AnalyzeReceiptRequest
{
 public byte[] ImageBytes { get; set; }
}
```
RéceptionAnalyzeResult
Ce modèle capture le résultat après traitement d’un reçu. Il contient les données structurées extraites du reçu, telles que le nom du magasin, la date, les articles et le montant total.
```
public class ReceiptAnalyzeResult
{
 public DateTime CreatedAt { get; set; }
 public ReceiptData Result { get; set; }
}
```
Données de réception
Il s’agit du modèle qui contient les données structurées des reçus. Il comprend les propriétés du nom du magasin, la date, une liste d’articles (avec le nom et le prix de chaque article) et le montant total sur le reçu.
```
public class ReceiptData
{
 public string Store { get; set; }
 public DateTime? Date { get; set; }
 public List<ReceiptItem> Items { get; set; }
 public decimal? Total { get; set; }
}
```

Article de réception
Chaque élément du reçu est représenté par ce modèle. Il contient le nom de l’article et son prix.

public class ReceiptItem
{
 public string Name { get; set; }
 public decimal? Price { get; set; }
}
```Ces modèles servent de base à la transmission des données entre le client et le serveur, garantissant ainsi un flux fluide d'informations. L'API reçoit l'image du reçu et, en retour, elle traite et renvoie un objet JSON structuré qui peut être facilement consommé par le front-end.

Étape 1 : Configuration du service API backend

La première étape de la création de cette application consiste à configurer un service API pour analyser les images des reçus. Nous utiliserons l’API Azure OpenAI pour extraire les informations des images de reçu. Voici un aperçu de la façon dont tout s’articule :

Service IA – Une plongée en profondeur

Le service IA est au cœur de notre système d’analyse des reçus. Il est chargé de communiquer avec l’API d’Azure OpenAI pour traiter les données d’image et renvoyer des informations significatives. La classe AiApiClient est le client qui gérera toutes les interactions avec l’API Azure OpenAI.

Implémentation du client IA

Le AiApiClient est le composant clé responsable de l’envoi de l’image du reçu (au format tableau d’octets) à l’API Azure OpenAI. Il gère la communication, la journalisation des erreurs et l’analyse des données :

public class AiApiClient
{
 private readonly HttpClient _httpClient;
 private readonly ILogger<AiApiClient> _logger;

 public AiApiClient(HttpClient httpClient, ILogger<AiApiClient> logger)
 {
 _httpClient = httpClient;
 _logger = logger;
 }

 public async Task<ReceiptAnalyzeResult?> AnalyzeAsync(byte[] imageBytes, CancellationToken cancellationToken = default)
 {
 if (imageBytes == null || imageBytes.Length == 0)
 {
 _logger.LogWarning("ImageBytes is null or empty.");
 return null;
 }

 _logger.LogInformation("Sending analyze request with image bytes of length: {Length}", imageBytes.Length);

 var request = new AnalyzeReceiptRequest
 {
 ImageBytes = imageBytes
 };

 try
 {
 var response = await _httpClient.PostAsJsonAsync("/analyze-receipt", request, cancellationToken);

 if (!response.IsSuccessStatusCode)
 {
 _logger.LogWarning("Failed to analyze receipt. StatusCode: {StatusCode}", response.StatusCode);
 return null;
 }

 var analyzeResult = await response.Content.ReadFromJsonAsync<ReceiptAnalyzeResult>(cancellationToken: cancellationToken);

 if (analyzeResult == null)
 {
 _logger.LogWarning("No content received from AI API service.");
 return null;
 }

 _logger.LogInformation("Analysis result received: {AnalyzeResult}", analyzeResult);

 return analyzeResult;
 }
 catch (Exception ex)
 {
 _logger.LogError(ex, "An error occurred while analyzing the receipt.");
 return null;
 }
 }
}

Dans cette partie du code, nous définissons la méthode AnalyzeAsync, qui se charge de :

Envoi du tableau d’octets de l’image à l’API Azure OpenAI.
Gérer les erreurs ou les réponses infructueuses de l’API.
Analyse des données JSON renvoyées en un résultat structuré (ReceiptAnalyzeResult).

Les avantages de séparer cette fonctionnalité en un service dédié (AiApiClient) incluent :

Gestion des erreurs : Gestion centralisée des erreurs telles que des problèmes de réseau ou des réponses non valides.
Journalisation : Journalisation appropriée des demandes et des réponses pour surveiller le comportement du système.

Service API - Gestion des requêtes et des réponses

Le Service API agit comme intermédiaire entre l’application frontale Blazor et le service AI. Ce service est chargé d’accepter les données d’image, de les transmettre au service AI et de renvoyer les résultats de l’analyse au client.

Point de terminaison de l’API

Dans cette étape, nous définissons un point de terminaison d’API simple pour accepter les images de reçus, les transmettre au service AI pour traitement et renvoyer les résultats au client :

using ReceiptScanner.Shared.Clients;
using ReceiptScanner.Shared.Models;

var builder = WebApplication.CreateBuilder(args);

// Add service defaults & Aspire client integrations.
builder.AddServiceDefaults();

// Add services to the container.
builder.Services.AddProblemDetails();

// Register AiApiClient with HttpClient
builder.Services.AddHttpClient<AiApiClient>(client =>
{
 client.BaseAddress = new Uri("https+http://aiservice");
});

// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseExceptionHandler();

if (app.Environment.IsDevelopment())
{
 app.MapOpenApi();
}

// POST endpoint to analyze receipt
app.MapPost("/api/analyze-receipt", async (AnalyzeReceiptRequest request, AiApiClient aiApiClient, ILogger<Program> logger) =>
{
 if (request.ImageBytes == null || request.ImageBytes.Length == 0)
 {
 logger.LogWarning("ImageBytes is null or empty.");
 return Results.BadRequest("ImageBytes is required.");
 }

 logger.LogInformation("Received analyze receipt request with image bytes of length: {Length}", request.ImageBytes.Length);

 try
 {
 var result = await aiApiClient.AnalyzeAsync(request.ImageBytes);

 if (result == null)
 {
 logger.LogWarning("Failed to analyze the receipt.");
 return Results.Problem("Unable to process the receipt at this time. Please try again later.");
 }

 logger.LogInformation("Analysis completed successfully. Result: {Result}", result);

 return Results.Ok(result);
 }
 catch (Exception ex)
 {
 logger.LogError(ex, "An error occurred while processing the receipt.");
 return Results.Problem("An error occurred while processing the receipt. Please try again later.");
 }
});

app.MapDefaultEndpoints();

app.Run();

Ce point de terminaison :

Accepte l’image du reçu dans le corps de la demande.
Appelle la méthode d’endopinte AiService pour envoyer l’image à Azure OpenAI pour traitement.
Renvoie le résultat de l’analyse au client.

Étape 2 : Configuration de l’interface Blazor

Maintenant que nous avons configuré le backend, tournons notre attention vers le frontend Blazor. C’est ici que les utilisateurs peuvent télécharger leurs images de reçus pour analyse et voir les résultats.

Implémentation des pages Blazor

La page Blazor fournit une interface simple où les utilisateurs peuvent télécharger plusieurs images de reçus, puis voir les résultats d’analyse affichés dans un tableau. Voici le code de la page :

@page "/analyzer"
@using ReceiptScanner.Shared.Clients
@using ReceiptScanner.Shared.Models
@using System.Globalization
@inject ApiServiceClient ApiClient
@inject ILogger<Program> Logger

@attribute [StreamRendering]
@rendermode InteractiveServer

<PageTitle>Receipt Analyzer</PageTitle>

<h1 class="text-center my-4">Receipt Analyzer</h1>

<div class="container">
 <p class="lead text-center mb-4">Upload receipt images below to extract their data.</p>

 <!-- File Upload Section -->
 <div class="card mb-4">
 <div class="card-body">
 <InputFile OnChange="HandleFileSelected" multiple class="form-control mb-3" />
 <button class="btn btn-primary w-100" @onclick="ProcessReceipts" disabled="@(!hasFiles)" type="button">
 <span class="@(!processing ? "d-none" : "") spinner-border spinner-border-sm" role="status" aria-hidden="true"></span>
 @if (processing)
 {
 <span>Processing...</span>
 }
 else
 {
 <span>Process Receipts</span>
 }
 </button>
 </div>
 </div>

 <!-- Uploaded Images Preview -->
 @if (fileBytesList.Any())
 {
 <div class="card mb-4">
 <div class="card-header">
 <h5 class="mb-0">Uploaded Receipt Images</h5>
 </div>
 <div class="card-body">
 <div class="row">
 @foreach (var fileBytes in fileBytesList)
 {
 <div class="col-12 col-md-4 mb-3">
 <img src="@($"data:image/jpeg;base64,{Convert.ToBase64String(fileBytes)}")" class="img-fluid rounded" alt="Uploaded receipt" />
 </div>
 }
 </div>
 </div>
 </div>
 }

 <!-- Processing Indicator -->
 @if (processing)
 {
 <div class="alert alert-info text-center" role="alert">
 <strong>Processing receipts...</strong> Please wait while we analyze the uploaded files.
 </div>
 }

 <!-- Analysis Results Section -->
 @if (analyzedReceipts != null && analyzedReceipts.Any())
 {
 <div class="card">
 <div class="card-header">
 <h5 class="mb-0">Analysis Results</h5>
 </div>
 <div class="card-body">
 <table class="table table-striped table-bordered">
 <thead>
 <tr>
 <th>Store</th>
 <th>Date</th>
 <th>Total</th>
 <th>Items</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var receipt in analyzedReceipts)
 {
 <tr>
 <td>@(receipt.Result?.Store ?? "Unknown")</td>
 <td>@(receipt.Result?.Date?.ToString() ?? "Unknown")</td>
 <td>@(receipt.Result?.Total?.ToString("C", ci) ?? "Unknown")</td>
 <td>
 <ul class="list-unstyled">
 @if (receipt.Result?.Items is not null)
 {
 @foreach (var item in receipt.Result?.Items!)
 {
 <li><strong>@item.Name</strong> - @item.Price?.ToString("C", ci)</li>
 }
 }
 </ul>
 </td>
 </tr>
 }
 </tbody>
 </table>
 </div>
 </div>
 }
 else if (processed && (analyzedReceipts == null || !analyzedReceipts.Any()))
 {
 <div class="alert alert-warning text-center" role="alert">
 <strong>No results found.</strong> Please try again with different images or ensure they are clear and legible.
 </div>
 }
</div>

@code {
 private bool hasFiles;
 private bool processing;
 private bool processed;
 private List<byte[]> fileBytesList = new();
 private List<ReceiptAnalyzeResult> analyzedReceipts = new();
 CultureInfo ci = new CultureInfo("es-es");

 private async Task HandleFileSelected(InputFileChangeEventArgs e)
 {
 try
 {
 fileBytesList.Clear();

 foreach (var file in e.GetMultipleFiles())
 {
 var memoryStream = new MemoryStream();
 await file.OpenReadStream().CopyToAsync(memoryStream);
 fileBytesList.Add(memoryStream.ToArray());
 }

 hasFiles = fileBytesList.Any();
 }
 catch (Exception ex)
 {
 Logger.LogError(ex, "Error while handling file upload.");
 }
 }

 private async Task ProcessReceipts()
 {
 if (!hasFiles)
 return;

 processing = true;
 analyzedReceipts.Clear();

 try
 {
 foreach (var fileBytes in fileBytesList)
 {
 var result = await ApiClient.AnalyzeReceiptAsync(fileBytes);
 if (result != null)
 {
 analyzedReceipts.Add(result);
 }
 }
 }
 catch (Exception ex)
 {
 Logger.LogError(ex, "Error while processing receipts.");
 }
 finally
 {
 processing = false;
 processed = true;
 }
 }
}

```Cette page permet aux utilisateurs de télécharger des reçus et affiche les résultats de l'analyse dans un tableau avec les noms des magasins, les dates, les montants totaux et la liste des articles.

<p align="center">
<img src="https://imgur.com/BLswKhm.png">
</p>

## Étape 3 : .NET Aspire

<p align="center">
<img src="https://imgur.com/ja56RWN.png">
</p>

### Qu'est-ce que .NET Aspire ?

.NET Aspire est un ensemble d'outils, de modèles et de packages puissants permettant de créer des applications observables et prêtes pour la production. .NET Aspire est fourni via une collection de packages NuGet qui répondent à des problèmes spécifiques liés au cloud. Les applications cloud natives sont souvent constituées de petits éléments ou de microservices interconnectés plutôt que d'une base de code unique et monolithique. Les applications cloud natives consomment généralement un grand nombre de services, tels que les bases de données, la messagerie et la mise en cache. Pour plus d’informations sur la prise en charge, consultez la politique de prise en charge de .NET Aspire.

Une application distribuée est une application qui utilise des ressources de calcul sur plusieurs nœuds, tels que des conteneurs exécutés sur différents hôtes. Ces nœuds doivent communiquer au-delà des limites du réseau pour fournir des réponses aux utilisateurs. Une application cloud native est un type spécifique d'application distribuée qui tire pleinement parti de l'évolutivité, de la résilience et de la gérabilité des infrastructures cloud.

L'utilisation de **.NET Aspire** pour ce projet offre plusieurs avantages qui améliorent la qualité globale du système, tels que :

### 1. **Journalisation centralisée**

.NET Aspire intègre automatiquement la journalisation dans l'ensemble de l'application, ce qui signifie que vous n'avez pas besoin de configurer manuellement la journalisation pour chaque service. Cela garantit que les journaux sont cohérents et stockés dans un emplacement centralisé, ce qui facilite grandement le débogage et la surveillance.

Par exemple, la classe `AiApiClient` utilise la journalisation pour enregistrer les octets d'image envoyés au service AI, les réponses de l'API et toutes les erreurs qui se produisent pendant le processus d'analyse.

```csharp
_logger.LogInformation("Sending analyze request with image bytes of length: {Length}",

 imageBytes.Length);

2. Collecte automatique de métriques

.NET Aspire suit et rapporte également automatiquement les mesures d’application importantes telles que les temps de réponse, le nombre de demandes et les taux d’erreur. Cela vous aide à comprendre les performances de l’application et à détecter rapidement les goulots d’étranglement ou les problèmes.

3. Performances améliorées

.NET Aspire optimise les appels HTTP, ce qui permet de maintenir des temps de réponse faibles et de réduire la consommation inutile de ressources. Il fournit des fonctionnalités telles que le regroupement de connexions, les tentatives de requêtes et le routage intelligent.

4. Intégration transparente

.NET Aspire simplifie l’intégration de divers services (comme les services IA et API de ce projet) et rationalise le processus de déploiement. Vous n’avez pas à vous soucier des configurations de bas niveau, car Aspire s’occupe pour vous des tâches liées à l’infrastructure.

###ConclusionL’IA n’est plus seulement un mot à la mode ou quelque chose que l’on voit dans les films de science-fiction. Il résout activement des problèmes du monde réel aujourd’hui, comme celui que nous avons abordé dans ce projet : extraire des données structurées à partir de reçus. Avec l’aide de Azure OpenAI, .NET Aspire et Blazor, nous pouvons automatiser ce qui serait autrement une tâche manuelle fastidieuse et sujette aux erreurs. L’IA ne se contente pas de discuter ou de répondre à des invites comme ChatGPT ; il interprète les images, extrait des informations précieuses et nous donne des informations exploitables en quelques secondes.

En utilisant Azure OpenAI pour l’analyse des reçus et .NET Aspire pour une intégration transparente avec la journalisation et les métriques, nous avons créé une solution à la fois puissante et évolutive. Le potentiel de l’IA pour rationaliser les processus métiers, automatiser les tâches fastidieuses et améliorer la précision est énorme, et ce n’est qu’un exemple de la façon dont elle peut être appliquée.

Cet article fait partie du Calendario de Adviento de Inteligencia Artificial 2024 en Español, un événement qui présente des applications d’IA du monde réel et sensibilise la communauté technologique hispanophone aux dernières tendances. Si vous souhaitez approfondir votre connaissance de l’IA et de ses possibilités, cet événement est un excellent point de départ.

L’IA transforme notre façon de travailler, et ce projet n’est qu’un aperçu de ce qui est possible. Le véritable pouvoir de l’IA réside dans sa capacité à résoudre des problèmes réels, qu’il s’agisse de traiter des reçus, d’analyser des images ou de prédire des tendances. Nous ne faisons qu’effleurer la surface.

###Code source

Le code source complet de ce projet est disponible sur GitHub. N’hésitez pas à le télécharger, à découvrir comment les services IA et API fonctionnent ensemble et à l’adapter à vos propres cas d’utilisation. Si vous rencontrez des problèmes ou si vous avez des idées d’amélioration, n’hésitez pas à créer un problème ou à soumettre une pull request. Les contributions sont toujours les bienvenues et vos commentaires contribueront à rendre ce projet encore meilleur !

Bon codage !

Utiliser des conteneurs pour... suivre les prix des cadeaux de Noël ?

Thu, 12 Dec 2024 00:00:00 +0000

Noël approche à grands pas et avec lui vient la joyeuse tâche de trouver les cadeaux parfaits pour vos proches. Si vous êtes comme moi, vous aimez probablement faire de bonnes affaires, mais naviguer dans la montée en flèche des prix des articles populaires pendant la période des fêtes peut ressembler à une véritable promenade en traîneau : excitant mais un peu écrasant ! Cette année, au lieu de me rendre fou avec des contrôles de prix quotidiens, j’ai décidé de mettre à profit mes compétences techniques et d’automatiser le processus.

En tant que développeur de logiciels et passionné par l’utilisation de la technologie pour résoudre les problèmes quotidiens, j’ai trouvé un moyen d’automatiser le processus de vérification des prix. Au lieu de visiter manuellement plusieurs boutiques en ligne chaque jour pour comparer les prix, j’ai décidé de créer un système capable de le faire à ma place. Cela me fait non seulement gagner du temps, mais garantit également que j’obtiens les meilleures offres sans le stress des contrôles quotidiens.

Pourquoi automatiser la surveillance des prix ?

Automatiser la surveillance des prix, c’est comme avoir votre propre équipe de lutins du Père Noël travaillant 24 heures sur 24 pour vous assurer d’obtenir les meilleures offres sans lever le petit doigt. Voici pourquoi vous allez l’adorer :

Articles coûteux : Nous savons tous que les cadeaux de Noël peuvent coûter assez cher, surtout lorsque les gadgets et les jouets figurent sur votre liste. Économiser de l’argent sur ceux-ci peut être aussi satisfaisant que de trouver la dernière cime d’arbre en stock.
Contrôles quotidiens : Qui a le temps (ou la patience) de vérifier les prix chaque jour ? Pas moi !
Automatisation : Adoptez l’esprit de générosité des Fêtes : offrez-vous le cadeau de l’efficacité.
Précision : l’automatisation garantit que vos contrôles de prix sont aussi précis que le nez de Rudolph est brillant.

Technologies de base

Pour construire mon propre petit assistant du Père Noël, j’ai décidé d’utiliser plusieurs technologies clés :

Conteneurs

Les conteneurs sont comme l’emballage de Noël des logiciels. Ils regroupent vos applications avec tous leurs goodies (dépendances) pour que tout se déroule aussi bien qu’une promenade en traîneau dans la neige fraîche. Docker est notre référence pour créer ces conteneurs.

Blazeur

Blazor est un framework sympa pour créer des applications Web interactives à l’aide de .NET. C’est comme remplacer les chants de Noël génériques par votre propre playlist de vacances : sur mesure, efficace et tellement amusante.

Docker-Compose

Docker-Compose est le gestionnaire des opérations de notre pôle Nord. Cela nous aide à maintenir tous nos services, comme l’API et le front-end Blazor, fonctionnant ensemble en parfaite harmonie. Considérez-le comme le chef d’orchestre de notre symphonie des Fêtes.

Guide étape par étape

Maintenant, plongeons dans l’atelier du Père Noël et donnons vie à ce projet !

Étape 1 : Création de l’API

1.1 Mise en place du projet

Enfilez votre chapeau de Père Noël de codage et configurez un nouveau projet d’API Web ASP.NET Core. Ouvrez votre terminal (c’est un peu comme ouvrir votre calendrier de l’avent) et exécutez :

dotnet new webapi -o PriceMonitorApi
cd PriceMonitorApi

Cette commande crée un nouveau répertoire nommé PriceMonitorApi et configure un projet d’API Web de base. Imaginez que c’est comme créer une base solide pour votre maison en pain d’épice.

1.2 Ajout de HttpClient et de bibliothèques ScrapingEnsuite, ajoutez `HttpClient` et une bibliothèque pour analyser le HTML. Ce sera notre fidèle traîneau pour récupérer et lire les données sur les prix.

dotnet add package HtmlAgilityPack

HtmlAgilityPack est l’elfe qui nous aide à analyser les documents HTML.

1.3 Création de modèles

Les modèles sont comme le modèle de nos jouets. Créons un modèle pour représenter les informations sur le produit :

namespace PriceMonitorApi.Models
{
 public class ProductInfo
 {
 public string Title { get; set; }
 public decimal Price { get; set; }
 public DateTime Date { get; set; }
 }
}

Nous venons de créer le modèle parfait pour nos données.

1.4 Implémentation du service Scraper

Notre service Scraper est comme le petit assistant du Père Noël : il récupère et traite les informations pour nous :

using HtmlAgilityPack;
using PriceMonitorApi.Models;
using System.Globalization;

namespace PriceMonitorApi.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> ScrapeProductInfoAsync(string url)
 {
 var response = await _httpClient.GetStringAsync(url);

 var htmlDoc = new HtmlDocument();
 htmlDoc.LoadHtml(response);

 var title = htmlDoc.DocumentNode.SelectSingleNode("//h1[@class='product-title']").InnerText.Trim();
 var priceString = htmlDoc.DocumentNode.SelectSingleNode("//span[@class='product-price']").InnerText.Trim();

 if (decimal.TryParse(priceString, NumberStyles.Currency, CultureInfo.InvariantCulture, out var price))
 {
 return new ProductInfo
 {
 Title = title,
 Price = price,
 Date = DateTime.UtcNow
 };
 }

 throw new Exception("Unable to parse price");
 }
 }
}

Cet extrait transforme notre HtmlAgilityPack en une baguette magique pour les fêtes.

1.5 Création du contrôleur API

Créons un contrôleur qui agira comme le gardien de nos données :

using Microsoft.AspNetCore.Mvc;
using PriceMonitorApi.Models;
using PriceMonitorApi.Services;

namespace PriceMonitorApi.Controllers
{
 [ApiController]
 [Route("api/[controller]")]
 public class ScraperController : ControllerBase
 {
 private readonly ScraperService _scraperService;

 public ScraperController(ScraperService scraperService)
 {
 _scraperService = scraperService;
 }

 [HttpGet("productinfo")]
 public async Task<ActionResult<ProductInfo>> GetProductInfo(string url)
 {
 try
 {
 var productInfo = await _scraperService.ScrapeProductInfoAsync(url);
 return Ok(productInfo);
 }
 catch (Exception ex)
 {
 return BadRequest(new { Message = ex.Message });
 }
 }
 }
}

Notre contrôleur garantit que les données sont transmises plus rapidement que le Père Noël dans la cheminée.

1.6 Enregistrement des services dans le conteneur DI

Enfin, enregistrez votre ScraperService pour vous assurer qu’il est disponible en cas de besoin.

services.AddHttpClient<ScraperService>();

Votre API est désormais prête, comme le traîneau du Père Noël la veille de Noël !

Étape 2 : Création de l’application Blazor

Blazor nous aide à décorer notre projet comme un sapin de Noël, le rendant visuellement attrayant et interactif.

2.1 Mise en place du projet Blazor

Ensuite, nous créerons un projet Blazor qui servira d’interface pour notre promenade en traîneau de surveillance des prix.

dotnet new blazor -o PriceMonitorBlazor
cd PriceMonitorBlazor

Cette commande apporte un peu de magie des fêtes pour mettre en place un projet Blazor WebAssembly de base.

2.2 Ajout de modèles

Tout comme pour configurer des ornements, ajoutez un modèle ProductInfo dans le projet Blazor :

namespace PriceMonitorBlazor.Models
{
 public class ProductInfo
 {
 public string Title { get; set; }
 public decimal Price { get; set; }
 public DateTime Date { get; set; }
 }
}

2.3 Création du service pour les appels API

Créez un service pour récupérer les données de notre API. Considérez-le comme notre partenaire d’achat en ligne :

using PriceMonitorBlazor.Models;
using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;

namespace PriceMonitorBlazor.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> GetProductInfoAsync(string url)
 {
 var response = await _httpClient.GetFromJsonAsync<ProductInfo>($"https://localhost:5001/api/scraper/productinfo?url={url}");
 return response;
 }
 }
}

2.4 Enregistrement des services dans le conteneur DI

Assurez-vous que ScraperService est enregistré afin que nous puissions l’injecter dans nos composants.

builder.Services.AddScoped<ScraperService>();

2.5 Création du composant Blazor

Mettez à jour Pages/Index.razor pour inclure une interface amusante et interactive :

@page "/"
@using PriceMonitorBlazor.Models
@using PriceMonitorBlazor.Services
@inject ScraperService ScraperService

<h3>Price Monitor</h3>

<p>
 <label for="urlInput">Product URL:</label>
 <input id="urlInput" @bind="productUrl" />
 <button @onclick="FetchProductInfo">Fetch Price</button>
</p>

@if (productInfos.Any())
{
 <table class="table">
 <thead>
 <tr>
 <th>Title</th>
 <th>Price</th>
 <th>Date</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var product in productInfos)
 {
 <tr>
 <td>@product.Title</td>
 <td>@product.Price</td>
 <td>@product.Date</td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private string productUrl;
 private List<ProductInfo> productInfos = new List<ProductInfo>();

 private async Task FetchProductInfo()
 {
 if (!string.IsNullOrEmpty(productUrl))
 {
 var productInfo = await ScraperService.GetProductInfoAsync(productUrl);
 productInfos.Add(productInfo);
 }
 }
}

C’est comme organiser une exposition festive pour les fêtes, rendant notre application interactive et agréable.

Étape 3 : Tout connecter à l’aide de Docker-Compose

Connectons maintenant le tout à l’aide de Docker-Compose, transformant ainsi notre projet en une balade en traîneau bien huilée.

3.1 Création de fichiers Docker

Créez des Dockerfiles pour les projets API et Blazor :

PriceMonitorApi/Dockerfile :

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["PriceMonitorApi/PriceMonitorApi.csproj", "PriceMonitorApi/"]
RUN dotnet restore "PriceMonitorApi/PriceMonitorApi.csproj"
COPY . .
WORKDIR "/src/PriceMonitorApi"
RUN dotnet build "PriceMonitorApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "PriceMonitorApi.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "PriceMonitorApi.dll"]

PriceMonitorBlazor/Dockerfile :

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["PriceMonitorBlazor/PriceMonitorBlazor.csproj", "PriceMonitorBlazor/"]
RUN dotnet restore "PriceMonitorBlazor/PriceMonitorBlazor.csproj"
COPY . .
WORKDIR "/src/PriceMonitorBlazor"
RUN dotnet build "PriceMonitorBlazor.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "PriceMonitorBlazor.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "PriceMonitorBlazor.dll"]

3.2 Création de docker-compose.yml

Connectez tous les points (lumières de Noël) avec un seul fichier docker-compose.yml :

version: '3.4'

services:
 api:
 image: pricemonitorapi
 build:
 context: ./PriceMonitorApi
 dockerfile: Dockerfile
 ports:
 - "5000:80"
 networks:
 - price-monitor-network

 blazor:
 image: pricemonitorblazor
 build:
 context: ./PriceMonitorBlazor
 dockerfile: Dockerfile
 ports:
 - "5001:80"
 depends_on:
 - api
 networks:
 - price-monitor-network

networks:
 price-monitor-network:
 driver: bridge

Diagrammes

Vous trouverez ci-dessous les diagrammes pour nous aider à visualiser les différents composants et le flux de données, cela nous aidera à comprendre ce qui se passe réellement dans notre monde du Père Noël :

Schéma d’architecture du système

Diagramme de flux de données

Diagramme de séquence

Diagramme des composants pour la configuration de Docker

Étape 4 : Gestion des URL, actualisation et actualisation périodique automatiséeDans cette démo, nous allons simplement le stocker en mémoire, mais dans une application réelle, vous utiliseriez une base de données. Pour ce projet amusant, restons-en au stockage en mémoire.

4.1 Modification du service pour gérer les URL

Tout d’abord, nous veillerons à ce que notre service puisse gérer l’ajout et la récupération d’URL, ainsi que la récupération d’informations sur les produits :

Mettre à jour Services/ScraperService.cs :

using PriceMonitorBlazor.Models;
using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;

namespace PriceMonitorBlazor.Services
{
 public class ScraperService
 {
 private readonly HttpClient _httpClient;
 private List<string> urls = new List<string>();

 public ScraperService(HttpClient httpClient)
 {
 _httpClient = httpClient;
 }

 public async Task<ProductInfo> GetProductInfoAsync(string url)
 {
 var response = await _httpClient.GetFromJsonAsync<ProductInfo>($"http://localhost:5000/api/scraper/productinfo?url={url}");
 return response;
 }

 public void AddUrl(string url)
 {
 if (!urls.Contains(url))
 {
 urls.Add(url);
 }
 }

 public List<string> GetUrls()
 {
 return urls;
 }

 public void ClearUrls()
 {
 urls.Clear();
 }
 }
}

4.2 Mise à jour du composant Blazor pour la gestion et l’actualisation des URL

Ensuite, mettez à jour Pages/Index.razor pour ajouter la gestion des URL, l’actualisation et l’actualisation périodique automatisée :

@page "/"
@using PriceMonitorBlazor.Models
@using PriceMonitorBlazor.Services
@inject ScraperService ScraperService

<h3>Price Monitor</h3>

<p>
 <label for="urlInput">Product URL:</label>
 <input id="urlInput" @bind="productUrl" />
 <button @onclick="AddUrl">Add URL</button>
</p>

<p>
 <button @onclick="RefreshPrices">Refresh All Prices</button>
</p>

@if (productInfos.Any())
{
 <table class="table">
 <thead>
 <tr>
 <th>Title</th>
 <th>Price</th>
 <th>Date</th>
 </tr>
 </thead>
 <tbody>
 @foreach (var product in productInfos)
 {
 <tr>
 <td>@product.Title</td>
 <td>@product.Price</td>
 <td>@product.Date</td>
 </tr>
 }
 </tbody>
 </table>
}

@code {
 private string productUrl;
 private List<ProductInfo> productInfos = new List<ProductInfo>();
 private Timer _timer;

 protected override void OnInitialized()
 {
 StartTimer();
 }

 private void StartTimer()
 {
 // Set up the timer to call RefreshPrices every minute (60000 ms)
 _timer = new Timer(async _ => await InvokeAsync(RefreshPrices), null, TimeSpan.Zero, TimeSpan.FromMinutes(1));
 }

 private void AddUrl()
 {
 if (!string.IsNullOrEmpty(productUrl))
 {
 ScraperService.AddUrl(productUrl);
 productUrl = string.Empty;
 }
 }

 private async Task RefreshPrices()
 {
 productInfos.Clear();
 var urls = ScraperService.GetUrls();

 foreach (var url in urls)
 {
 var productInfo = await ScraperService.GetProductInfoAsync(url);
 productInfos.Add(productInfo);
 }
 StateHasChanged();
 }
}

Dans ce composant mis à jour :

Nous utilisons un Timer pour appeler périodiquement la méthode RefreshPrices toutes les minutes.
La méthode StartTimer initialise le timer pour qu’il démarre immédiatement puis se déclenche toutes les 60 secondes.
La méthode de cycle de vie OnInitialized appelle StartTimer lorsque le composant est initialisé pour démarrer l’actualisation périodique.

4.3 Exécuter la solution

Pour exécuter l’application Blazor mise à jour avec les nouvelles fonctionnalités, reconstruisez et redémarrez vos conteneurs Docker :

docker-compose build
docker-compose up

Après avoir chargé http://localhost:5001 dans votre navigateur, l’application Blazor devrait désormais actualiser automatiquement les prix des produits toutes les minutes en plus de permettre les actualisations manuelles et la gestion des URL.

Conclusion

Construire ce système de surveillance des prix a été une explosion de joie ! Non seulement cela m’a évité le stress des vérifications quotidiennes des prix, mais cela a également mis en valeur la magie des technologies Web modernes.

Calendrier Tech Festif 2024

J’ai créé cet article dans le cadre de l’événement Festive Tech Calendar 2024, qui rassemble des passionnés de technologie, des innovateurs et des rêveurs numériques pour partager leurs connaissances et célébrer la fusion de l’esprit festif et des merveilles technologiques. Cette initiative ne vise pas seulement à apprendre et à se connecter, mais aussi à redonner.

Festive Tech Calendar 2024 soutient cette année la Beatson Cancer Charity. La Beatson Cancer Charity se consacre à soutenir les personnes touchées par le cancer, leurs familles et les professionnels de la santé qui s’en occupent. Plus d’informations sur leur incroyable travail peuvent être trouvées sur https://www.beatsoncancercharity.org/.

Consultez le site Web du calendrier technique festif à l’adresse https://festivetechcalendar.com pour consulter les questions fréquemment posées et plus de détails sur l’événement.

HO HO HO!

Créer ce projet a été une merveilleuse façon de contribuer à la communauté technologique festive et de soutenir en même temps une grande cause.

J’espère que vous avez trouvé ce guide utile et qu’il vous incitera à explorer d’autres façons d’utiliser la technologie pour simplifier les tâches quotidiennes.

Si vous avez des questions ou avez besoin d’aide supplémentaire, n’hésitez pas à nous contacter.

Bon codage !

Validation personnalisée ValidationAttribute et Blazor

Fri, 29 Mar 2024 00:00:00 +0000

# Tout personnaliser

Comme vous l’avez probablement vu dans tous mes articles, j’essaie vraiment de garder tout aussi propre que possible, car j’ai déjà écrit des articles concernant les attributs personnalisés, la gestion des exceptions personnalisées, l’injection de collection de services, etc.

J’ai réalisé avec le temps que ce type de méthode de codage me donnait, à moi et à mon équipe, un moyen d’améliorer les heures supplémentaires, de trouver plus facilement les problèmes et de séparer le code autant que possible.

Ouais, après cette histoire sympa que je viens de vous raconter, j’ai travaillé sur Blazor ces derniers temps comme d’habitude et j’ai découvert qu’après des années et des années de développement, vous pouvez créer des attributs de validation personnalisés.

Ouais, c’est drôle, après toutes ces années…

Attributs de validation personnalisés

L’idée est venue du travail en fait, nous faisons toujours de la validation partout mais j’avais certains champs qui nécessitaient un peu le même processus de validation, alors j’ai pensé qu’il pourrait y avoir quelque chose là-bas… comme des attributs de validation personnalisés !

J’ai donc lancé la documentation Microsoft à ce sujet et découvert que oui, vous pouvez créer des attributs de validation personnalisés et les attribuer aux propriétés, comme ceci :

public class StringLengthRangeAttribute : ValidationAttribute
{
 public int Minimum { get; set; }
 public int Maximum { get; set; }

 public StringLengthRangeAttribute()
 {
 this.Minimum = 0;
 this.Maximum = int.MaxValue;
 }

 public override bool IsValid(object value)
 {
 string strValue = value as string;
 if (!string.IsNullOrEmpty(strValue))
 {
 int len = strValue.Length;
 return len >= this.Minimum && len <= this.Maximum;
 }
 return true;
 }
}

et utilisez-le dans une classe simple comme celle-ci :

[Required]
[StringLengthRange(Minimum = 10, ErrorMessage = "Must be >10 characters.")]

[StringLengthRange(Maximum = 20)]

[Required]
[StringLengthRange(Minimum = 10, Maximum = 20)]

Validateur personnalisé

J’ai donc ce validateur dont j’ai besoin pour une analyse de rentabilisation spécifique qui contiendra 20 premiers caractères qui comprendront 9 chiffres et un trait d’union, et se termineront par 2 caractères qui seront généralement le code du pays, donc quelque chose comme ceci : 123456789-123456789-ES

J’ai fini par arriver avec quelque chose comme ça, c’est vraiment simple mais ça marche :

using System;
using System.ComponentModel.DataAnnotations;
using System.Text.RegularExpressions;

public class SpecialStringValidatorAttribute : ValidationAttribute
{
 private const int TotalLength = 22;
 private const string Pattern = @"^(\d{10})-(\d{10})-([A-Za-z]{2})$";

 protected override ValidationResult IsValid(object value, ValidationContext validationContext)
 {
 string strValue = value as string;

 if (!string.IsNullOrEmpty(strValue))
 {
 if (strValue.Length != TotalLength)
 {
 return new ValidationResult($"The string must be {TotalLength} characters long.");
 }

 if (!Regex.IsMatch(strValue, Pattern))
 {
 return new ValidationResult("The string must follow the pattern: 1234567890-1234567890-AB");
 }

 return ValidationResult.Success;
 }

 return new ValidationResult("The string cannot be null or empty.");
 }
}

## Tests

J’ai aussi écrit un test pour eux, juste au cas où :

public class SpecialStringValidatorTests
{
 [Theory]
 [InlineData("1234567890-1234567890-AB", true)]
 [InlineData("1234567890-1234567890-XY", true)]
 [InlineData("1234567890-1234567890-A1", false)]
 [InlineData("1234567890-1234567890-A", false)]
 [InlineData("1234567890-123456789-AB", false)]
 [InlineData("1234567890-1234567890", false)]
 [InlineData("1234567890-1234567890-ABCDE", false)]
 public void SpecialStringValidatorTest(string input, bool expectedResult)
 {
 // Arrange
 var validator = new SpecialStringValidatorAttribute();

 // Act
 var result = validator.IsValid(input);

 // Assert
 Assert.Equal(expectedResult, result);
 }
}

Et une fois exécuté, j’ai eu ces résultats :

Microsoft (R) Test Execution Command Line Tool Version 16.9.1
Copyright (c) Microsoft Corporation. All rights reserved.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.

Test run in progress...

Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-AB", expectedResult: True)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-XY", expectedResult: True)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-A1", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-A", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-123456789-AB", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890", expectedResult: False)
Passed! - SpecialStringValidatorTests.SpecialStringValidatorTest(input: "1234567890-1234567890-ABCDE", expectedResult: False)

Test Run Successful.
Total tests: 7
 Passed: 7
 Total time: 1.7296 Seconds

Validation personnalisée et Blazor

Alors maintenant que je sais que le sien peut être utilisé, c’est clairement une bonne idée de l’implémenter dans Blazor, n’est-ce pas ?

Supposons que j’ai ce formulaire, qui utilisera le modèle Person que j’ai montré précédemment :

@using Models
@page "/"

<PageTitle>Home</PageTitle>

<h1>Hello, world!</h1>

<EditForm Model=@Person FormName="PersonForm">
 <DataAnnotationsValidator/>
 <ValidationSummary/>
 <div class="form-group">
 <label for="Name">Name</label>
 <InputText @bind-Value=Person.Name class="form-control" id="Name" />
 <ValidationMessage For="() => Person.Name"/>
 </div>
 <div class="form-group">
 <label for="MySpecialString">My special string</label>
 <InputText @bind-Value=Person.MySpecialString class="form-control" id="Name" />
 <ValidationMessage For="() => Person.MySpecialString"/>
 </div>
 <div class="form-group">
 <label for="Age">Age</label>
 <InputNumber @bind-Value=Person.Age class="form-control" id="Age" />
 <ValidationMessage For=@(() => Person.Age) />
 </div>
 <input type="submit" class="btn btn-primary" value="Save"/>
</EditForm>

@code {
 Person Person = new Person();
}

Dès que nous exécutons ceci, nous obtenons les erreurs suivantes :

Et si nous mettons juste ce que nous voulons, nous obtenons la chose suivante, tout à fait claire :

Pour être honnête pour moi, il est clair que nous devrions au moins déplacer la logique pour valider ces formulaires vers des attributs de validation personnalisés, cela nous donne la liberté de stocker le code de cette connexion en un seul endroit, et nous pouvons l’utiliser plus tard pour une API ou une autre application.

J’espère que cela vous a plu, si vous avez des questions ou si vous souhaitez nous contacter, n’hésitez pas et contactez-moi !

Gestion des exceptions personnalisées sur l'API .NET

Sun, 01 Oct 2023 00:00:00 +0000

Les exceptions sont mauvaises, nous le savons, n’est-ce pas ? Mais que se passe-t-il si nous devons les gérer ?

Que se passe-t-il lorsque nous avons une exception, par exemple sur une API, elle affiche un message de pile qui comprend de nombreuses informations que nous pourrions vouloir supprimer de la réponse que nos utilisateurs reçoivent.

Pour la démo, j’ai créé une API dotnet et ajouté une méthode qui lèvera une exception :

[HttpGet]
[Route("GetWithoutExceptionHandler")]
public Task GetWithoutExceptionHandler()
{
 throw new Exception("This is a custom exception!");
}

Si nous levons une exception, cela ressemble à ceci :

System.Exception: This is a custom exception!
 at CustomExceptionHandleDemo.Controllers.WeatherForecastController.GetWithoutExceptionHandler()
 at lambda_method16(Closure , Object , Object[] )
 at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
 at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
 at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
 at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
 at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Cela semble normal, c’est ce que vous obtenez d’une exception, mais pour moi, cela affiche beaucoup d’informations, si vous avez des bibliothèques et autres, cela pourrait montrer des informations sensibles concernant votre client, votre projet ou d’autres éléments à quelqu’un qui pourrait essayer de voir des choses.

Voici à quoi cela ressemble sur Swagger :

Création d’une exception personnalisée

Cette étape pourrait être évitée, puisque nous savons quelle exception sera levée, dans ce cas un Exception, mais pour moi, avoir vos exceptions personnalisées est le mieux puisque vous avez plus de contrôle sur ce que vous lancez.

Dans ce cas, je viens de créer un objet CustomException qui hérite de Exception :

namespace CustomExceptionHandleDemo.Exceptions
{
 public class CustomException : Exception
 {
 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 public CustomException() { }

 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 /// <param cref="string" name="message">Parameter for message</param>
 public CustomException(string message) : base(message) { }

 /// <summary>
 /// Constructor for <see cref="CustomException"/>
 /// </summary>
 /// <param cref="string" name="message">Parameter for message</param>
 /// <param cref="Exception" name="inner">Parameter for inner</param>
 public CustomException(string message, Exception inner) : base(message, inner) { }
 }
}

Après avoir créé notre exception personnalisée, mettons à jour notre méthode pour lancer CustomException au lieu de Exception :

[HttpGet]
[Route("GetWithoutExceptionHandler")]
public Task GetWithoutExceptionHandler()
{
 throw new CustomException("This is a custom exception!");
}

Pour l’instant, cela ne changera rien mais la trace de pile montrera que l’objet qui a été lancé est un CustomException au lieu de Exception, jetez un œil au début de la trace de pile :

CustomExceptionHandleDemo.Exceptions.CustomException: This is a custom exception!
 at CustomExceptionHandleDemo.Controllers.WeatherForecastController.GetWithoutExceptionHandler()
 at lambda_method24(Closure , Object , Object[] )
 at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
 at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
 at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
 at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
 at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
 at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Création d’un ExceptionFilterAttribute

Microsoft nous a donné un moyen de gérer les exceptions après leur émission, vous pouvez consulter plus d’informations ici.

Mais jusqu’à présent, la documentation qu’ils nous donnent est la suivante :

Un filtre abstrait qui s’exécute de manière asynchrone après qu’une action a levé une exception. Les sous-classes doivent remplacer OnException(ExceptionContext) ou OnExceptionAsync(ExceptionContext) mais pas les deux.

Alors créons-en un, nous allons créer CustomExceptionFilterAttribute dans lequel nous allons remplacer OnException :

using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.AspNetCore.Mvc;
using CustomExceptionHandleDemo.Exceptions;

namespace CustomExceptionHandleDemo.ExceptionFilterAttributes
{
 public class CustomExceptionFilterAttribute : ExceptionFilterAttribute
 {
 /// <summary>
 /// OnException
 /// </summary>
 /// <param cref="ExceptionContext" name="context">Parameter for context</param>
 public override void OnException(ExceptionContext context)
 {
 if (context.Exception is CustomException)
 {
 context.HttpContext.Response.StatusCode = 500;
 context.Result = new ObjectResult(context.Exception.Message);
 }
 }
 }
}

Comme vous pouvez le voir, nous examinons le ExceptionContext, lorsque l’exception est un type de CustomException, nous faisons quelque chose.

Ce quelque chose met à jour la réponse et le code d’état de ce que nous allons retourner.

Afin de mettre à jour le code d’état, nous devons mettre à jour context.HttpContext.Response.StatusCode et pour renvoyer le résultat, nous devons mettre à jour le context.Result en lui donnant un objet hérité de ActionResult.

Il s’agit d’un filtre, cela signifie donc que nous devons lui ajouter quelque chose en ajoutant [CustomExceptionFilter].

Utiliser le filtre

Maintenant, reproduisons la méthode que nous avons et ajoutons ce filtre pour qu’il agisse, notre point de terminaison d’API finira comme ceci :

using CustomExceptionHandleDemo.ExceptionFilterAttributes;
using CustomExceptionHandleDemo.Exceptions;
using Microsoft.AspNetCore.Mvc;

namespace CustomExceptionHandleDemo.Controllers
{
 [ApiController]
 [Route("[controller]")]
 public class WeatherForecastController : ControllerBase
 {
 public WeatherForecastController()
 {
 }

 [HttpGet]
 [Route("GetWithoutExceptionHandler")]
 public Task GetWithoutExceptionHandler()
 {
 throw new CustomException("This is a custom exception!");
 }

 [HttpGet]
 [Route("GetWithExceptionHandler")]
 [CustomExceptionFilter]
 public Task GetWithExceptionHandler()
 {
 throw new CustomException("This is a custom exception!");
 }
 }
}

Comme vous pouvez le voir, nous avons une nouvelle méthode appelée GetWithExceptionHandler, qui a la même logique que GetWithoutExceptionHandler, mais dans ce cas, nous avons ajouté le filtre [CustomExceptionFilter] à la méthode.

Le résultat est le suivant après avoir exécuté la méthode, j’afficherai une image, car elle n’affiche plus la trace de la pile :

Nous avons donc créé une exception personnalisée, un filtre pour remplacer ce qui se passe lorsque nous lançons une exception et l’utilisons sur une méthode.

Cela peut être utilisé pour beaucoup de choses comme la journalisation et savoir quoi, quand et où l’erreur se produit.

Une façon plus agréable d'injecter des trucs

Mon, 04 Sep 2023 00:00:00 +0000

Chaque fois que je crée des éléments tels que des services, des référentiels, des attributs ou quoi que ce soit à injecter dans mes applications, nous devons effectuer cette étape, qui consiste en fait à ajouter les services à l’application.

C’est toujours la même chose, vous allez dans Program.cs, puis procédez à une partie du fichier en ajoutant builder.Services.AddScoped<MyService>(); afin d’injecter le service.

Quelque chose comme ça :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

// Repositories
builder.Services.AddScoped<ARepository>(); // 👀
builder.Services.AddScoped<BRepository>(); // 👀

// Services
builder.Services.AddScoped<AService>(); // 👀
builder.Services.AddScoped<BService>(); // 👀
builder.Services.AddScoped<CService>(); // 👀
builder.Services.AddScoped<DService>(); // 👀

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Je veux dire, ça marche, mais je suis difficile et je n’aime pas vraiment ça.

Disons que nous voulons faire plusieurs injections de dépendances, et ce ne sont pas vraiment les mêmes choses, dans mon cas, cela pourrait être quelque chose comme avoir une bibliothèque qui contient tous les référentiels, une autre bibliothèque qui a tous les services et enfin, une autre bibliothèque qui contient des attributs.

Dans ce cas, pouvez-vous imaginer le nombre de lignes que nous devons ajouter à Program.cs.

Disons que nous avons une bibliothèque qui contient certains services, si nous voulons inclure tous nos services, nous devons travailler avec IServiceCollection.

Nous allons donc créer un static class qui aura une méthode static appelée AddServices qui renvoie un IServiceCollection.

Dans ce cas, il sera nommé IServiceCollectionServicesExtensions.

/// <summary>
/// IServiceCollectionServicesExtensions class
/// </summary>
public static class IServiceCollectionServicesExtensions
{
 /// <summary>
 /// AddCoreServices
 /// </summary>
 /// <param cref="IServiceCollection" name="services">Parameter for <see cref="IServiceCollection"/></param>
 /// <returns>An object of type <see cref="IServiceCollection"/></returns>
 public static IServiceCollection AddServices(this IServiceCollection services)
 {
 services
 .AddScoped<AService>()
 .AddScoped<BService>()
 .AddScoped<CService>()
 .AddScoped<DService>();

 return services;
 }
}

Non seulement cela, nous avons également une autre bibliothèque qui inclut certains référentiels utilisés par ces services, alors faisons de même.

/// <summary>
/// IServiceCollectionServicesExtensions class
/// </summary>
public static class IServiceCollectionServicesExtensions
{
 /// <summary>
 /// AddCoreServices
 /// </summary>
 /// <param cref="IServiceCollection" name="services">Parameter for <see cref="IServiceCollection"/></param>
 /// <returns>An object of type <see cref="IServiceCollection"/></returns>
 public static IServiceCollection AddRepositories(this IServiceCollection services)
 {
 services
 .AddScoped<ARepository>()
 .AddScoped<BRepository>();

 return services;
 }
}

Maintenant, nous avons créé nos référentiels et nos méthodes de services à injecter, mais comment les utiliser ?

Revenons à notre Program.cs et ajoutons ce qui suit :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

// Repositories
builder.Services.AddRepositories(); // 👀

// Services
builder.Services.AddServices(); // 👀

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Cela a l’air bien plus propre, n’est-ce pas ? Eh bien, avec cela, nous avons injecté avec succès certains services et référentiels, mais maintenant cela semble plus joli et nous avons réellement ce que nous injectons dans la bibliothèque externe.

Injection de dépendances avec attributs sur l'API .NET

Tue, 22 Aug 2023 00:00:00 +0000

L’injection de dépendances est probablement l’une des meilleures fonctionnalités dont nous disposons actuellement sur .NET. Il est impossible que vous ne l’utilisiez pas, donc si vous êtes comme moi, vous voulez vraiment l’ajouter à toutes les implémentations que vous effectuez.

Filtres, selon la [documentation](https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.1 officielle de Microsoft :

Les filtres dans ASP.NET Core permettent d’exécuter du code avant ou après des étapes spécifiques du pipeline de traitement des requêtes.

Les filtres intégrés gèrent des tâches telles que :

Autorisation, empêchant l’accès aux ressources pour lesquelles un utilisateur n’est pas autorisé.

Mise en cache des réponses, court-circuitant le pipeline de requêtes pour renvoyer une réponse mise en cache.

Des filtres personnalisés peuvent être créés pour traiter les préoccupations transversales. Des exemples de problèmes transversaux incluent la gestion des erreurs, la mise en cache, la configuration, l’autorisation et la journalisation. Les filtres évitent la duplication de code.

Je travaille beaucoup avec des API et il y a des éléments qui doivent exécuter chaque requête, ou presque toutes, donc idéalement, ce que nous voulons faire, c’est travailler avec cela plus… l’injection de dépendances !

Mais c’est parfois un peu compliqué, cela ne fonctionne pas comme nous le souhaitons si nous voulons hériter de ActionAttribute donc nous devons travailler avec TypeFilterAttribute, qui nous permet de faire des choses lors du remplacement de OnActionExecutionAsync.

Je crée habituellement ces filtres pour effectuer de la journalisation, nous allons donc l’utiliser comme exemple :

/// <summary>
/// LoggedQueryAttribute class
/// </summary>
public class LoggedQueryTypeFilterAttribute : TypeFilterAttribute
{
 /// <summary>
 /// Constructor for <see cref="LoggedQueryTypeFilterAttribute"/>
 /// </summary>
 public LoggedQueryTypeFilterAttribute() : base(typeof(LoggedQueryFilter))
 {
 }

 /// <summary>
 /// LoggedQueryFilter class
 /// </summary>
 private class LoggedQueryFilter : IAsyncActionFilter
 {
 /// <summary>
 /// <see cref="_loggingService"/> object
 /// </summary>
 private readonly LoggingService _loggingService;

 /// <summary>
 /// Constructor for <see cref="LoggedQueryFilter"/>
 /// </summary>
 /// <param cref="LoggingService" name="loggingService">Parameter for loggingService</param>
 public LoggedQueryFilter(LoggingService loggingService)
 {
 _loggingService = loggingService;
 }

 /// <summary>
 /// OnActionExecutionAsync
 /// </summary>
 /// <param cref="ActionExecutingContext" name="context">Parameter for context</param>
 /// <param cref="ActionExecutionDelegate" name="next">Parameter for next</param>
 public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
 {
 // Get properties
 var properties = (Request)context.ActionArguments.First().Value!;

 // Get call from context
 var call = context.HttpContext.Request.Path.Value!;

 // Logging
 _loggingService.LogCustomEvent(call);

 // Continue call
 await next();
 }
 }
}

La logique est assez simple, nous obtenons le corps en accédant à l’objet context avec context.ActionArguments.First().Value, nous obtenons également l’appel de méthode avec context.HttpContext.Request.Path.Value.

Ensuite, nous appelons simplement notre méthode depuis notre service, dans ce cas est _loggingService.LogCustomEvent(call).

Ensuite, il faut appeler await next();, car le pipeline doit continuer.

C’est pour l’attribut, maintenant, nous devons effectivement inclure cet attribut dans une méthode.

[LoggedQueryTypeFilterAttribute]
public ActionResult<string> TestFilter()
{
 return Ok("Hello world!");
}

J’espère que cela vous a plu, si vous avez des questions ou si vous souhaitez nous contacter, n’hésitez pas et contactez-moi !

Documentation Swagger avec des bibliothèques externes

Fri, 17 Feb 2023 00:00:00 +0000

Utiliser plusieurs bibliothèques pour diviser votre code pour des cas futurs est une bonne chose. Personnellement, j’adore le faire, si je peux diviser ma logique pour qu’elle puisse être réutilisée dans d’autres projets ou parties de projets.

Pour moi au moins, il est indispensable de diviser les modèles de données, qui incluent le Entity Framework, afin qu’il puisse être référencé et utilisé dans un Console application, un Blazor application ou un API.

Jetons un coup d’œil à un exemple de la façon dont je fais les choses, il s’agit d’une capture d’écran d’un projet comportant quelques applications et une bibliothèque partagée contenant tous les modèles.

Ceci est un exemple de classe que j’ai déplacée du projet API avec une documentation avec summary sur chaque propriété et classe.

namespace CustomLibrariesDocumentation.Models
{
 /// <summary>
 /// WeatherForecast class
 /// </summary>
 public class WeatherForecast
 {
 /// <summary>
 /// Gets or sets the Date
 /// </summary>
 public DateOnly Date { get; set; }

 /// <summary>
 /// Gets or sets the TemperatureC
 /// </summary>
 public int TemperatureC { get; set; }

 /// <summary>
 /// Gets or sets the TemperatureF
 /// </summary>
 public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

 /// <summary>
 /// Gets or sets the Summary
 /// </summary>
 public string? Summary { get; set; }
 }
}

Si nous le référençons au Console application et que nous commençons à utiliser le modèle, nous pouvons voir la documentation, c’est une fonctionnalité standard dans Visual Studio donc cela fonctionne bien, comme vous pouvez le voir ici :

Mais ensuite, si nous le référençons au API et que nous passons à Swagger, il n’y a pas de documentation récapitulative.

Comment pouvons-nous résoudre ce problème ?

Tout d’abord, nous devons activer les commentaires XML sur la bibliothèque, pour ce faire, vous devez mettre à jour les paramètres du projet et activer `` :

Cela générera des fichiers sur le dossier de construction qui se terminent par l’extension de fichier xml, comme vous pouvez le voir ici :

Maintenant que nous avons fait cela, nous devons ajouter quelques éléments sur le Program.cs, afin de pouvoir lire ces fichiers, car par défaut, il ne charge que la définition XML du projet sur lequel il se trouve.

Il utilise une méthode que nous avons à l’intérieur du AddSwaggerGen et qui s’appelle IncludeXmlComments.

L’idée est que si nous avons tous les fichiers xml, nous allons forcer leur chargement sur le Swagger.

builder.Services.AddSwaggerGen(s =>
{
 // Comments
 var allXmlFiles = Directory.GetFiles(AppContext.BaseDirectory, "*.xml");

 foreach (string xmlFiles in allXmlFiles)
 {
 s.IncludeXmlComments(xmlFiles);
 }
});

C’est simple, nous récupérons les fichiers xml du répertoire de construction et les ajoutons avec la méthode IncludeXmlComments .

Maintenant, nous chargeons à nouveau le API et nous vérifions si nous pouvons voir la documentation.

Et vous voyez qu’on peut voir la documentation !

J’espère que cela vous a aidé, si vous avez des questions, n’hésitez pas à me contacter !

Nettoyer les branches locales dans Git

Mon, 30 Jan 2023 00:00:00 +0000

Êtes-vous déjà arrivé à un point où vous aviez trop de succursales locales ? Cela m’arrive souvent, puisque nous utilisons des branches pour chaque fonctionnalité, bug ou tâche.

Je me retrouve avec quelque chose comme ça et ça devient super sale au bout d’un moment

Cela m’énerve vraiment, alors je vais juste partager une commande rapide que vous pouvez exécuter sur votre console pour effectuer ce nettoyage !

J’ai trouvé cette commande dans Stack Overflow dans la réponse suivante par Robert Corvus, qui est une version qui s’exécute sur Powerhsell.

Veuillez être prudent lorsque vous exécutez cette commande car vous risquez de perdre vos modifications

Avant de l’exécuter, n’oubliez pas de mettre à jour le MY_MASTER_BRANCH_NAME vers votre branche principale, qui peut être master comme j’utilise ou les nouveaux qui viennent par défaut appelés main.

git branch | %{ $_.Trim() } | ?{ $_ -ne 'MY_MASTER_BRANCH_NAME' } | %{ git branch -D $_ }

Après avoir exécuté cette commande, vous obtiendrez une sortie comme celle-ci

J’espère que cela vous sera utile !

Mise à jour des routes d'Identity dans ASP.NET Core 7

Mon, 23 Jan 2023 00:00:00 +0000

Vous vous demandez même comment Microsoft nomme des choses si rares ? J’ai toujours pensé qu’ils ne le faisaient pas vraiment très bien, mais bon, c’est ce que c’est !

La bonne chose à ce sujet est que vous pouvez pratiquement tout changer pendant que vous développez !

Êtes-vous déjà entré dans une page et réalisez-vous instantanément qu’il s’agit d’un projet Web ASP.NET simplement en effectuant le processus d’inscription ou de connexion ?

Cela m’est souvent arrivé car par défaut dans le projet que vous créez, vous avez ces URL pour effectuer le processus de connexion et d’enregistrement (vous avez également beaucoup d’autres pages).

Ce tutoriel montre donc un moyen de mettre à jour ces URL pour que votre projet soit plus joli !!

Comportement par défaut

Lorsque nous créons un projet Blazor et que nous décidons de l’utiliser avec Identity, il affiche quelque chose comme ceci :

Et lorsque nous essayons d’effectuer le processus de connexion ou d’enregistrement, nous allons soit /Identity/Account/Login ou /Identity/Account/Register.

Mais que se passe-t-il si je vous dis que vous pouvez réellement mettre à jour ces URL pour qu’elles soient différentes ?

Échafaudage des pages `Login` et `Register`

Afin de mettre à jour ces pages, Microsoft les masque, mais vous pouvez les échafauder rapidement et effectuer les modifications que vous souhaitez !

Pour ce faire, vous devez aller sur Add Scaffolded Item dans le menu contextuel du projet, comme ceci :

Ensuite, un modal apparaîtra et vous devrez sélectionner Identity deux fois et cliquer sur Add :

Après celui-ci, un autre modal apparaîtra, dans lequel vous pourrez sélectionner les pages de l’ensemble de l’identité que vous souhaitez mettre à jour. Il y a beaucoup de pages que vous pouvez mettre à jour, mais nous allons nous concentrer sur Account/Login et Account/Register :

Maintenant, laissez-le fonctionner un peu, puis vérifiez l’Explorateur de solutions, vous trouverez quelques nouveaux fichiers :

Ces nouveaux fichiers constituent la page de connexion et d’enregistrement qu’ASP.NET ajoute à votre projet lorsque vous le sélectionnez pour ajouter une identité !

Mise à jour des URL

Comme vous l’avez probablement remarqué, ces fichiers sont des fichiers rasoir, puisque leur extension est cshtml, nous allons donc simplement utiliser une directive pour mettre à jour l’url de la page :

@page "/login"
@model LoginModel

@{
 ViewData["Title"] = "Log in";
}

<h1>@ViewData["Title"]</h1>
<div class="row">
 <div class="col-md-4">
 <section>
 <form id="account" method="post">
 <h2>Use a local account to log in.</h2>
 <hr />
 <div asp-validation-summary="ModelOnly" class="text-danger" role="alert"></div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Email" class="form-control" autocomplete="username" aria-required="true" placeholder="name@example.com" />
 <label asp-for="Input.Email" class="form-label">Email</label>
 <span asp-validation-for="Input.Email" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Password" class="form-control" autocomplete="current-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.Password" class="form-label">Password</label>
 <span asp-validation-for="Input.Password" class="text-danger"></span>
 </div>
 <div class="checkbox mb-3">
 <label asp-for="Input.RememberMe" class="form-label">
 <input class="form-check-input" asp-for="Input.RememberMe" />
 @Html.DisplayNameFor(m => m.Input.RememberMe)
 </label>
 </div>
 <div>
 <button id="login-submit" type="submit" class="w-100 btn btn-lg btn-primary">Log in</button>
 </div>
 <div>
 <p>
 <a id="forgot-password" asp-page="./ForgotPassword">Forgot your password?</a>
 </p>
 <p>
 <a asp-page="./Register" asp-route-returnUrl="@Model.ReturnUrl">Register as a new user</a>
 </p>
 <p>
 <a id="resend-confirmation" asp-page="./ResendEmailConfirmation">Resend email confirmation</a>
 </p>
 </div>
 </form>
 </section>
 </div>
 <div class="col-md-6 col-md-offset-2">
 <section>
 <h3>Use another service to log in.</h3>
 <hr />
 @{
 if ((Model.ExternalLogins?.Count ?? 0) == 0)
 {
 <div>
 <p>
 There are no external authentication services configured. See this <a href="https://go.microsoft.com/fwlink/?LinkID=532715">article
 about setting up this ASP.NET application to support logging in via external services</a>.
 </p>
 </div>
 }
 else
 {
 <form id="external-account" asp-page="./ExternalLogin" asp-route-returnUrl="@Model.ReturnUrl" method="post" class="form-horizontal">
 <div>
 <p>
 @foreach (var provider in Model.ExternalLogins!)
 {
 <button type="submit" class="btn btn-primary" name="provider" value="@provider.Name" title="Log in using your @provider.DisplayName account">@provider.DisplayName</button>
 }
 </p>
 </div>
 </form>
 }
 }
 </section>
 </div>
</div>

@section Scripts {
 <partial name="_ValidationScriptsPartial" />
}

Comme vous pouvez le constater, la plupart des éléments sont les mêmes, mais si vous jetez un œil à la toute première ligne de la classe, j’ai mis à jour ce que nous avions auparavant :

@page

@page "/login"

Eh bien, c’était facile, n’est-ce pas ? Faisons maintenant un test rapide pour voir si cela fonctionne.

Tout d’abord, allons à la page par défaut que nous avons au début, pour vérifier si elle fonctionne toujours :

Ce qui n’est pas le cas ! Alors maintenant, allons tester notre nouvelle url qui est /login :

Et ça marche !!

Faisons maintenant de même pour le registre, mettons à jour sa page et ajoutons le chemin que nous voulons dans la directive @page et faisons un test !

@page "/register"
@model RegisterModel
@{
 ViewData["Title"] = "Register";
}

<h1>@ViewData["Title"]</h1>

<div class="row">
 <div class="col-md-4">
 <form id="registerForm" asp-route-returnUrl="@Model.ReturnUrl" method="post">
 <h2>Create a new account.</h2>
 <hr />
 <div asp-validation-summary="ModelOnly" class="text-danger" role="alert"></div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Email" class="form-control" autocomplete="username" aria-required="true" placeholder="name@example.com" />
 <label asp-for="Input.Email">Email</label>
 <span asp-validation-for="Input.Email" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.Password" class="form-control" autocomplete="new-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.Password">Password</label>
 <span asp-validation-for="Input.Password" class="text-danger"></span>
 </div>
 <div class="form-floating mb-3">
 <input asp-for="Input.ConfirmPassword" class="form-control" autocomplete="new-password" aria-required="true" placeholder="password" />
 <label asp-for="Input.ConfirmPassword">Confirm Password</label>
 <span asp-validation-for="Input.ConfirmPassword" class="text-danger"></span>
 </div>
 <button id="registerSubmit" type="submit" class="w-100 btn btn-lg btn-primary">Register</button>
 </form>
 </div>
 <div class="col-md-6 col-md-offset-2">
 <section>
 <h3>Use another service to register.</h3>
 <hr />
 @{
 if ((Model.ExternalLogins?.Count ?? 0) == 0)
 {
 <div>
 <p>
 There are no external authentication services configured. See this <a href="https://go.microsoft.com/fwlink/?LinkID=532715">article
 about setting up this ASP.NET application to support logging in via external services</a>.
 </p>
 </div>
 }
 else
 {
 <form id="external-account" asp-page="./ExternalLogin" asp-route-returnUrl="@Model.ReturnUrl" method="post" class="form-horizontal">
 <div>
 <p>
 @foreach (var provider in Model.ExternalLogins!)
 {
 <button type="submit" class="btn btn-primary" name="provider" value="@provider.Name" title="Log in using your @provider.DisplayName account">@provider.DisplayName</button>
 }
 </p>
 </div>
 </form>
 }
 }
 </section>
 </div>
</div>

@section Scripts {
 <partial name="_ValidationScriptsPartial" />
}

J’ai mis à jour la partie supérieure avec @page "/login" et maintenant nous testons si cela fonctionne :

Fonctionne aussi !!

C’est toutJ’espère que vous avez appris comment mettre à jour ces URL, principalement parce que sur certains projets, lorsque vous créez les URL d’une certaine manière et que l’identité semble différente, c’est nul haha !

Si vous avez besoin de quelque chose, tweetez-moi ou envoyez-moi un e-mail et j’essaierai de vous donner un coup de main !

Attributs personnalisés sur l'API .NET 6 Core

Fri, 09 Dec 2022 00:00:00 +0000

Les attributs personnalisés sont vraiment une bonne chose à utiliser, j’ai commencé à les utiliser très récemment, car ils me permettent d’en créer un seul et de les réutiliser soit sur le contrôleur, soit sur la classe, soit sur la méthode elle-même.

Ils sont vraiment utiles lorsque vous souhaitez effectuer des tâches de sécurité, comme vérifier les en-têtes ou vérifier la valeur d’un paramètre dont vous avez absolument besoin.

Dans mon cas, nous allons l’utiliser sur un projet API .NET Core, où nous allons vérifier si toutes les requêtes contiennent un certain en-tête.

# En-têteCheckAttribute

Donc, après avoir créé notre superbe API .NET Core, créons un dossier pour stocker nos données, car nous aimons utiliser des dossiers.

Et puis nous allons ajouter la logique à notre classe HeaderCheckAttribute .

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;

namespace DotNet6CustomAttribute.Attributes
{
 public class HeaderCheckAttribute : ActionFilterAttribute
 {
 public override void OnActionExecuting(ActionExecutingContext context)
 {
 // Get all headers
 var headers = context.HttpContext.Request.Headers;

 // Check if headers has x-dotnet-6-custom-attribute
 if (!headers.ContainsKey("x-dotnet-6-custom-attribute"))
 {
 context.Result = new BadRequestObjectResult("The header x-dotnet-6-custom-attribute is missing");
 }
 else if (string.IsNullOrEmpty(headers["x-dotnet-6-custom-attribute"]))
 {
 context.Result = new BadRequestObjectResult("The header x-dotnet-6-custom-attribute can't be null or empty");
 }

 base.OnActionExecuting(context);
 }
 }
}

Fondamentalement, la logique est la suivante : il vérifie d’abord un en-tête avec la clé x-dotnet-6-custom-attribute et s’il est là, il vérifie s’il a des valeurs.

Si ces deux expressions sont vraies, cela renverra un BadRequestObjectResult avec un certain message.

L’ajouter au contrôleur

Nous pouvons ajouter cette logique à plusieurs endroits, nous pouvons l’ajouter directement à l’ensemble du contrôleur, ou nous pouvons l’ajouter à certaines méthodes, nous allons l’ajouter d’abord aux méthodes puis à l’ensemble du contrôleur.

Alors décorons la classe WeatherForecastController avec eux.

using DotNet6CustomAttribute.Attributes;
using Microsoft.AspNetCore.Mvc;

namespace DotNet6CustomAttribute.Controllers
{
 [ApiController]
 [Route("[controller]")]
 public class WeatherForecastController : ControllerBase
 {
 private static readonly string[] Summaries = new[]
 {
 "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
 };

 private readonly ILogger<WeatherForecastController> _logger;

 public WeatherForecastController(ILogger<WeatherForecastController> logger)
 {
 _logger = logger;
 }

 [HttpGet]
 [Route("GetWeatherForecastWithCheck")]
 [HeaderCheckAttribute]
 public IEnumerable<WeatherForecast> GetWithCheck()
 {
 return Enumerable.Range(1, 5).Select(index => new WeatherForecast
 {
 Date = DateTime.Now.AddDays(index),
 TemperatureC = Random.Shared.Next(-20, 55),
 Summary = Summaries[Random.Shared.Next(Summaries.Length)]
 })
 .ToArray();
 }

 [HttpGet]
 [Route("GetWeatherForecastWithoutCheck")]
 public IEnumerable<WeatherForecast> GetWithoutCheck()
 {
 return Enumerable.Range(1, 5).Select(index => new WeatherForecast
 {
 Date = DateTime.Now.AddDays(index),
 TemperatureC = Random.Shared.Next(-20, 55),
 Summary = Summaries[Random.Shared.Next(Summaries.Length)]
 })
 .ToArray();
 }
 }
}

Lançons le projet !

Nous avons 2 fonctions là-dedans : GetWeatherForecastWithCheck et GetWeatherForecastWithoutCheck, l’une d’elles échouera et l’autre non, mais vérifions cela sur Swagger !

Comme vous pouvez le voir, l’un des renvoie une erreur 400 avec notre message et l’autre renvoie les valeurs. Maintenant, pour tester complètement cela, exécutons Postman et ajoutons un en-tête afin que nous puissions également voir les données en utilisant GetWeatherForecastWithCheck.

Facteur

Maintenant exécuté sur Postman, nous ajoutons l’en-tête et nous voyons que le message d’erreur a changé, puisque maintenant nous fournissons l’en-tête mais il n’a aucune valeur

Si on y ajoute une valeur, on obtient enfin les valeurs !

C’est ça

Et bien c’est tout ! Assez simple, non ? Eh bien, vous savez maintenant comment créer un attribut et l’attribuer aux méthodes et aux contrôleurs !

Amusez-vous avec eux !

#Code

L’intégralité de ce projet est sur Github et vous pouvez le trouver ici !

Si vous avez des problèmes ou des questions, n’hésitez pas à me contacter sur n’importe quel réseau social à @emimontesdeoca (sur Twitter, c’est en fait @emimontesdeocaa avec deux aa à la fin). Vous pouvez également retrouver la plupart de mes réseaux sociaux sur l’en-tête du blog.

J’espère que vous avez aimé le message ! Ouais !

Gérer le chargement des composants dans Blazor

Tue, 19 Jul 2022 00:00:00 +0000

Blazor est génial, vraiment génial, surtout lorsque nous faisons des choses asynchrones comme charger des boîtes et ça a l’air bien.

J’ai essayé de plusieurs manières de gérer le chargement des pages, des états, des composants, etc. Et je pense avoir enfin trouvé le moyen idéal de le faire comme je le souhaite.

Idée

Au lieu de réécrire la logique de chargement sur chaque page ou composant, nous construisons le composant parent avec un ChildComponent, cela nous donnera la possibilité de simplement le réutiliser plusieurs fois.

Code du composant de chargement

Le code est assez simple cependant, il n’y a pas grand chose à faire, un if basique avec une propriété de chargement, une fonction bascule à l’intérieur et c’est fait !

@if (_loaded)
{
 <div class="text-center">
 <div class="spinner-border" role="status">
 <span class="sr-only"></span>
 </div>
 </div>
}
else
{
 @ChildContent
}

@code {
 private bool _loaded = true;

 [Parameter]
 public RenderFragment? ChildContent { get; set; }

 public void ToggleLoad(bool state)
 {
 _loaded = state;
 }
}

Utilisation

L’utilisation est assez simple, pour des raisons de test, nous allons utiliser une nouvelle page et nous plaçons notre contenu dans le composant LoadingComponent créé que nous venons de créer.

@page "/loading"
@using LoadingBoxes.Components

<LoadingBoxes.Components.LoadingComponent @ref=loadingComponent>
 This is some content
</LoadingBoxes.Components.LoadingComponent>

@code {
 private LoadingComponent loadingComponent;


 protected override async Task OnInitializedAsync()
 {
 // We are going to simulate some load
 await Task.Delay(5000);

 loadingComponent.ToggleLoad(false);
 }

}

Voilà à quoi ça ressemble

Un exemple plus amusant

Disons que nous avons plusieurs composants dont chacun a son temps de chargement, nous pouvons construire quelque chose qui a l’air bien dessus !

Créons un faux composant de chargement que nous pouvons réutiliser appelé FakeLoadingComponent.

@using LoadingBoxes.Components

<LoadingBoxes.Components.LoadingComponent @ref=loadingComponent>
 It took @ellapsedTime seconds!
</LoadingBoxes.Components.LoadingComponent>

@code {
 private LoadingComponent loadingComponent = new();
 private int ellapsedTime = 0;
 private Random rnd = new();

 protected override async Task OnInitializedAsync()
 {
 var random = rnd.Next(0, 5000);

 // We are going to simulate some load
 await Task.Delay(random);

 ellapsedTime = random/ 1000;

 loadingComponent.ToggleLoad(false);
 StateHasChanged();
 }
}

Ensuite, nous mettons simplement à jour la page Loading avec plusieurs composants FakeLoadingComponent et vérifions le résultat !!

@page "/loading"
@using LoadingBoxes.Components

<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>
<FakeLoadingComponent/>

Maintenant, ça a l’air bien mieux

Et c’est tout !

J’espère que vous avez aimé le message !

Obtenir la date d'expiration d'un certificat

Fri, 27 May 2022 00:00:00 +0000

Il existe quelques applications Web qui vous aident à vérifier l’état actuel des certificats des domaines que nous utilisons, et nous en avons quelques-unes.

J’ai créé une fonction Azure qui s’exécute une fois par jour et vérifie quelques-uns des domaines dont je dois jeter un œil, c’est une application console super simple qui si la date d’expiration du certificat est inférieure à 30 jours, elle enverra un e-mail.

La logique elle-même du fonctionnement de la fonction ne sera pas affichée, j’aimerais montrer la fonction qui effectue la vérification de base du certificat et les données que nous obtenons.

La fonction

static async Task<X509Certificate2> CheckCertificateAsync(string urlPath)
{
 var certificate = new X509Certificate2();
 var httpClientHandler = new HttpClientHandler
 {
 ServerCertificateCustomValidationCallback = (request, cert, chain, policyErrors) =>
 {
 certificate = new X509Certificate2(cert);
 return true;
 }
 };

 using HttpClient httpClient = new HttpClient(httpClientHandler);
 await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Head, urlPath));

 return certificate;
}

Cette méthode CheckCertificateAsync nous renverra un certificat X509Certificate2 qui nous permettra de faire un tas de choses, notamment de jeter un œil à la date d’expiration.

Résultat sérialisé

Il s’agit de la valeur sérialisée de l’objet certificate :

{
 "Archived":false,
 "Extensions":[
 {
 "KeyUsages":160,
 "Critical":true,
 "Oid":{
 "Value":"2.5.29.15",
 "FriendlyName":"Key Usage"
 },
 "RawData":"AwIFoA=="
 },
 {
 "EnhancedKeyUsages":[
 {
 "Value":"1.3.6.1.5.5.7.3.1",
 "FriendlyName":"Server Authentication"
 },
 {
 "Value":"1.3.6.1.5.5.7.3.2",
 "FriendlyName":"Client Authentication"
 }
 ],
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.37",
 "FriendlyName":"Enhanced Key Usage"
 },
 "RawData":"MBQGCCsGAQUFBwMBBggrBgEFBQcDAg=="
 },
 {
 "CertificateAuthority":false,
 "HasPathLengthConstraint":false,
 "PathLengthConstraint":0,
 "Critical":true,
 "Oid":{
 "Value":"2.5.29.19",
 "FriendlyName":"Basic Constraints"
 },
 "RawData":"MAA="
 },
 {
 "SubjectKeyIdentifier":"634E1585565AA49402C21642A4A5979A38025797",
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.14",
 "FriendlyName":"Subject Key Identifier"
 },
 "RawData":"BBRjThWFVlqklALCFkKkpZeaOAJXlw=="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.35",
 "FriendlyName":"Authority Key Identifier"
 },
 "RawData":"MBaAFBQusxe3WFbLrlAJQOYfr52LFMLG"
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"1.3.6.1.5.5.7.1.1",
 "FriendlyName":"Authority Information Access"
 },
 "RawData":"MEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLw=="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.17",
 "FriendlyName":"Subject Alternative Name"
 },
 "RawData":"MB6CHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20="
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"2.5.29.32",
 "FriendlyName":"Certificate Policies"
 },
 "RawData":"MEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3Jn"
 },
 {
 "Critical":false,
 "Oid":{
 "Value":"1.3.6.1.4.1.11129.2.4.2",
 "FriendlyName":"SCT List"
 },
 "RawData":"BIH0APIAdwBByMqx3yJGShDGoToJQodeTjGLGwPr60vHaPCQYpYG9gAAAYCeJIwYAAAEAwBIMEYCIQCG8sf4iBitUjNCc1dsxVd5mdRQCKapRqqnTHKxSKHjHgIhAJFGNXEZkCHKygT1T7bE4orpd6p2l1+GmifMEIuRsgHbAHcARqVV63X6kSAwtaKJafTzfREsQXS+/Um4havy/HD+bUcAAAGAniSMNgAABAMASDBGAiEAoxv1LBn/vfyR7s67kRLB/n1tq3eicuA/8/V0S2YzQCYCIQDXaS3FZbdIVNxQvKxPFxM1awBO/sGxBXafz0lspOoWSA=="
 }
 ],
 "FriendlyName":"",
 "HasPrivateKey":false,
 "PrivateKey":null,
 "IssuerName":{
 "Name":"CN=R3, O=Let's Encrypt, C=US",
 "Oid":{
 "Value":null,
 "FriendlyName":null
 },
 "RawData":"MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMw=="
 },
 "NotAfter":"2022-08-05T10:50:35+01:00",
 "NotBefore":"2022-05-07T10:50:36+01:00",
 "PublicKey":{
 "EncodedKeyValue":{
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 },
 "RawData":"MIIBCgKCAQEAq8cbDO3GAfjqqbPPCBdPost8NMRmEubv85gXecll7mZMH5qSfTPuB/ouFWL3tPMf1U8usWeoSUK/48yatzBGwmj1KKlkaW9MS2QkydztRp+kH8LvbzbQvGknuOLWGHBALLT17o/3DYxuA5LnXdY+vLvJWygQoFr2N/XhnhUjcm6OaQEJpIykydfbBQGQSEuQIIw4egpgdHkYJjCOYAsXuSSggN8/FADTCec0RzVjfFTSoJ3hV9HLE9M8MCSXjuo0AJ/MbAxq91S8XmDcRjHCCd7Zw+NjHo8cxZCQ6NqGvn3xwx8ahmmbC+CyDEcIyJJZK2Yv+qE4oS8QZfaX/RaHMwIDAQAB"
 },
 "EncodedParameters":{
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 },
 "RawData":"BQA="
 },
 "Key":{
 "Key":{
 "Algorithm":{
 "Algorithm":"RSA"
 },
 "AlgorithmGroup":{
 "AlgorithmGroup":"RSA"
 },
 "ExportPolicy":0,
 "Handle":{
 "IsInvalid":false,
 "IsClosed":false
 },
 "IsEphemeral":true,
 "IsMachineKey":false,
 "KeyName":null,
 "KeySize":2048,
 "KeyUsage":16777215,
 "ParentWindowHandle":{
 "value":0
 },
 "Provider":{
 "Provider":"Microsoft Software Key Storage Provider"
 },
 "ProviderHandle":{
 "IsInvalid":false,
 "IsClosed":false
 },
 "UIPolicy":{
 "ProtectionLevel":0,
 "FriendlyName":null,
 "Description":null,
 "UseContext":null,
 "CreationTitle":null
 },
 "UniqueName":null
 },
 "LegalKeySizes":[
 {
 "MinSize":512,
 "MaxSize":16384,
 "SkipSize":64
 }
 ],
 "KeyExchangeAlgorithm":"RSA",
 "SignatureAlgorithm":"RSA",
 "KeySize":2048
 },
 "Oid":{
 "Value":"1.2.840.113549.1.1.1",
 "FriendlyName":"RSA"
 }
 },
 "RawData":"MIIFQDCCBCigAwIBAgISBNwTmwP/RTcrEeIgAdMrpaFtMA0GCSqGSIb3DQEBCwUAMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMzAeFw0yMjA1MDcwOTUwMzZaFw0yMjA4MDUwOTUwMzVaMCcxJTAjBgNVBAMTHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrxxsM7cYB+Oqps88IF0+iy3w0xGYS5u/zmBd5yWXuZkwfmpJ9M+4H+i4VYve08x/VTy6xZ6hJQr/jzJq3MEbCaPUoqWRpb0xLZCTJ3O1Gn6Qfwu9vNtC8aSe44tYYcEAstPXuj/cNjG4Dkudd1j68u8lbKBCgWvY39eGeFSNybo5pAQmkjKTJ19sFAZBIS5AgjDh6CmB0eRgmMI5gCxe5JKCA3z8UANMJ5zRHNWN8VNKgneFX0csT0zwwJJeO6jQAn8xsDGr3VLxeYNxGMcIJ3tnD42MejxzFkJDo2oa+ffHDHxqGaZsL4LIMRwjIklkrZi/6oTihLxBl9pf9FoczAgMBAAGjggJZMIICVTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFGNOFYVWWqSUAsIWQqSll5o4AleXMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMCcGA1UdEQQgMB6CHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20wTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEGBgorBgEEAdZ5AgQCBIH3BIH0APIAdwBByMqx3yJGShDGoToJQodeTjGLGwPr60vHaPCQYpYG9gAAAYCeJIwYAAAEAwBIMEYCIQCG8sf4iBitUjNCc1dsxVd5mdRQCKapRqqnTHKxSKHjHgIhAJFGNXEZkCHKygT1T7bE4orpd6p2l1+GmifMEIuRsgHbAHcARqVV63X6kSAwtaKJafTzfREsQXS+/Um4havy/HD+bUcAAAGAniSMNgAABAMASDBGAiEAoxv1LBn/vfyR7s67kRLB/n1tq3eicuA/8/V0S2YzQCYCIQDXaS3FZbdIVNxQvKxPFxM1awBO/sGxBXafz0lspOoWSDANBgkqhkiG9w0BAQsFAAOCAQEAjSEID5MWonbSiyHbmPYWO8ImCCOjkLGxgY8WJODbrWxFy+xU44UwrWOCkqYZUlv2LRmPqSyZDrIeeHK9VMbGh71oXX+XovikgAr6PpI0Mp897nPWj0XvOBaSYG0s+f+CXMtyt0tWCsQOcl+iT82+Ja71f8gbVL6l7xESewEE78pTKEH8EqD22r8VSD7FNICD8EYQr13v3AuVWObSU/R8Td6SrSVEknw1HgJS4e9nvmrMxBGKOJ+aWrAGiUydehg8M9o2gbGckMhz6D7cwB5l618cYaXKkW1dEOYZHl++qUj1/VPK+FNkiDZOPVNN//PbZuOLwAUIlZvhqGWX5/9PBg==",
 "SerialNumber":"04DC139B03FF45372B11E22001D32BA5A16D",
 "SignatureAlgorithm":{
 "Value":"1.2.840.113549.1.1.11",
 "FriendlyName":"sha256RSA"
 },
 "SubjectName":{
 "Name":"CN=blog.emilianomontesdeoca.com",
 "Oid":{
 "Value":null,
 "FriendlyName":null
 },
 "RawData":"MCcxJTAjBgNVBAMTHGJsb2cuZW1pbGlhbm9tb250ZXNkZW9jYS5jb20="
 },
 "Thumbprint":"28CF960F772ABFF22AA193C291492C27F8E13D4D",
 "Version":3,
 "Handle":{
 "value":2658150705632
 },
 "Issuer":"CN=R3, O=Let's Encrypt, C=US",
 "Subject":"CN=blog.emilianomontesdeoca.com"
}

Date d’expiration

Afin de connaître le délai d’expiration, nous devons jeter un œil aux NotAfter et NotBefore, qui se trouvent à l’intérieur de cet objet :

 "NotAfter":"2022-08-05T10:50:35+01:00",
 "NotBefore":"2022-05-07T10:50:36+01:00",

##Application console

L’extrait suivant est une simple application console construite sur .NET 6, qui produira le résultat suivant, dans lequel vous pourrez vérifier n’importe laquelle des certifications de votre choix :

using Newtonsoft.Json;
using System.Net;
using System.Security.Cryptography.X509Certificates;
using System.Text.Json;

var url = "https://blog.emilianomontesdeoca.com/";

static async Task<X509Certificate2> CheckCertificateAsync(string urlPath)
{
 var certificate = new X509Certificate2();
 var httpClientHandler = new HttpClientHandler
 {
 ServerCertificateCustomValidationCallback = (request, cert, chain, policyErrors) =>
 {
 certificate = new X509Certificate2(cert);
 return true;
 }
 };

 using HttpClient httpClient = new HttpClient(httpClientHandler);
 await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Head, urlPath));

 return certificate;
}

var cert = await CheckCertificateAsync(url);

var serializedValue = JsonConvert.SerializeObject(cert);

Console.WriteLine(serializedValue);

Console.ReadLine();

Projet de démonstration

Vous pouvez trouver l’application console dans mon Github, dans le référentiel appelé expiration-date-certificate.

Concentrer un élément dans Blazor

Thu, 05 May 2022 00:00:00 +0000

Après avoir travaillé sur le jeu Wordlzor que j’ai réalisé récemment, j’avais besoin d’ajouter une fonctionnalité assez simple : concentrer l’intégralité du jeu en entrant.

Cela devait être fait car l’utilisateur pouvait réellement taper sur le jeu et pas seulement utiliser le clavier à l’écran.

Fichier Javascript

Pour ce faire, nous devons créer un fichier Javascript appelé app.js qui contiendra une fonction

window.FocusElement = (element) => {
 element.focus();
};

Après avoir fait cela, nous devons inclure le script dans le fichier index.html :

<script src="js/app.js"></script>

Composant Blazor

Une fois que nous avons initialisé le script, nous devons trouver un élément sur lequel nous concentrer, donc dans n’importe lequel de nos composants, nous devons référencer cet élément à un objet.

Donc, dans notre composant Blazor, ajoutons un div avec le Propriété @ref :

<div @ref=@elementToFocus tabindex="0" >
 This is my focus component
</div>

Ensuite, dans la logique du composant, vous pouvez avoir la propriété sous la forme d’un ElementReference :

/// <summary>
/// Reference to element
/// </summary>
private ElementReference elementToFocus;

Injection de JSInterop

Maintenant, pour appeler la fonction que nous avons dans notre fichier Javascript, nous devons utiliser JSInterop.

Tout d’abord il faut l’injecter sur le composant avec la syntaxe suivante :

[Inject]
public IJSRuntime JSRuntime { get; set; }

Avec le service injecté, nous pouvons désormais appeler n’importe laquelle de ses méthodes, comme InvokeVoidAsync, qui appellera la fonction :

public async Task Focus()
{
 // Focus when initializing
 await JSRuntime.InvokeVoidAsync("window.FocusElement", elementToFocus);
}

Et lorsque vous appelez la fonction Focus(), elle focalisera l’élément que nous avons créé, vous pouvez évidemment refactoriser et passer l’élément lui-même en tant que paramètre.

Si vous voulez voir comment je l’ai implémenté, jetez un œil au code source de Wordlzor, je l’ai utilisé pour les alertes et la concentration lors de la fermeture du modal d’instruction.

Générez des fichiers *.dacpac à partir du projet VS Database dans GitHub Actions

Mon, 18 Apr 2022 00:00:00 +0000

Si vous avez besoin de travailler avec des bases de données et que vous souhaitez effectuer un développement agile, vous devez disposer d’un flux dans lequel chaque fois que vous ajoutez ou modifiez une table, un SP, une fonction, il la compilera et générera le fichier de déploiement pour la base de données.

Je fais cette approche depuis longtemps maintenant, nous effectuons les modifications en local, comparons à notre projet de base de données, puis lorsque nous validons et transmettons nos modifications, ils génèrent un fichier bacpac qui ira dans la base de données.

Cela élimine tous les problèmes liés au fait de le faire à la main, ce qui peut provoquer une erreur humaine et dans une base de données, c’est une très mauvaise nouvelle.

Projet de base de données

Lorsque nous créons notre projet de base de données sur Visual Studio et importons une base de données, cela se terminera comme ceci

Lorsque nous lancerons une compilation sur ce projet, cela générera un fichier dacpac qui inclura toute notre structure

Pipeline Github

Maintenant que notre code est publié sur le référentiel, nous devons maintenant créer une action qui compilera ce projet, générera ce fichier dacpac et le placera quelque part où nous pourrons le télécharger ou l’utiliser pour une autre étape.

name: DacpacGithubActions project build

on:
 push:
 branches: main

jobs:
 build:
 runs-on: windows-latest

 steps:
 - uses: actions/checkout@v2

 - name: Setup MSBuild
 uses: microsoft/setup-msbuild@v1

 - name: Navigate to Workspace
 run: cd $GITHUB_WORKSPACE

 - name: Create Build Directory
 run: mkdir artifacts

 - name: Build Solution
 run: |
 msbuild.exe /t:DacpacGithubActions /p:DebugSymbols=false /p:DebugType=None /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:OutDir="../artifacts"
 
 - name: Upload artifact
 uses: actions/upload-artifact@v1.0.0
 with:
 name: DacpacGithubActionsArtifacts
 path: "../artifacts"

Cette action fera un tas de choses, construira la solution et placera le résultat dans le dossier artifacts, créé au préalable, puis elle téléchargera les fichiers de ce dossier vers les artefacts.

Exécution du pipeline

Maintenant, lancez une build, le résultat devrait être le suivant

Si nous téléchargeons réellement l’artefact et examinons le contenu, c’est ce dont nous aurons besoin à l’avenir, lorsque nous mettrons en œuvre une étape de déploiement continu, le fichier dacpac !

#Code

L’intégralité de ce projet est sur Github et vous pouvez le trouver ici !

J’espère que vous avez aimé le message ! Ouais !

Basculer les thèmes avec Javascript Interop dans Blazor

Fri, 01 Apr 2022 00:00:00 +0000

Pour les personnes comme moi qui souffrent de flashbacks à chaque fois que j’ouvre une page Web, j’ai trouvé une solution très simple pour basculer entre les modes clair et sombre à l’aide de Javascript et l’appeler depuis Blazor à l’aide de Javascript Interop.

Définition de l’attribut parent

Tout d’abord, nous devons identifier l’élément parent avec un identifiant, car nous changeons les couleurs en fonction de la valeur de cet identifiant.

Pour faire cela en Javascript, nous devrons exécuter cette commande

document.documentElement.setAttribute('data-theme', 'YOUR_IDFENTIFIER');

Dans notre cas, nous souhaitons avoir deux identifiants pour chaque type de style, qui sont light et dark.

Création d’un fichier Javascript pour gérer la logique

Nous avons maintenant la fonction pour mettre à jour l’identifiant, créons maintenant un fichier Javscript avec une fonction qui exécute cette logique. Notre fichier va s’appeler app.js

Dans ce fichier, nous aurons une fonction qui appellera le code que nous avons mentionné plus tôt.

var toggleTheme = function (identifier) {
 document.documentElement.setAttribute('data-theme', identifier);
}

Ajout d’un fichier Javascript à Blazor

Ajoutez le script à l’application Blazor en l’ajoutant à l’endroit où se trouvent les scripts.

<script src="~/js/app.js"></script>

Création du service

Maintenant que nous avons le code Javascript, nous devons créer un service qui s’appellera ThemeToggleService.

Ce service gérera la logique pour basculer entre le thème light et dark.

Injection de JSInterop

Pour appeler n’importe quel Javascipt, nous devons appeler JSInterop, nous devons donc créer une propriété qui injectera.

using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace BlazorDarkmodeToggle.Data
{
 private readonly IJSRuntime jSRuntime;

 public ThemeToggleService(IJSRuntime jSRuntime)
 {
 this.jSRuntime = jSRuntime;
 }
}

Fonction pour définir l’identifiant

Maintenant que le service est créé, créons la fonction pour définir l’identifiant, cette fonction mettra simplement à jour le data-theme dans la page.

using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace BlazorDarkmodeToggle.Data
{
 public class ThemeToggleService
 {
 private readonly IJSRuntime jSRuntime;

 public ThemeToggleService(IJSRuntime jSRuntime)
 {
 this.jSRuntime = jSRuntime;
 }

 public bool IsLightTheme { get; set; } = true;
 public string GetIdentifier => IsLightTheme ? "light" : "dark";

 public async Task ToggleTheme() {
 IsLightTheme = !IsLightTheme;
 await jSRuntime.InvokeVoidAsync("toggleTheme", GetIdentifier);
 }
 }
}

Ajouter un service au démarrage

Afin de rendre le service disponible pour tous les composants et pages, nous devons l’ajouter au fichier Program.cs.

builder.Services.AddSingleton<ThemeToggleService>();

Donc le fichier finira comme ça

using BlazorDarkmodeToggle.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
builder.Services.AddSingleton<ThemeToggleService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
 app.UseExceptionHandler("/Error");
 // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
 app.UseHsts();
}

app.UseHttpsRedirection();

app.UseStaticFiles();

app.UseRouting();

app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Gardez à l’esprit que cela peut changer selon que vous utilisez Blazor Server ou Blazor WebAssembly.

Préparer le CSS

Maintenant que nous avons une partie du code prête, nous devons commencer à travailler sur le CSS. Ce que nous devons faire est de définir toutes les propriétés CSS qui gèrent les couleurs CSS, l’arrière-plan, etc. sur une variable.

:root {
 --background-color:#ffffff;
 --text-color:#000000;
}

Une fois que nous avons fait cela, en utilisant l’identifiant, nous pouvons facilement changer d’identifiant, et il utilisera l’une ou l’autre valeur.

[data-theme="dark"] {
 --background-color: #000000;
 --text-color: #ffffff;
}

Pour le fondu d’animation sympa, nous ajouterons simplement une propriété transition à tous, pour que ça ait l’air bien.

* {
 transition: all 250ms;
}

Nous allons maintenant attribuer ces variables à certaines classes CSS, afin que nous puissions les voir sur la page Blazor.

.app-background {
 background-color: var(--background-color);
 width: 200px;
 height: 200px;
}

.app-text {
 color: var(--text-color);
}

Pensez à ajouter le fichier à l’application Blazor en l’ajoutant sur le head.

<link href="css/app.css" rel="stylesheet" />

Appel depuis Blazor

Alors comment allons-nous tester cela ? Pour faire simple, nous allons simplement ajouter un div avec la classe app-background, et à l’intérieur il y aura un p avec la classe app-text .Créons donc une page appelée Theme.razor sous le dossier Pages et ajoutons du code pour cela.

@page "/theme"
@using BlazorDarkmodeToggle.Data
@inject ThemeToggleService ThemeToggleService

<button class="btn btn-primary" @onclick=Toggle>Toggle theme</button>

<br />

<div class="app-background">
 <p class="app-text">Hello world!</p>
</div>

@code{
 public async Task Toggle()
 {
 await this.ThemeToggleService.ToggleTheme();
 }
}

Nous pourrions tester cela en allant sur /theme, mais ajoutons-le également à la barre de navigation

<div class="nav-item px-3">
 <NavLink class="nav-link" href="theme">
 <span class="oi oi-list-rich" aria-hidden="true"></span> Theme togle
 </NavLink>
</div>

Tests

Comme vous pouvez le voir, dès que nous changeons de thème, d’arrière-plan et de couleur de police, vous pouvez maintenant voir à quel point cela est puissant. Si vous développez réellement la page entière en utilisant ces variables sur CSS, vous pouvez avoir différents thèmes et simplement les basculer !

Comme c’est génial !!

#Code

L’intégralité de ce projet est sur Github et vous pouvez le trouver ici !

J’espère que vous avez aimé le message !

Ressources

Appeler des fonctions JavaScript à partir de méthodes .NET dans ASP.NET Core Blazor

Téléchargement de fichiers sur Azure Blob Storage dans Blazor

Wed, 23 Mar 2022 00:00:00 +0000

Le service de stockage Azure Blob est l’un des services les plus utilisés de l’écosystème Azure, il vous permet de télécharger de nombreux fichiers sur le cloud tout en étant très bon marché. Il dispose également d’un site Web intuitif auquel vous pouvez accéder ou le télécharger par un lien direct.

Dans l’ensemble, c’est un bon service, je l’utilise à la fois pour des projets professionnels et personnels et honnêtement, la meilleure chose est la simplicité de son fonctionnement.

La plupart des cas dans lesquels j’ai utilisé Azure Blob Storage se trouvent dans le backend, téléchargeant directement quelque chose qui est le résultat d’une opération ou quelque chose du genre. Je n’ai donc pas vraiment téléchargé de fichier à partir d’un site Web. Malchanceux!

Puisque je suis un fanboy de Blazor, je vous propose un moyen de télécharger des fichiers sur un stockage Azure Blob en utilisant l’entrée de fichier native de HTML5.

Prérequis

Compte Azure (si vous ne l’avez pas, allez [ici] (aka.ms/free) avec un tas de $$$).
Un IDE (VS, Code, tout fonctionnera)
.NET Core 3.0 ou supérieur

Création d’un stockage Azure Blob

Accédez à votre portail Azure et procédons à la création d’un compte de stockage.

Recherchez d’abord Storage accounts et cliquez sur le résultat.

Une fois chargé, cliquez sur Create.

Un formulaire apparaîtra avec un certain nombre d’étapes, alors n’hésitez pas à les remplir.

Après avoir tout rempli avec les paramètres souhaités, passez la validation et créez la ressource.

Après sa création, cliquez sur Go to resource. Nous allons obtenir une chaîne de connexion qui nous permettra de jouer avec l’API.

Récupérez les clés de ressources

Une fois arrivés à notre ressource nouvellement créée, accédez à Acccess keys sous le Security + networking. Après le chargement, vous verrez un Connection string et un Key, copiez-les car nous en aurons besoin plus tard !

Création d’un projet Blazor Server sympa

Je vais utiliser Visual Studio 2022 pour ce didacticiel, mais comme je l’ai déjà dit, vous pouvez utiliser n’importe quel autre IDE et simplement créer le projet à l’aide de la CLI dotnet.

Alors allons-y et créons un projet Blazor très rapidement à l’aide de Visual Studio en quelques étapes seulement.

Si nous exécutons ce que nous venons de créer, cela ressemblera à ceci, juste une application Blazor normale.

Maintenant que le projet est créé, faisons quelques trucs sur l’interface utilisateur afin d’avoir une nouvelle page avec un tas d’entrées afin que nous puissions remplir les clés de la ressource, un InputFile pour le(s) fichier(s), un bouton pour faire quelque chose et un message qui résultera de l’action.

Création du modèle

Nous aurons besoin de modèles pour le faire correctement. Nous aurons d’abord la classe BlobRequest qui gérera la chaîne de connexion, le nom du conteneur et les fichiers.

De plus, pour que tout soit bien rangé, nous allons créer une classe appelée BlobFile dans laquelle nous stockerons le Name et le Data.

J’ai créé un dossier appelé Models pour que tout soit séparé.

Les cours sont très simples.```csharp using System.ComponentModel.DataAnnotations;

namespace UploadingFilesAzBlobBlazor.Models { public class BlobRequest { [Required(ErrorMessage = “Connection string is required”)] public string? ConnectionString { get; set; } [Required(ErrorMessage = “Container name is required”)] public string? Container { get; set; } public List? Files { get; set; } } }


```csharp
namespace UploadingFilesAzBlobBlazor.Models
{
 public class BlobFile
 {
 public string? Name { get; set; }
 public byte[]? Data { get; set; }
 }
}

Modification de l’interface utilisateur

Maintenant que notre modèle est créé, allons-y et faisons de la magie sur l’interface utilisateur avec !

Tout d’abord, créez une page sous le dossier Pages appelée Upload.razor.

Dans cette page, nous allons ajouter un petit formulaire qui remplira notre classe BlobRequest, nous devons donc ajouter des entrées pour ConnectionString, Container et Files.

@page "/upload"
@using UploadingFilesAzBlobBlazor.Models
@inject IJSRuntime JsRuntime
<PageTitle> Upload</PageTitle>

<h1> Azure blob storage uploader!</h1>

<EditForm Model="@modal" OnValidSubmit="@HandleValidSubmit">
<DataAnnotationsValidator />
<ValidationSummary />

<div class="mb-3">
<label for="connectionString" class="form-label"> Connection string</label>
<InputText class="form-control" id="connectionString" @bind-Value="modal.ConnectionString" />
</div>

<div class="mb-3">
<label for="container" class="form-label"> Container name</label>
<InputText class="form-control" id="container" @bind-Value="modal.Container" />
</div>

<div class="mb-3">
<label for="formFileMultiple" class="form-label"> Files</label>
<InputFile OnChange="OnInputFileChange" class="form-control" id="formFileMultiple" multiple />
</div>

<div class="mb-3">
<button type="submit" class="btn btn-primary"> Submit</button>
</div>
</EditForm>

@code {
 private BlobRequest modal = new();
 private EditContext editContext;
 IReadOnlyList <IBrowserFile> selectedFiles;
 private void OnInputFileChange(InputFileChangeEventArgs e)
 {
 selectedFiles = e.GetMultipleFiles();
 this .StateHasChanged();
 }

 private async Task HandleValidSubmit() {
 // This is where we are going to upload stuff ! 
 await JsRuntime.InvokeVoidAsync("alert", "Files uploaded!");
 }
}

C’est un peu de code mais, en gros, il restituera le formulaire et gérera la validation.

Si vous appuyez sur le bouton pour télécharger et que tout va bien, une alerte s’affichera.

Téléchargement vers Azure Blob Storage

Maintenant que la majeure partie de l’interface utilisateur est terminée, installons maintenant le package qui gérera l’API Azure Blob Storage et nous permettra de télécharger des fichiers. Assez simple.

Ajouter le package NuGet

Gérons les packages NuGet du projet et ajoutons Azure.Storage.Blob.

Télécharger sur Azure Blob Stoare

Passons maintenant à la logique pour télécharger réellement le fichier, normalement nous utiliserions la chaîne de connexion et la clé de app.config mais pour les besoins de ce didacticiel, nous utilisons des entrées et nous y fournissons les données.

Tout d’abord, ajoutons le using pour la classe Azure Blob Storage

@using Azure.Storage.Blobs
@using Azure.Storage.Blobs.Models

Ensuite nous allons travailler sur la méthode HandleValidSubmit, qui va se connecter au stockage blob, créer le conteneur s’il n’existe pas puis télécharger les fichiers.

private async Task HandleValidSubmit()
{
 try
 {
 // Instantiate container
 var container = new BlobContainerClient(modal.ConnectionString, modal.Container);
 // Create container if not exists
 var createResponse = await container.CreateIfNotExistsAsync();
 // Set access policy
 if (createResponse != null && createResponse.GetRawResponse().Status == 201)
 {
 await container.SetAccessPolicyAsync(Azure.Storage.Blobs.Models.PublicAccessType.Blob);
 }

 // For each file that we have uploaded
 foreach (var file in selectedFiles)
 {
 // New blob
 var blob = container.GetBlobClient(file.Name);
 // Delete any blob with the same name
 await blob.DeleteIfExistsAsync(Azure.Storage.Blobs.Models.DeleteSnapshotsOption.IncludeSnapshots);
 // Create a file stream and use the UploadSync method to upload the Blob.
 using (var fileStream = file.OpenReadStream())
 {
 await blob.UploadAsync(fileStream, new BlobHttpHeaders { ContentType = file.ContentType });
 }
 }

 // Display success message
 await JsRuntime.InvokeVoidAsync("alert", "Files uploaded!");
 }
 catch (Exception e)
 {
 // Display error message
 await JsRuntime.InvokeVoidAsync("alert", "An error ocurred!");
 }
}

Tester le code

Il est maintenant temps de tester le code, pour ce faire, il suffit de remplir le formulaire et de cliquer sur soumettre.

Nous afficherons une alerte et le fichier devra être téléchargé sur Azure Blob Storage, accédez au portail Azure et jetez-y un œil.

Comme vous pouvez le voir, le conteneur a également été créé, maintenant si nous entrons à l’intérieur du conteneur, nous voyons le fichier que nous avons téléchargé.

Bon travail !

Refactoriser

Maintenant que tout fonctionne, déplaçons le code de la page .razor vers une classe .razor.cs pour qu’il soit meilleur.

Si vous utilisez Visual Studio 2022, il y a une ampoule lorsque vous survolez directement dans @code, elle vous montrera une option pour Extract block to code behind, et elle fera ce qu’elle dit !

Maintenant, vous allez tout séparer et tout faire !

#Code

L’intégralité de ce projet est sur Github et vous pouvez le trouver ici !

J’espère que vous avez aimé le message ! Ouais !

Ressources

Remplacer un contrôleur principal de Pimcore

Thu, 10 Dec 2020 00:00:00 +0000

Je travaille sur un projet Pimcore depuis un certain temps maintenant, je n’ai jamais touché à PHP et Symfony de ma vie donc ça a été un beau défi.

La documentation est géniale, je veux dire, sérieusement, elle est géniale, mais on dirait qu’elle n’est pas faite pour les débutants sur le langage/le framework, donc tout ce que j’ai fait, j’ai dû en prendre des notes.

Après avoir appris que vous pouvez étendre Pimcore en utilisant des bundles, j’ai passé des heures et des heures à essayer de remplacer les contrôleurs, les méthodes javascript et bien plus encore.

Donc, dans cet article, je vais expliquer comment j’ai réussi à remplacer un contrôleur. Comment remplacer les fichiers javascript viendra plus tard 😎.

Création du bundle

Tout d’abord, nous devons créer un bundle pour cela, c’est assez simple car c’est documenté dans la documentation Pimcore, il nous suffit d’exécuter bin/console pimcore:generate:bundle --namespace=EmiDemo/EmiDemoBundle sur le dossier du projet.

Cela suscitera quelques questions mais il n’y a pas de quoi s’inquiéter.

Cela créera un nouveau dossier sous le dossier src avec l’espace de noms que nous avons déclaré précédemment, et à l’intérieur nous aurons tous les fichiers nécessaires pour le bundle.

De plus, le plugin sera détecté par le site d’administration de Pimcore, mais il sera désactivé, vous devrez l’activer pour commencer à l’utiliser.

Remplacer une méthode depuis un contrôleur

Pour remplacer une méthode dans un contrôleur, vous devez évidemment d’abord trouver l’action que vous souhaitez mettre à jour, cela semble facile mais je vais vous donner la façon dont je le fais habituellement (appris de mon coéquipier Cesar).

Allez d’abord dans la page sur laquelle vous pensez que le contrôleur agit, dans mon cas, je veux vérifier celle qui se charge lorsque nous ouvrons un actif

Il suffit ensuite d’ouvrir la console et d’aller dans l’onglet réseau, de refaire les mêmes étapes et d’essayer de retrouver l’action

Avec ces informations, vous pouvez voir que l’action qui charge l’actif est http://localhost/admin/asset/get-data-by-id?_dc=1607601778450&id=2&type=image. À partir de là, nous pouvons voir que l’action du contrôleur est get-data-by-id.

Rechercher l’action dans le contrôleur principal

Pour moi, le moyen le plus simple de le faire est simplement de rechercher dans tous les fichiers de Visual Studio Code

Il en trouvera probablement plusieurs, vous devez donc y jeter un œil et décider lequel est le bon. Dans notre cas, nous travaillons avec des actifs, il est donc clair que nous voulons utiliser le AssetController.php.

Modifier le contrôleur principal

Cela dépend du développeur, je ne le fais généralement pas car il est plus rapide de simplement remplacer le contrôleur et de développer à partir de là. Mais je recommanderais d’abord de mettre à jour le contrôleur dans le bundle principal pour voir si vos modifications fonctionnent.

Dans notre cas je retournerai juste un message au début de la méthode pour vérifier qu’elle fonctionne.

return $this->adminJson(['success' => false, 'message' => "Overriding the getDataByIdAction in the core!!"]);

Ensuite, rechargeons notre actif et vérifions l’onglet réseau

Gardons ce que nous avons là-dedans, afin que nous sachions plus tard que nous utilisons le message groupé au lieu du message principal.

Maintenant, copions simplement cela dans un fichier temporaire pour suivre ce que nous avons fait.

Déplacez ces modifications vers le bundle

Maintenant, afin de déplacer ces modifications vers notre bundle, nous avons d’abord besoin de certains éléments de notre contrôleur principal :

Espace de noms
Importations
Nom du contrôleur

Et évidemment la méthode getDataByIdAction qui est celle que l’on souhaite remplacer.

Exposer le contrôleur

Nous devons exposer le contrôleur, pour ce faire, vous devez aller dans le fichier /src/EmiDemo/EmiDemoBundle/Resources/config/pimcore/routing.yml et ajouter

options:
 expose: true

Nous devons également remplacer le prefix par celui que nous allons remplacer, dans notre cas le contrôleur admin .

Donc à la fin ça ressemblera à ça

emi_demo_emi_demo:
 resource: "@EmiDemoEmiDemoBundle/Controller/"
 type: annotation
 prefix: /admin
 options:
 expose: true

DefaultController.php

Dans notre fichier, nous ajouterons les importations et étendrons le contrôleur avec celui que nous remplacerons

Ensuite, nous copierons simplement la méthode du contrôleur principal et, dans notre cas, mettrons à jour le message que nous renvoyons.

Si vous vous en souvenez, nous avons déjà un message dans le contrôleur principal : Overriding the getDataByIdAction in the core!! et maintenant nous devrions voir Overriding the getDataByIdAction in the bundle!!

Ne renvoyons rien et voyons que nous pouvons maintenant voir la page comme elle était avant

Commentez l’instruction return et rechargez

C’est tout

Et avec cette petite démo, vous pouvez voir avec quelle facilité vous pouvez remplacer un contrôleur principal Pimcore existant. Il y a certaines étapes que vous devez suivre mais ce n’est rien de difficile. Assurez-vous simplement d’exposer le contrôleur et de vider le cache de temps en temps pendant que vous apportez des modifications, parfois il est mis en cache et vous êtes bloqué en pensant qu’il ne fonctionne pas et qu’il est simplement mis en cache.

Si vous vous demandez comment remplacer les fichiers javascript, cela viendra dans un autre tutoriel 😁.

Configurer l'Apple Magic Keyboard 2 sur Windows 10

Wed, 11 Nov 2020 00:00:00 +0000

Hier encore, j’ai acheté un Apple Magic Keyboard 2, même si j’ai environ 5 claviers mécaniques, car je voulais l’essayer et il était sans fil.

Mon OS principal est Windows 10, je l’adore et je ne veux pas le changer donc dans cette optique je savais qu’il faudrait faire certaines choses pour que le clavier fonctionne parfaitement. Je sais comment fonctionne Apple et comment ils aiment garder leurs appareils dans leur écosystème.

Problèmes

Si vous associez le clavier, vous reconnaîtrez quelques éléments :

Les touches de fonction ne fonctionnent pas
Certaines touches sont mal mappées (cela m’est arrivé dans la version espagnole)

##Documents

Pour que cela fonctionne, j’ai dû lire beaucoup sur le Web, mais ces deux liens sont ceux qui m’ont aidé à le faire fonctionner :

Installation du pilote du clavier Apple

Certaines de ces étapes proviennent de la documentation mentionnée précédemment :

Installez 7zip sur votre ordinateur si vous ne l’avez pas.
Installez Python (version 2.x) sur votre ordinateur si vous ne l’avez pas.
- IMPORTANT : La dernière version de Python est la 3.x. Mais vous avez besoin de la version 2.x car le script brigadier n’est pas compatible avec la version 3.x.
- (option) Le programme d’installation, par défaut, n’ajoute pas python.exe à votre PATH. Si vous le souhaitez, vous devez activer cette option. (voir la capture d’écran à droite)
- Si vous disposez déjà d’une autre version de Python, vous ne souhaitez probablement pas activer cette option.
Téléchargez Brigadier (un script Python qui vous aide à télécharger la dernière version de Boot Camp).
Veuillez cliquer avec le bouton droit sur le lien suivant et enregistrer le fichier en utilisant “Enregistrer le lien sous…”. https://raw.githubusercontent.com/timsutton/brigadier/master/brigadier
Ouvrez la fenêtre d’invite de commande (alias boîte DOS) et modifiez le répertoire où vous avez téléchargé le script brigadier.
En supposant que le script du brigadier ait été enregistré sous le nom « brigadier.txt », exécutez la commande suivante :
- Si Python version 2.x est dans votre PATH : python brigadier.txt –model=MacBook13,2
- Sinon : [Chemin d’accès à la version Python 2.x]\python.exe brigadier.txt –model=MacBook13,2
Il téléchargera un gros paquet avec tous les pilotes du bootcamp
Créez un dossier appelé BootCamp et copiez-y les BootCamp-xxx-yyyyyy\BootCamp\Drivers\Apple\BootCamp.msi et BootCamp-xxx-yyyyyy\BootCamp\Drivers\Apple\AppleKeyboardMagic2.
Exécutez un PowerShell d’administration et exécutez le BootCamp.msi, il installera des éléments mais nous devons mettre à jour le pilote en utilisant le contenu du dossier AppleKeyboardMagic2
Démarrez le Gestionnaire de périphériques (devmgmt.msc)
Développez le nœud Human Interface Devices
Recherchez Bluetooth HID Device
Mettez à jour le pilote en utilisant le contenu du dossier AppleKeyboardMagic2
Redémarrez l’ordinateur

Vous devriez voir le clavier Bluetooth maintenant détecté comme un clavier Apple

Mettre à jour le comportement des touches FNSi vous avez tout installé correctement, vous remarquerez que les touches FN sont activées par défaut, cela signifie que vous devez appuyer sur `fn` + `F5` pour appuyer réellement sur le bouton `F5`.

Afin de résoudre ce problème, j’ai trouvé une solution, indiquée dans la section documentation, qui fonctionne en modifiant une entrée dans le regedit.

Ouvrez Regedit
Accédez à HKEY_CURRENT_USER\SOFTWARE\Apple Inc.\Apple Keyboard Support
Créez ou mettez à jour OSXFnBehavior et définissez-le sur 0
Redémarrez l’ordinateur

Mettre à jour le mappage des clés

Si vous rencontrez un problème avec les mappages, vous pouvez utiliser SharpKeys et les mettre à jour.

C’est vraiment simple à utiliser, mais n’oubliez pas de vous déconnecter ou de redémarrer l’ordinateur pour activer les mises à jour, car cela met à jour le registre.

Pour mon cas, j’ai dû mettre à jour les clés Windows, alt, º et <>.

Ajout de bibliothèques compilées à un package NuGet

Thu, 01 Oct 2020 00:00:00 +0000

L’autre jour, j’ai trouvé un bug concernant un NullReferenceException sur une bibliothèque manquante qui aurait dû être là puisqu’il provient d’un package nuget que nous avons téléchargé.

Fondamentalement, j’ai compilé une classe de bibliothèque faisant référence à quelques projets. Lors de la phase de construction, il ajouterait les fichiers dll au dossier bin, mais lorsque packaging en tant que package nuget et les installerait dans une autre solution, les fichiers dll que j’ai référencés et qui doivent être copiés dans le dossier bin ne sont pas là.

Comment le résoudre

Résoudre ce problème est assez simple, vous devez mettre à jour le fichier nuspec et pour chacune des bibliothèques que vous souhaitez copier, ajouter le file dans la partie files.

<?xml version="1.0" encoding="utf-8"?>
<package >
 <metadata>
 <id>$id$</id>
 <version>$version$</version>
 <title>$title$</title>
 <authors>$author$</authors>
 <owners>$author$</owners>
 <requireLicenseAcceptance>false</requireLicenseAcceptance>
 <license type="expression">MIT</license>
 <projectUrl>$projectUrl$</projectUrl>
 <iconUrl>$projectIconUrl$</iconUrl>
 <description>$description$</description>
 <releaseNotes></releaseNotes>
 <copyright>$copyright$</copyright>
 <tags></tags>
 </metadata>
 <files>
 <file src="bin\Release\MyFile1.dll" target="lib\net47" />
 <file src="bin\Release\MyFile2.dll" target="lib\net47" />
 <file src="bin\Release\MyFile3.dll" target="lib\net47" />
 <file src="bin\Release\MyFile4.dll" target="lib\net47" />
 </files>
</package>

Effectuer un bash de chargement du terminal sur le répertoire personnel WSL

Tue, 22 Sep 2020 00:00:00 +0000

J’adore WSL pour le développement et les tests depuis le jour de sa sortie, puis l’application Terminal a été abandonnée et je ne pourrais pas être plus heureux, elle a l’air bien, fonctionne parfaitement et offre d’excellentes performances.

Ce serait stupide de ne pas l’utiliser avec la distribution WSL au lieu d’utiliser la console qui vous est fournie.

Cette console est évidemment bonne, mais après avoir utilisé Terminal, vous ne pouvez plus revenir en arrière. C’est tellement mieux, aussi les couleurs.

Maintenant, si vous lancez le terminal et ouvrez un nouvel onglet pour charger votre distribution WSL, il charge votre dossier utilisateur monté.

Ce n’est pas vraiment un problème, car si vous faites simplement cd ~, cela charge simplement le dossier utilisateur de distribution.

Le fait est que je ne veux pas le faire encore et encore, alors mettons à jour un fichier pour le faire tout seul.

.bashrc

Lancez le terminal ou la console, accédez à votre dossier de profil, puis modifiez le fichier .bashrc à l’aide de votre éditeur de texte préféré.

Ajoutez cd ~ à la fin du fichier avant la dernière instruction.

Enregistrez, rouvrez la console WSL avec le terminal et vous devriez être sur le dossier des profils.

Gardez à l’esprit que vous devrez faire cela pour toutes vos installations WSL, puisque nous mettons à jour le fichier bashrc pour une seule.

Génération d'objets dynamiques à l'aide d'ExpandoObject

Fri, 06 Mar 2020 00:00:00 +0000

J’ai eu besoin de convertir un fichier Excel avec ses propres colonnes définies en un nouveau avec des colonnes dynamiques, et j’étais un peu confus quant à la façon de le faire correctement sans problèmes de performances sérieux.

Je suis tombé sur un tutoriel que vous pouvez trouver ici qui utilise .NET ExpandoObject qui vous permet à peu près de créer un objet et d’ajouter des membres dynamiques.

ExpandoObject

La définition de Microsoft est :

Représente un objet dont les membres peuvent être ajoutés et supprimés dynamiquement au moment de l’exécution.

Et il contient quelques remarques :

La classe ExpandoObject vous permet d’ajouter et de supprimer des membres de ses instances au moment de l’exécution et également de définir et d’obtenir les valeurs de ces membres. Cette classe prend en charge la liaison dynamique, qui vous permet d’utiliser une syntaxe standard telle que sampleObject.sampleMember au lieu d’une syntaxe plus complexe telle que sampleObject.GetAttribute(“sampleMember”).

Comportement actuel

Nous avons un ExcelExportService qui, en passant un List<T>, dans ce cas ExcelItem, utilisera Reflection pour créer un fichier xlsx.

Jusqu’à présent, notre code ressemble à ceci :

class ExcelItem
 {
 public int Id { get; set; }
 public string Name { get; set; }
 public string Surname { get; set; }
 public string Age { get; set; }
 public string CreatedAt { get; set; }
 public string UpdatedAt { get; set; }
 }

ExcelItem est l’objet avec toutes les propriétés utilisées pour générer le fichier Excel.

public static byte[] GetExcelBytes() {
 List<ExcelItem> excelItems = new List<ExcelItem>();
 ExcelExportService exportService = new ExcelExportService();

 foreach (var items in itemsToExcel)
 {
 excelItems.Add(new ExcelItem()
 {
 Id = item.Id,
 Name = item.Name,
 Surname = item.Surname,
 Age = item.Age,
 CreatedAt = item.CreatedAt
 UpdatedAt = item.UpdatedAt
 });
 }

 return exportService.ExportToExcel(excelItems);
}

Cette approche fonctionne parfaitement, le fichier xlsx est généré sans problème, chaque colonne étant chaque propriété, vous utiliseriez cette méthode GetExcelBytes comme ceci, par exemple, pour l’enregistrer dans un fichier :

File.WriteAllBytes("path-to-somewhere/my-file.xlsx", GetExcelBytes());

Le problème

Puisque ce que nous faisons, c’est d’utiliser toutes les propriétés de l’objet ExcelItem, tout ce que je veux, c’est ne pas les utiliser toutes, mais simplement en utiliser peut-être 2 ou 3.

Une autre exigence est que je ne veux pas changer le code, tout doit être fait par le administrator, qui décidera quelles colonnes doivent être affichées, et il peut ou non connaître les propriétés du code.

TLDR : tout doit être dynamique, nous avons un objet avec des propriétés et nous devons nous assurer que le fichier généré a les N propriétés de cet objet, mais évidemment pas codées en dur.

Colonnes dynamiques

Le changement serait d’utiliser un objet dynamic, car nous aimerions définir quelles propriétés de l’objet seront utilisées pour générer la liste des colonnes.

Disons que nous avons un objet avec beaucoup de propriétés, comme une tonne d’entre elles, et que nous ne voulons pas vraiment changer l’objet ExcelItem à chaque fois que nous apportons une modification, nous créons une table ColumnExcelItem, qui sera utilisée pour générer ce ExcelItem.

Structure de la base de données

Nous enregistrons cette définition dans notre base de données avec quelque chose comme ceci :

Id PropertyName
---------------------
1 Name
2 Surname
3 Age

Notez que nous avons moins de valeurs que les propriétés existantes de l’objet ExcelItem, celui-ci ayant les propriétés 6 et nous n’avons que 3 répertoriés dans la base de données.

Notez également que le PropertyName doit correspondre au nom de propriété de l’objet que j’utiliserai pour l’affectation dynamique.

Construire l’objet

Maintenant que nous avons la table de base de données, nous devons construire le référentiel pour l’obtenir et pouvoir les utiliser dans le code.Je ne ferai pas de tutoriel sur cette partie, je passerai directement au début de la nouvelle fonction GetExcelBytes().

public static byte[] GetExcelBytes(List<string> columns) {
 List<ExcelItem> excelItems = new List<ExcelItem>();
 List<dynamic> objectsToExcel = new List<dynamic>();
 ExcelExportService exportService = new ExcelExportService();

 foreach (var item in itemsToExcel)
 {
 dynamic newObject = new ExpandoObject();
 foreach (var col in columns)
 {
 this.AddProperty(newObject, col, product.GetType().GetProperty(col).GetValue(item, null));
 }

 objectsToExcel.Add(newObject);
 }

 return exportService.ExportToExcel(objectsToExcel);
}

Nous allons maintenant créer un objet avec certaines des propriétés de ExcelItem, mais complètement dynamique. Au lieu d’utiliser les 6 propriétés, nous n’en utilisons que 3, celle que nous voulons uniquement envoyer.

Supposons maintenant que cet objet ExcelItem possède 200 propriétés, fou, mais cela pourrait arriver.

La seule chose que je dois faire est d’insérer les propriétés que je souhaite restituer dans le fichier Excel dans ce tableau ColumnExcelItem et c’est tout.

Cas

Dans ce cas, nous n’avons utilisé qu’un seul cas, mais disons que vous souhaitez avoir des rapports différents pour certains utilisateurs. Disons que le rôle admin devrait obtenir toutes les propriétés, vous créeriez alors quelque chose comme cette structure dans la base de données

ReportingTemplates

Id PropertyName
---------------------
1 Admin
2 Users

ReportingTemplateItems

Id TemplateId PropertyName
---------------------
1 1 Id
2 1 Name
3 1 Surname
4 1 Age
5 1 CreatedAt
6 1 UpdatedAt
7 2 Name
8 2 Surname
9 2 Age

Ensuite, en obtenant le modèle, vous pourriez avoir différentes colonnes, toutes dynamiques et sans rapport avec le code.

Si nous avons un utilisateur avec le rôle Admins, le fichier contiendra les colonnes Id, Name, Surname, Age, CreatedAt, UpdatedAt.

Dans le cas où vous le générez en utilisant le rôle Users, il aura Name, Age. Surname.

Conclusion

C’est une bonne façon d’apprendre comment fonctionne le dynamic dans .NET, et c’est une très bonne solution lorsque vous avez besoin d’avoir différents rôles ou modèles pour différents utilisateurs, et que vous n’êtes pas vraiment intéressé à investir du temps dans le codage en dur.

Livraison continue du package NuGet à l'aide de TravisCI

Tue, 21 Jan 2020 00:00:00 +0000

Récemment, j’ai fait un tutoriel sur la façon d’utiliser Travis CI comme outil pour tester automatiquement votre code que vous venez de pousser ou que vous essayez de pousser vers la branche master . Le faire être compilé et testé et enfin vous signaler l’état de ce changement.

Mais nous pouvons continuer à l’améliorer **, par exemple, la bibliothèque principale qui a été créée dans ce dernier tutoriel, je souhaite la rendre publique en utilisant le flux NuGet, afin que tout le monde puisse utiliser facilement ses bibliothèques !

Mais comment ? Comment allons-nous compiler, tester puis publier ce package dans le flux pour que chacun puisse le télécharger dans ses projets ?

Eh bien, c’est ce tutoriel pour 😁 !

Quoi de neuf ?

Il n’y a presque aucun changement concernant le code, les choses que nous devons changer sont l’emballage, la publication et ensuite la façon dont nous pouvons l’automatiser.

CLI .NET Core

Nous allons utiliser la .NET Core CLI, nous l’avons utilisée dans le tutoriel précédent avec des commandes comme dotnet restore, dotnet build et dotnet test.

Nous allons maintenant utiliser un nouvel ensemble de commandes !

`dotnet nuget`

Vous pouvez consulter la documentation de cet ensemble d’outils directement ici, mais une brève explication :

dotnet nuget est un ensemble d’outils essentiels qui incluent l’installation, la restauration, la suppression et la publication de packages.

Flux NuGet

NuGet est le gestionnaire de packages pour .NET. Les outils clients NuGet offrent la possibilité de produire et de consommer des packages. La galerie NuGet est le référentiel central de packages utilisé par tous les auteurs et consommateurs de packages.

NuGet est gratuit, vous pouvez donc vous inscrire, récupérer votre clé API et commencer à télécharger des packages. Ils seront téléchargés, vérifiés puis répertoriés pour tout le monde.

Récupérer la clé API

Afin de télécharger votre package, vous devrez obtenir votre clé API après l’inscription, alors rendez-vous sur la page Clés API et créez-en une nouvelle.

Gardez à l’esprit que la clé API a une expiration de 365 jours.

Copiez ensuite votre clé et stockez-la quelque part, comme indiqué sur la page, vous ne pourrez plus la revoir, et si vous ne l’avez pas sauvegardée vous devrez la régénérer.

Générer le package NuGet

Maintenant que nous avons la clé API, notre prochaine étape consiste à générer ce package NuGet à partir de la solution, alors allez-y et ouvrez la solution dans laquelle vous avez votre bibliothèque de classes.

J’utiliserai la solution de mon dernier tutoriel, qui possède une classe de bibliothèque .NET Core appelée CalculatorCLI.Core.

Allez maintenant dans les propriétés du projet, puis dans Package, vous verrez de nombreuses informations concernant le package comme la version du package, les auteurs, les descriptions et plus encore.

Ensuite, il faut remplir ceci, vous n’êtes pas vraiment obligé de tout remplir, mais les plus importants et obligatoires sont Package id, Package version, Authors et Description. De plus, si vous essayez de télécharger le fichier par vous-même, il vous sera demandé License, nous devrons également l’ajouter.

Ensuite, vous pouvez enregistrer, faire un clic droit dans le projet et sélectionner Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

La sortie montrera que si tout va bien, elle imprimera Successfully created package.

Utilisation de `dotnet`

Comme dans le tutoriel précédent, nous avons utilisé différentes commandes afin de construire et tester la solution. Maintenant, nous allons ajouter plus de commandes pour compresser et publier les packages.

Ces commandes sont :

dotnet pack -c <configuration>
dotnet nuget push <package> <k <apikey> -s <source>

Scripts de déploiement

Comme nous allons changer la façon dont la construction va être, je pense qu’avoir des fichiers différents, chacun contenant une définition de construction en fonction de l’environnement, serait la meilleure idée.

Créons donc un dossier appelé scripts avec trois scripts bash à la racine du référentiel.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Amélioration du fichier `.travis.yml`

Maintenant que nous avons le code source mis à jour, que nous connaissons les commandes que nous devons utiliser, nous devons intégrer notre livraison continue à l’intégration continue. Avec cela, nous n’avons pas vraiment besoin de faire autre chose que coder, tester, réviser et pousser.

Ce que nous allons faire maintenant, avec le fichier .travis.yml, est le suivant :

Ajoutez différents stages
Chaque stage dépend de la branche
Si votre build est sur master, cela signifie que le package doit être mis à jour, nous allons donc pousser notre package vers les flux NuGet
Si votre build est une pull request, nous allons quand même vérifier si la build est compilée et testée, mais nous n’allons pas la publier.

Étapes

D’après leur documentation :

Vous pouvez filtrer et rejeter les builds, les étapes et les tâches en spécifiant les conditions dans votre configuration de build (votre fichier .travis.yml).

Vous pouvez trouver plus d’informations sur TravisCI stages dans leur page de documentation.

Nous allons donc changer le fichier et ajouter les étapes, ce qui se termine ainsi :

language:
 csharp
sudo: required
mono: none 
dotnet: 3.0

os:
 - linux

jobs:
 include:
 - stage: compile
 script: bash scripts/compile.sh

 - stage: test
 script: bash scripts/test.sh

 - stage: deploy-prod
 if: branch = master AND type = push
 name: "Deploy to NuGet"
 script: bash scripts/push.sh

Comme vous pouvez le voir, nous avons trois étapes différentes compile, test et push, dont la dernière ne sera exécutée que lorsque le branch est master et qu’il ne s’agit pas d’un pull request, seulement d’un push.

Si vous ne comprenez pas cela, allez simplement dans la documentation et c’est expliqué assez simplement.

Dans cet esprit, tous les pull request ne transmettront rien au flux NuGet.

Définition de la clé API comme variable d’environnement

Accédez aux paramètres de construction de votre référentiel et ajoutez une nouvelle variable d’environnement, appelée NUGET_API_KEY, la valeur étant la clé API copiée à partir de la page NuGet.

Créer un `pull request`

Maintenant que tout est configuré, il est temps de créer un pull request et de vérifier si la compilation pour cette pull request ignore le dernier stage.

Vérifiez les builds

Dès que vous effectuez la pull request, une build sera mise en file d’attente dans le tableau de bord TravisCI, et comme vous pouvez le voir, nous y avons 2 builds différentes et non trois.

Acceptons maintenant le pull request et vérifions à nouveau la construction pour voir que nous avons maintenant trois tâches au lieu de deux.

Et dès que vous voyez la construction mise en file d’attente, vous pouvez voir les trois tâches, y compris le Deploy-prod à la fin.

Dès que cette version est entièrement terminée, vous pouvez voir dans les journaux que le package a été poussé vers les sources.

Et évidemment, vous pouvez le voir sur la page NuGet

C’est ça

Dans ce didacticiel, nous avons découvert comment automatiser la livraison de nos packages NuGet. Nous avons utilisé certains outils comme TravisCI, stages et dotnet nuget.

À mon avis, même si c’est quelque chose qui prendrait du temps à mettre en place correctement et qui pourrait s’avérer bien trop complexe dans certains cas. Investir du temps dans ce genre de techniques afin que tout soit parfait et automatisé en vaut la peine.

Vous pouvez trouver le code source, avec le fichier .travis.yml juste ici, si vous avez des questions, n’hésitez pas à me contacter sur mon twitter !

Intégration continue pour un projet .NET Core 3.0 utilisant TravisCI

Tue, 14 Jan 2020 00:00:00 +0000

Ce week-end dernier, j’ai décidé que je voulais démarrer correctement mon projet scraper-checker-downloader que j’ai réalisé dans différents référentiels.

Après avoir démarré un autre projet, cela devait être cool, comme vraiment cool, en utilisant CI/CD, pull request, documentation, badges dans readme, tout ce que j’ai vu, c’est cool et ce sont en effet les meilleures pratiques.

Et après un bon week-end, j’ai fini par créer Dramarr, un ensemble d’outils qui suppriment et téléchargent des émissions à partir de différentes sources.

Il existe différents référentiels dans l’organisation et la plupart d’entre eux sont des bibliothèques qui sont compilées, testées et déployées elles-mêmes dans la demande d’extraction et lorsqu’elles sont fusionnées dans la branche principale.

C’est ce qu’on appelle CI/CD ou intégration continue/livraison continue.

Mais pour ce tutoriel nous allons juste parler de CI.

Intégration continue

Qu’est-ce que c’est ?

Tiré du [blog](https://martinfowler.com/articles/continuousIntegration.html de Martin Fowler, qui est la meilleure explication que j’ai lue :

L’intégration continue est une pratique de développement logiciel dans laquelle les membres d’une équipe intègrent fréquemment leur travail, généralement chaque personne l’intègre au moins quotidiennement, ce qui conduit à plusieurs intégrations par jour. Chaque intégration est vérifiée par un build automatisé (incluant un test) pour détecter les erreurs d’intégration le plus rapidement possible.

Outils

Il existe de nombreux outils pour intégrer votre flux de travail avec CI/CD, mais pour ce didacticiel, nous utiliserons Github pour stocker notre code et les outils TravisCI pour configurer le CI. Concernant le langage et les frameworks, nous utiliserons C# et le nouveau .NET Core 3.0.

Exigences

Pour que cela fonctionne, vous avez besoin de trois choses simples :

Dernière version de Visual Studio 2019
Compte Github
Compte Travis-CI lié à votre compte Github

Projet

Pour le bien de ce didacticiel, nous allons réaliser une simple calculatrice. Nous allons créer une bibliothèque, un outil de ligne de commande et un projet de test pour tout tester.

Ce projet de test sera également en cours d’exécution lorsque nous configurerons le CI, ce qui signifie que si à l’avenir nous apportons une modification au code et que les tests que nous avons initialement créés ne réussissent pas, nous recevrons une notification ou nous pourrons simplement rejeter la pull request.

Création du dépôt Github

Tout d’abord, nous allons créer un référentiel Github, alors accédez à Github, créez le référentiel et clonez-le dans votre environnement local. J’ai décidé d’appeler ce nouveau référentiel CalculatorCLI-demo.

Créer la solution

Créons maintenant une solution vide appelée CalculatorCLI, dans le dossier racine du référentiel cloné

Bibliothèque principale

Comme ce serait le cas dans un projet du monde réel, nous stockerons notre logique dans un projet séparé qui génère une bibliothèque, alors créons-la.

Allez créer un Class Library (.NET Standard) et nommez-le CalculatorCLI.Core

###NETCore versionDès que vous créez le projet, accédez aux propriétés du projet et remplacez Target framework par .NET Standard 2.1, afin de le rendre compatible avec les projets construits dans .NET Core 3.0.

###Code

Pour le bien du didacticiel, créons une classe simple qui gère les opérations.

using System;

namespace ConsoleCalculator.Core
{
 public enum OperatorsEnum
 {
 ADD,
 SUBSTRACT,
 MULTIPLY,
 DIVIDE
 }

 public class Operation
 {
 public OperatorsEnum OperatorEnum { get; set; }
 public int LeftValue { get; set; }
 public int RightValue { get; set; }

 public Operation(string operatorString, int leftValue, int rightValue)
 {
 switch (operatorString)
 {
 case "+":
 OperatorEnum = OperatorsEnum.ADD;
 break;
 case "-":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "*":
 OperatorEnum = OperatorsEnum.MULTIPLY;
 break;
 case "/":
 OperatorEnum = OperatorsEnum.DIVIDE;
 break;
 default:
 throw new Exception("Operator invalid");
 }

 LeftValue = leftValue;
 RightValue = rightValue;
 }

 public int DoOperation()
 {
 switch (OperatorEnum)
 {
 case OperatorsEnum.ADD:
 return LeftValue + RightValue;
 case OperatorsEnum.SUBSTRACT:
 return LeftValue - RightValue;
 case OperatorsEnum.MULTIPLY:
 return LeftValue * RightValue;
 case OperatorsEnum.DIVIDE:
 return LeftValue / RightValue;
 default:
 throw new Exception("Operator is not valid");
 }
 }
 }
}

## CLI

Maintenant que nous avons le projet principal, créons l’application. Dans ce cas, il s’agira d’une simple application console qui accepte les arguments et affiche un résultat.

Alors allons-y et créons un nouveau Console App (.NET Core), je l’ai nommé CalculatorCLI.CLI.

###NETCore version

Comme nous l’avons fait précédemment, dès que vous créez le projet, accédez aux propriétés du projet et remplacez le Target framework par .NET Core 3.0, si ce n’est pas déjà le cas.

Ajoutez ensuite la référence au ConsoleCLI.Core à notre projet nouvellement créé.

###Code

Maintenant, pour le code, c’est plus simple qu’avant.

using ConsoleCalculator.Core;
using System;
using System.Text.RegularExpressions;

namespace ConsoleCalculator.CLI
{
 public class Program
 {
 public static void Main(string[] args)
 {
 if (args.Length == 0)
 {
 PrintUsage();
 }
 else
 {
 var joinedArgs = string.Join(" ", args);
 var regex = @"-op [\+\-\*\/] -l [-0-9]+ -r [-0-9]+";

 if (Regex.IsMatch(joinedArgs, regex))
 {
 int _left = Int32.Parse(args[3]);
 int _right = Int32.Parse(args[5]);
 string _operator = args[1];

 var _operation = new Operation(_operator, _left, _right);
 var _result = _operation.DoOperation();

 Console.WriteLine($"Result is: {_result}");
 }
 else
 {
 PrintUsage();
 }
 }
 }

 public static void PrintUsage()
 {
 Console.WriteLine($"Welcome to ConsoleCalculator!");
 Console.WriteLine($"");
 Console.WriteLine($"-op Operator, it must be +,-,*,/");
 Console.WriteLine($"-l Left number");
 Console.WriteLine($"-r Left number");
 Console.WriteLine($"");
 Console.WriteLine($"Example usage: -op + -l 5 -r 6");
 }
 }
}

Nous utiliserons cette application à partir d’une commande similaire, donc pour la faire fonctionner, nous devons l’appeler en passant certains paramètres. Par exemple :

ConsoleCalculator.CLI.exe -op + -l 10 -r 20

Ce qui se traduit par :

ConsoleCalculator.CLI.exe -operator + -leftValue 10 -rightValue 20

Le code pour cela est assez simple, s’il ne correspond pas à un certain modèle d’expression régulière, c’est un mauvais appel et il appelle le PrintUsage(). Cela signifie que si nous entrons quelque chose de différent d’un nombre, parce qu’il est défini sur l’expression régulière, il n’essaiera même pas de faire le calcul.

Cela signifie que si nous l’appelons ainsi :

ConsoleCalculator.CLI.exe -operator + -leftValue asdfg -rightValue ghjk

Il n’entrera jamais dans la logique des opérations et nous enregistrons les contrôles futurs comme TryParse les valeurs.

##Tester

Nous avons la bibliothèque principale et la ligne de commande, mais nous devons maintenant tester, car c’est ce que nous voulons faire dans le CI.

Alors allons-y et créons un nouveau MSTest Test Project (.NET Core) et nommons-le CalculatorCLI.Tests.

###NETCore version

Comme nous l’avons fait auparavant, dès que vous créez le projet, accédez aux propriétés du projet et remplacez Target framework par .NET Core 3.0, si ce n’est pas déjà le cas.

Ajoutez ensuite la référence aux ConsoleCLI.Core et ConsoleCLI.Core à notre projet de test nouvellement créé.

###Code

Nous allons diviser le test en deux fichiers différents : CoreTests.cs et CLITests.cs

using CalculatorCLI.Core;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.Generic;
using System.Text;

namespace CalculatorCLI.Tests
{
 [TestClass]
 public class CoreTests
 {
 public int _left = 2;
 public int _right = 2;

 [TestMethod]
 public void ShouldAdd()
 {
 var expectedResult = 4;
 var operation = new Operation("+", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldSubstract()
 {
 var expectedResult = 0;
 var operation = new Operation("-", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldMultiply()
 {
 var expectedResult = 4;
 var operation = new Operation("*", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 public void ShouldDivide()
 {
 var expectedResult = 1;
 var operation = new Operation("/", _left, _right);
 var functionResult = operation.DoOperation();

 Assert.AreEqual(functionResult, expectedResult);
 }

 [TestMethod]
 [ExpectedException(typeof(System.DivideByZeroException))]
 public void ShouldThrowExceptionForDivideByZero()
 {
 var operation = new Operation("/", _left, 0);
 operation.DoOperation();
 }

 [TestMethod]
 [ExpectedException(typeof(System.Exception), "Operator invalid")]
 public void ShouldThrowExceptionForWrongOperator()
 {
 var operation = new Operation("text", _left, 0);
 operation.DoOperation();
 }
 }
}

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.Generic;
using System.Text;

namespace CalculatorCLI.Tests
{
 [TestClass]
 public class CLITests
 {
 public string _left = "2";
 public string _right = "2";

 [TestMethod]
 public void ShouldAdd()
 {
 var args = new string[] { "-op", "+", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldSubstract()
 {
 var args = new string[] { "-op", "-", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldMultiply()
 {
 var args = new string[] { "-op", "*", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }

 [TestMethod]
 public void ShouldDivide()
 {
 var args = new string[] { "-op", "/", "-l", "45", "-r", "96" };
 CalculatorCLI.CLI.Program.Main(args);
 }
 }
}

Avec tout ce qui a été créé, nous aboutirons à une solution comme celle-ci :

Et avec cela, nous pouvons maintenant exécuter les tests, alors accédez au Test Explorer dans Visual Studio et exécutez-les !

Travis CI

Si vous ne l’avez pas déjà fait, TravisCI est un système hébergé d’intégration et de déploiement continu.

Nous devons suivre certaines étapes ici, mais nous allons d’abord lier notre référentiel Github pour qu’il soit écouté par les agents TravisCI afin de construire et de tester notre projet.

Activer le référentiel

Pour ce faire, connectez-vous à la page Travis CI et accédez à vos référentiels, puis filtrez le projet que vous avez créé et activez-le, en cliquant sur le curseur à côté du nom du référentiel.

Créer .travis.ymlNous devons créer un fichier appelé `.travis.yml` à la racine de votre projet, car comme indiqué dans la documentation :

Travis exécute uniquement les builds sur les commits que vous poussez après avoir ajouté un fichier .travis.yml.

Allez donc créer un fichier .travis.yml à la racine du dépôt avec les lignes suivantes :

language:
 csharp
sudo: required
mono: none 
dotnet: 3.0

os:
 - linux

before_script:
 - dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"

script:
 - dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release
 - dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

Je n’entrerai pas dans la syntaxe du fonctionnement du fichier .travis.yml, mais passons en revue ce qu’il fait :

Nous avons configuré que la langue sera csharp.
Nous n’utiliserons pas mono car .NET Core 3.0 fonctionnera en natif sous Linux.
Nous définissons la version dotnet sur 3.0.
Nous définissons le os, par défaut c’est linux mais je l’ai quand même ajouté.
Maintenant, nous avons before_script qui s’exécutera avant la logique majeure .ici, donc ce que j’ai mis était d’exécuter dotnet restore sur la solution pour que tout se charge parfaitement plus tard.
Maintenant, dans le script, nous allons faire un dotnet builld et un dotnet test à notre solution, cela vérifiera qu’elle compile puis exécutera les tests.

Et nous avons terminé !

Télécharger sur le maître

Il ne nous reste plus qu’à tout pousser pour maîtriser.

git add --all
git commit -m "Initial files"
git push

Vérifier l’intégration continue

Nous pouvons vérifier l’état CI du push vers master que nous avons effectué à la fois dans la page du référentiel ou dans le tableau de bord TravisCI.

En cours

Terminé

Cassons-le

Maintenant, pour voir à quel point cela est puissant, cassons le code et modifions la bibliothèque principale afin de la faire échouer.

Modifications du code

Alors allez dans le Operation.cs et changez quelque chose qui interrompra certains tests.

using System;

namespace CalculatorCLI.Core
{
 public enum OperatorsEnum
 {
 ADD,
 SUBSTRACT,
 MULTIPLY,
 DIVIDE
 }

 public class Operation
 {
 public OperatorsEnum OperatorEnum { get; set; }
 public int LeftValue { get; set; }
 public int RightValue { get; set; }

 public Operation(string operatorString, int leftValue, int rightValue)
 {
 switch (operatorString)
 {
 case "+":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "-":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;
 case "*":
 OperatorEnum = OperatorsEnum.MULTIPLY;
 break;
 case "/":
 OperatorEnum = OperatorsEnum.DIVIDE;
 break;
 default:
 throw new Exception("Operator invalid");
 }

 LeftValue = leftValue;
 RightValue = rightValue;
 }

 public int DoOperation()
 {
 switch (OperatorEnum)
 {
 case OperatorsEnum.ADD:
 return LeftValue + RightValue;
 case OperatorsEnum.SUBSTRACT:
 return LeftValue - RightValue;
 case OperatorsEnum.MULTIPLY:
 return LeftValue * RightValue;
 case OperatorsEnum.DIVIDE:
 return LeftValue / RightValue;
 default:
 throw new Exception("Operator is not valid");
 }
 }
 }
}

Et si nous exécutons à nouveau le test, parce que nous avons modifié le cas en addition, il échouera :

case "+":
 OperatorEnum = OperatorsEnum.SUBSTRACT;
 break;

Comme prévu, cela a échoué dans le cas ShouldAdd :

Maintenant, validez ce changement et poussez-le vers master, et attendez les résultats de l’agent TravisCI.

git add --all
git commit -m "Breaking changes"
git push

Construire

Passons maintenant aux journaux TravisCI et nous verrons que nous avons réussi à interrompre le projet, car les tests d’intégration échouent et l’état de la construction est une erreur.

À la toute fin du journal, nous pouvons voir l’erreur elle-même :

Réparons-le à nouveau !

Maintenant, revenez sur ce que nous avons fait, poussez le code vers la maîtrise et vérifiez l’état de la nouvelle version.

Les tests réussissent :

Et la construction est aussi une réussite :

#Conclusion

C’est vraiment assez puissant, CI et CD existent depuis longtemps, mais maintenant il est assez simple de le faire fonctionner dans chaque projet, peu importe sa taille ou sa simplicité.De mon point de vue, tout le monde devrait au moins configurer CI pour chacun de ses projets, car c’est une bonne pratique et cela vous fera éventuellement gagner du temps lors du débogage et de la recherche d’erreurs qui ne devraient pas se produire si vous aviez défini correctement tests et CI.

C’est ça

Il s’agit de savoir comment créer une solution .NET Core 3.0 avec une intégration continue sur chaque build à l’aide de TravisCI et en stockant le code dans Github.

Vous pouvez trouver le code source de ce projet ici.

Mon point de vue sur le cache en mémoire

Tue, 03 Sep 2019 00:00:00 +0000

J’ai travaillé sur des choses qui traitaient une grande quantité de données. Ce faisant, j’ai réalisé qu’une grande partie de cela ne change jamais, ou du moins pendant un certain temps, ce n’est pas le cas.

J’ai donc pensé qu’il serait utile de créer un référentiel de cache personnel, bien sûr, ce n’est pas nouveau, il y a quelques semaines, j’ai lu cela dans le post de StackOverflow écrit par Nick Craver sur la façon dont ils gèrent le cache des applications.

De plus, j’ai toujours voulu travailler avec le cache, comment ça marche, la logique et comment puis-je le faire fonctionner, alors… pourquoi pas !

Flux

Voici un aperçu rapide de la façon dont la classe qui contrôle le cache se comportera lorsque l’utilisateur demandera une valeur.

Implémentation

Avant de commencer

Je sais, je sais. Il existe System.Runtime.Caching qui gère le cache mémoire. Mais j’ai décidé de le construire moi-même, si vous souhaitez utiliser cette classe, consultez ici pour savoir comment faire.

CacheItem

La première étape consiste à disposer d’une classe qui stocke la valeur d’un objet et la date d’expiration. Il existe probablement une meilleure façon de procéder, mais voici ce que je pensais, alors voilà :

public class CacheItem
{
 public string Identifier { get; set; }
 public object Value { get; set; }
 public DateTime ValidUntil { get; set; }

 public CacheItem(string identifier, object value, TimeSpan valid)
 {
 Identifier = identifier;
 Value = value;
 ValidUntil = DateTime.UtcNow.Add(valid);
 }
}

CacheDépôt

Ensuite, nous avons besoin d’une classe qui gère les objets et les enregistre quelque part (sous le nom de CacheItem). J’aime gérer toutes les données/modèles dans les classes qui ont le suffixe Repository, mais ce n’est pas obligatoire, alors construisons-en un pour la mise en cache.

public class CacheRepository
{
 private static Dictionary<string, string> Cache = new Dictionary<string, string>();
 private static T Set<T>(string key, Func<T> lookup, TimeSpan durationMinutes)
 {
 var item = new Models.Item(key, lookup(), durationMinutes);
 return Save<T>(key, item);
 }
 private static T Save<T>(string key, Item item)
 {
 Cache[key] = JsonConvert.SerializeObject(item);
 return (T)item.Value;
 }
 private static T Get<T>(string key)
 {
 var cached = Cache.FirstOrDefault(x => x.Key == key).Value;
 var item = string.IsNullOrEmpty(cached) ? null : JsonConvert.DeserializeObject<Item>(cached);
 return (item == null)
 ? default : (item.ValidUntil > DateTime.UtcNow)
 ? JsonConvert.DeserializeObject<T>(JsonConvert.SerializeObject(item.Value)) : default;
 }
 public static T GetOrSet<T>(string key, Func<T> lookup, TimeSpan durationMinutes)
 {
 var cache = Get<T>(key);
 return cache == null ? Set(key, lookup, durationMinutes) : cache;
 }
}

Jusqu’à présent, nous avons un dictionnaire statique appelé Cache où tous les éléments seront stockés. N’oubliez pas que cela ne durera que pendant l’exécution de l’application, c’est pourquoi ce titre tutoriel contient une mise en cache en mémoire.

Gardez à l’esprit que l’élément Cache sera initialisé une fois la classe CacheRepository chargée.

La seule méthode disponible lors de l’appel de la classe CacheRepository est GetOrSet(string key, Func<T> lookup, TimeSpan durationMinutes) qui nécessite trois paramètres :

key : l’identifiant de l’objet à sauvegarder.
lookup : la fonction de rappel en cas d’expiration du cache ou s’il est nul.
durationMinutes : la durée en minutes qui sera ajoutée à l’heure actuelle (en UTC).

Il est temps de mettre en cache

Maintenant, utilisez notre référentiel de mise en cache pour obtenir des données quelque part.

Pour que tout cela ait un sens, créons un exemple d’objet avec quelques propriétés, puis un référentiel pour récupérer et remplir une liste de cet objet.

public class User
{
 public Guid Id { get; set; }
 public string Name { get; set; }
 public string Email { get; set; }
}
public class UserRepository
{
 public List<User> Get()
 {
 // Code to get users
 }
}

Puisque nous avons la méthode pour remplir une liste de User, utilisons la classe CacheRepository.

private UserRepository _userRepository = new UserRepository();
private List<User> _user;
public List<User> User
{
 get
 {
 _user = CacheRepository.GetOrSet($"users", usersRepo.Get, TimeSpan.FromMinutes(10));
 return _user;
 }
}

Et juste comme ça, chaque fois que vous accédez à la variable User, elle demandera à CacheRepository la valeur d’un objet qui a la clé users.

Si cette clé existe, il vérifiera la date d’expiration. Si l’une de ces conditions est fausse, il utilisera ce rappel pour définir la valeur (avec usersRepo.Get) de l’objet, l’enregistrera dans le cache avec la date d’expiration définie sur DateTime.UtcNow + TimeSpan.FromMinutes(10) et le renverra.

Prendre des captures d'écran de page à l'aide de Devtools

Thu, 09 May 2019 00:00:00 +0000

Il m’est parfois arrivé de devoir montrer à un client ou à un coéquipier une capture d’écran complète de l’état actuel du site Web, ou même d’une partie de celui-ci, j’ai donc utilisé Capture d’écran pleine page et, pour tout autre type de capture d’écran, l’outil Snippet de Windows ou Snaggit. Si je souhaite l’héberger en ligne comme dans cet article Gyazo, qui dispose également d’un créateur de GIF.

Récemment, j’ai découvert que Devtools dispose d’un outil qui permet de réaliser une capture d’écran pleine page, aucune extension n’est nécessaire !

Ce n’est pas une idée nouvelle, elle a été incluse dans la mise à jour de Devtools en avril 2017, mais on dirait que je vis sous un rocher et que je ne l’ai pas découvert jusqu’à maintenant…

Outils de développement

Comme indiqué dans la page officielle des outils de développement :

Chrome DevTools est un ensemble d’outils de développement Web directement intégrés au navigateur Google Chrome. DevTools peut vous aider à modifier des pages à la volée et à diagnostiquer rapidement les problèmes, ce qui vous aide finalement à créer de meilleurs sites Web, plus rapidement.

Exécuter des commandes dans Devtools

Vous savez déjà comment ouvrir Devtools mais au cas où vous l’auriez simplement oublié et pour le bien de cet article, ouvrez-le en utilisant la touche F12 ou le raccourci Ctrl + Shift + I. Ensuite, vous devez ouvrir le Run command dans le menu de Devtools ou utiliser Ctrl + Shift + P.

Outil de capture d’écran

Si vous tapez screenshot, cela filtrera les commandes, il y aura 4 types de méthodes de capture d’écran que vous pourrez utiliser :

Capture d’écran de la zone
Capture d’écran en taille réelle
Capture d’écran du nœud
Capturer une capture d’écran

Avant de vérifier toutes les méthodes de capture d’écran, une fois que devtools aura fini de traiter l’image, il la téléchargera automatiquement avec le nom de la page Web.

Capture d’écran de la zone

Le area screenshot vous permettra de sélectionner une partie du site Web et de faire une capture d’écran.

Résultat :

Capture d’écran en taille réelle

Le full size screenshot prendra une capture d’écran de la page Web entière, du début à la fin.

Résultat :

Capture d’écran du nœud

Le node screenshot vous permettra de faire une capture d’écran d’un nœud sélectionné dans l’élément inspect.

Résultat :

Capturer une capture d’écran

Le capture screenshot prendra une capture d’écran de la page actuelle sans défilement ni taille du navigateur.

Résultat :

Langages personnalisés utilisant des ressources intégrées et externes dans .NET Framework

Mon, 06 May 2019 00:00:00 +0000

#Présentation

Au travail, nous avons rencontré un problème normal auquel je suis presque sûr que de nombreux développeurs doivent faire face, à savoir les langages et les langages personnalisés des clients qui offrent nos services à leurs clients.

Par exemple, disons que la langue de base utilise un langage informel et qu’un client souhaite un langage formel parce que ses clients sont des personnes âgées.

Notez également que cette solution est disponible en plusieurs langues, nous utiliserons l’anglais et l’espagnol.

Ma langue maternelle n’est pas l’anglais. Je m’excuse pour toute erreur dans le tutoriel. Si vous trouvez des erreurs et souhaitez les corriger, vous pouvez ouvrir une pull request sur ce dépôt et je l’approuverai avec plaisir !

Ressources

Les ressources sont des fichiers XML avec l’extension .resx qui ont une structure clé/valeur et ressemblent à ce qui suit :

<?xml version="1.0" encoding="utf-8"?>
<root>
 <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
 <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
 <xsd:element name="root" msdata:IsDataSet="true">
 <xsd:complexType>
 <xsd:choice maxOccurs="unbounded">
 <xsd:element name="metadata">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" />
 </xsd:sequence>
 <xsd:attribute name="name" use="required" type="xsd:string" />
 <xsd:attribute name="type" type="xsd:string" />
 <xsd:attribute name="mimetype" type="xsd:string" />
 <xsd:attribute ref="xml:space" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="assembly">
 <xsd:complexType>
 <xsd:attribute name="alias" type="xsd:string" />
 <xsd:attribute name="name" type="xsd:string" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="data">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
 <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
 </xsd:sequence>
 <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
 <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
 <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
 <xsd:attribute ref="xml:space" />
 </xsd:complexType>
 </xsd:element>
 <xsd:element name="resheader">
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
 </xsd:sequence>
 <xsd:attribute name="name" type="xsd:string" use="required" />
 </xsd:complexType>
 </xsd:element>
 </xsd:choice>
 </xsd:complexType>
 </xsd:element>
 </xsd:schema>
 <resheader name="resmimetype">
 <value>text/microsoft-resx</value>
 </resheader>
 <resheader name="version">
 <value>2.0</value>
 </resheader>
 <resheader name="reader">
 <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
 </resheader>
 <resheader name="writer">
 <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
 </resheader>
 <data name="Action_cancel" xml:space="preserve">
 <value>Finish</value>
 </data>
 <data name="Action_greeting" xml:space="preserve">
 <value>Hello</value>
 </data>
</root>

Nous allons créer des ressources pour deux langues différentes : anglais et espagnol, donc la nomenclature des fichiers sera : resources.ISOLANGUAGECODE.resx, par exemple : resource.es.resx pour l’espagnol et resource.resx pour l’anglais, au cas où nous voudrions ajouter plus tard l’allemand, le fichier sera nommé resource.de.resx.

Ressource intégrée

Ressources embarquées, lorsque le projet sera compilé, elles seront ajoutées à l’intérieur du dll.

Voici une image avec une ressource intégrée, comme vous pouvez le voir, le fichier Resource.resx n’est pas visible dans la compilation.

Ressource externe

De l’autre côté les ressources externes ou non embarquées sont des ressources qui seront ajoutées au dossier après compilation.

Les fichiers de ressources (.resx) se trouveront dans le dossier Properties

Construire le projet

Commençons par un projet de console dans .NET Framework.

Création du fichier de ressources intégré

Ajoutez un fichier de ressources avec quelques clés et assurez-vous qu’il s’agit d’une ressource intégrée, que nous utiliserons plus tard pour mettre à jour avec des ressources externes.

Création du fichier de ressources externe

Afin de séparer les ressources externes de celles intégrées, nous ajouterons les ressources externes dans un dossier avec un nom afin de pouvoir y accéder facilement plus tard.

Astuce : pour ajouter un dossier dans le dossier Propriétés, créez-le à l’extérieur et déplacez-le à l’intérieur, Visual Studio ne vous permet pas de le créer

Faites la même chose que pour la ressource intégrée, puis accédez à properties du fichier et à l’intérieur de Advanced, Build action et remplacez-le par : Content et remplacez Copy to Output Dictionary par Copy if newer.

Voici à quoi cela devrait ressembler :

Ajout d’une clé à app.config

Parce que nous sommes des développeurs sympas et que nous aimons que tout soit bien fait et NE PAS changer le code pour chaque client, ajoutons une clé au appconfig qui portera le nom du dossier dans lequel nous rechercherons les fichiers de ressources

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <startup>
 <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
 </startup>
 <appSettings>
 <add key="CustomResources.Folder" value="John" />
 </appSettings>
</configuration>
```Ainsi, plus tard, lorsque nous rechercherons les ressources, il cherchera dans `Properties.John` au lieu de `Properties.Doe`.

Cela facilite également la modification lorsque l'application est déjà déployée puisque vous pouvez facilement modifier le fichier app.config.

## Accès aux fichiers de ressources intégrés

Utiliser .NET Framework est assez simple, donc pour accéder aux propriétés intégrées, il suffit d'utiliser l'objet `Properties`, qui aura les fichiers de ressources comme propriété, et à l'intérieur de cet objet il y aura toute la clé/valeur que nous avons dans le fichier `resx`.

```csharp
static void Main(string[] args)
{
 var hello = Properties.Resource.Action_greeting;
 var bye = Properties.Resource.Action_cancel;

 Console.WriteLine($"Action_greeting value: {hello}, Action_cancel value: {bye}");

 Console.Read();
}

En cours d’exécution, cela devrait nous montrer quelque chose comme ceci :

Action_greeting value: Hello, Action_cancel value: Cancel

Accès aux fichiers de ressources externes

Cette partie est à peu près la même, vous pouvez accéder aux fichiers de ressources par l’objet Properties.

var hello = Properties.Resource.Action_greeting;
var bye = Properties.Resource.Action_cancel;

var johnhello = Properties.John.Resource.Action_greeting;
var johnbye = Properties.John.Resource.Action_cancel;

var doehello = Properties.Doe.Resource.Action_greeting;
var doebye = Properties.Doe.Resource.Action_cancel;

Problème

Le principal problème de cette méthode est que chaque clé est une propriété à l’intérieur de l’objet, nous devons donc l’appeler comme nous l’avons vu précédemment. Si vous souhaitez appeler la clé Action_greeting du fichier de ressources de John nous devons utiliser le Properties.John suivant puis Resource.Action_greeting.

C’est là que réside le problème.

En effet, si nous développons une application pour un grand nombre de clients, ce n’est pas une bonne idée de changer la façon dont nous appelons les fichiers de ressources pour chacun d’eux.

Pourriez-vous imaginer cela ? Compiler l’application pour chaque client et remplacer John par Doe puis par autre chose. C’est fou !

#Solution

Notre chef d’équipe a pensé à une très bonne méthode, quelque chose comme un système de secours, nous devons avoir un modèle de base de ressources, puis pour chacun des clients avoir un fichier de ressources qui mettra à jour le fichier avec leurs ressources, et nous nous retrouvons avec une seule liste de ressources.

Si le client ne veut pas de ressources personnalisées, nous utilisons les ressources de base, et s’il les souhaite, nous utilisons les siennes.

Pour mettre cela dans une liste de contrôle, nous devons faire :

Trouvez un moyen de mapper toutes les clés/valeurs à un dictionnaire pour les ressources intégrées.
Trouver un moyen de mapper toutes les clés/valeurs à un dictionnaire pour les ressources externes
Mélangez les deux fichiers et disposez d’un seul dictionnaire pour chaque langue
Crée une méthode qui accède au dictionnaire et renvoie la valeur

Diagramme

Codons

Tout d’abord, créons une classe séparée où nous aurons toute notre logique, depuis l’obtention des fichiers de ressources jusqu’à leur mélange et le renvoi de la valeur. Cette classe s’appellera CustomResources.

Voilà à quoi ça ressemble :

 class CustomResources
 {

 private static Dictionary<string, string> _ResourcesEnglish;
 private static Dictionary<string, string> ResourcesEnglish;

 private static Dictionary<string, string> _ResourcesSpanish;
 private static Dictionary<string, string> ResourcesSpanish;


 private static Dictionary<string, string> OverwriteDictionary(Dictionary<string, string> currentDictionary, Dictionary<string, string> newDictionary, bool addIfDoesntExist = false)
 {
 ...
 }

 private static Dictionary<string, string> GetDictionaryFromEmbedded(string embedded, string cultureInfoCode)
 {
 ...
 }

 private static Dictionary<string, string> GetDictionaryFromFile(string file)
 {
 ...
 }

 public static string GetText(string key)
 {
 ...
 }

 public static string GetText(string key, string language)
 {
 ...
 }
 }

Notez que nous implémentons le chargement paresseux pour les propriétés, ce qui contribue à augmenter les performances et permet de charger le dictionnaire une fois.

GetDictionaryFromEmbedded : renvoie un dictionnaire à partir des ressources embarquées.
GetDictionaryFromFile : renvoie un dictionnaire provenant de ressources externes.
OverwriteDictionary : mélange deux dictionnaires et renvoie un seul.
GetText : renvoie une valeur étant donné une clé

De la ressource intégrée au dictionnaire

Nous devons récupérer toutes les propriétés du fichier XML et renvoyer un dictionnaire :

private static Dictionary<string, string> GetDictionaryFromEmbedded(string embedded, string cultureInfoCode)
{
 Dictionary<string, string> res = new Dictionary<string, string>();

 try
 {
 ResourceManager rm = new ResourceManager(embedded, Assembly.GetExecutingAssembly());
 var resourceSet = rm.GetResourceSet(new CultureInfo(cultureInfoCode), true, true);

 var resourceDictionary = resourceSet.Cast<DictionaryEntry>()
 .ToDictionary(r => r.Key.ToString(),
 r => r.Value.ToString());
 res = resourceDictionary;
 }
 catch (Exception e)
 {
 string a = e.Message;
 // Error getting resource file
 }

 return res;
}

Deux choses :- Notez qu’il a besoin d’un paramètre appelé embedded, que parementers est le nom du fichier que vous pouvez voir dans le concepteur, dans notre cas c’est : resources-demo.Properties.Resource.

Nous avons également un paramètre appelé cultureInfoCode, qui est le code de la langue à sélectionner. Heureusement pour nous, .NET Framework fait le travail à notre place et nous n’avons rien à faire, il suffit de définir que nous voulons l’anglais ou l’espagnol, et il choisira entre resource.es.resx ou resource.resx

De la ressource externe au dictionnaire

Obtenir du fichier un peu hacky mais pas difficile, nous devons obtenir l’emplacement actuel de l’exécutable, concaténer l’emplacement du fichier de ressources, puis l’analyser dans un dictionnaire.

Mais vous devez d’abord ajouter la référence à System.Windows.Forms, afin d’accéder à ResXResourceReader.

Passons maintenant à notre méthode GetDictionaryFromFile :

private static Dictionary<string, string> GetDictionaryFromFile(string file)
{
 Dictionary<string, string> res = new Dictionary<string, string>();
 string currentPath = (System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase) + file).Replace("file:\\", "");

 try
 {
 using (ResXResourceReader resxReader = new ResXResourceReader(currentPath))
 {
 foreach (DictionaryEntry entry in resxReader)
 {
 res.Add((string)entry.Key, (string)entry.Value);
 }
 }
 }
 catch (Exception e)
 {
 string a = e.Message;
 }

 return res;
}

Les paramètres du fichier doivent être renseignés avec l’emplacement de l’exécutable vers le fichier de ressources, dans notre cas : "\\Properties\\John\\Resource.resx".

Mélanger des dictionnaires

Nous avons presque terminé, tout d’abord, n’oubliez pas d’ajouter System.Configuration aux références pour pouvoir accéder à app.settings.

 private static Dictionary<string, string> OverwriteDictionary(Dictionary<string, string> currentDictionary, Dictionary<string, string> newDictionary, bool addIfDoesntExist = false)
{
 var identifier = ConfigurationManager.AppSettings["CustomResources.Folder"];
 if (String.IsNullOrEmpty(identifier))
 return currentDictionary;

 foreach (var item in newDictionary)
 {
 try
 {
 currentDictionary[item.Key] = item.Value;
 }
 catch (Exception)
 {
 if(addIfDoesntExist)
 currentDictionary.Add(item.Key, item.Value);
 }
 }

 return currentDictionary;
}

Récupérer du texte à partir du dictionnaire

Créez une méthode publique qui appelle une méthode privée qui sélectionne une langue :

private static string GetText(string key, string language)
{
 try
 {
 switch (language)
 {
 case "es":
 return ResourceSpanish[key];
 case "en":
 default:
 return ResourceEnglish[key];
 }
 }
 catch (Exception)
 {
 return $"No value with key: {key} and language: {language}";
 }
}

public static string GetText(string key)
{
 try
 {
 return GetText(key, Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName);
 }
 catch (Exception)
 {
 return $"No value with key: {key}";
 }
}

Notez que vous devez modifier le commutateur si vous ajoutez plus de langues.

Ajout de code au getter de propriétés

Puisque nous disposons actuellement de toutes les méthodes, nous pouvons modifier le getter de la propriété publique pour obtenir les valeurs.

private static Dictionary<string, string> _ResourcesEnglish;
private static Dictionary<string, string> ResourcesEnglish
{
 get
 {
 if (_ResourcesEnglish == null)
 {
 var folderIndentifier = ConfigurationManager.AppSettings["CustomResources.Folder"]; ;
 var baseResources = GetDictionaryFromEmbedded("resources-demo.Properties.Resource");
 var customResources = GetDictionaryFromFile($"\\Properties\\{folderIndentifier}\\Resource.resx", "en");
 _ResourcesEnglish = OverwriteDictionary(baseResources, customResources);
 }

 return _ResourcesEnglish;
 }
}

private static Dictionary<string, string> _ResourcesSpanish;
private static Dictionary<string, string> ResourcesSpanish
{
 get
 {
 if (_ResourcesSpanish == null)
 {
 var folderIndentifier = ConfigurationManager.AppSettings["CustomResources.Folder"]; ;
 var baseResources = GetDictionaryFromEmbedded("resources-demo.Properties.Resources");
 var customResources = GetDictionaryFromFile($"\\Properties\\{folderIndentifier}\\Resources.es.resx", "es");
 _ResourcesSpanish = OverwriteDictionary(baseResources, customResources);
 }

 return _ResourcesSpanish;
 }
}

Nous obtenons d’abord l’identifiant de app.settings.
Ensuite, nous obtenons les ressources de base, celles intégrées.
Après cela, nous obtenons les ressources personnalisées et pour cela nous avons besoin du nom du dossier (qui est l’identifiant).
Ensuite, nous les mélangeons et renvoyons la valeur.

Tout cela sera fait une seule fois, d’où le chargement paresseux.

Tests

Tout ce qui concerne le code est terminé, alors testons-le maintenant, pour obtenir une valeur du dictionnaire, nous devons appeler la méthode CustomResources.GetText(string key) qui renvoie la valeur.

Mise à jour de fichiers de ressources entiers

Ce test est un cas où nous souhaitons mettre à jour l’intégralité de la clé/valeur des fichiers de ressources, comme vous pouvez le voir sur les images, nous avons les mêmes clés mais des valeurs différentes.

Nous allons tester John, et pour définir cela, nous aurons le fichier app.config défini sur <add key="CustomResources.Folder" value="John" />.

Vérifions maintenant notre fichier de ressources de base (Properties/Resource.es.resx) :

Et puis notre fichier de ressources externe (Properties/John/Resource.es.resx) :

Ok, avec tout réglé, nous lançons l’application console, arrêtons-nous à la partie get des propriétés et vérifions tout

folderIdentifier a la valeur de l’appseting :

baseResources a la valeur des ressources de base, celles embarquées :

customResources a les valeurs des ressources externes à l’intérieur du dossier John :

Et enfin, _ResourcesSpanish a la valeur mélangée des ressources de base aux ressources externes.

Mise à jour d’un seul

Testons maintenant la même chose mais avec un scénario différent, mettons simplement à jour une clé et laissons l’autre être la même.

Comme vous pouvez le voir, les fichiers ont la même valeur pour Action_greeting mais une valeur différente pour Action_cancel, ils ne doivent donc mettre à jour que Action_cancel.

Il manque le fichier de ressources

Si vous ne fournissez pas le fichier de ressources externe, cela n’a aucune importance car comme nous nous attendons à avoir un fichier, s’il échoue, il renverra un dictionnaire vide et lors du mélange des deux dictionnaires, il se retrouvera avec celui de base.

Paire manquante dans la ressource intégrée

Si vous avez une paire dans le fichier de ressources externe, par défaut, il ne l’ajoutera pas au dictionnaire final, vous pouvez changer cela en appelant la méthode OverwriteDictionary() lors du mélange des deux dictionnaires et en définissant le paramètre addIfDoesntExist sur true.

Différentes langues

Comme vous pouvez le voir, nous n’avons spécifié aucune langue, car tout cela est fait par la fonction GetText(string key) qui appelle GetText(string key, string language), et le paramètre language est rempli par TwoLetterISOLanguageName qui renvoie la langue actuelle de notre fil.

Dans mon cas, j’ai l’espagnol comme langue par défaut et c’est pourquoi il l’affiche toujours en espagnol, mais nous pouvons aussi essayer d’utiliser l’anglais.

Codons un peu et construisons quelque chose pour vérifier l’espagnol et l’anglais.

static void Main(string[] args)
{

 // System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
 System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
 WriteText("Action_greeting");
 WriteText("Action_cancel");

 // System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("es-ES");
 System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES");
 WriteText("Action_greeting");
 WriteText("Action_cancel");

 Console.Read();
}

private static void WriteText(string key) {
 Console.WriteLine($"[Culture: {System.Threading.Thread.CurrentThread.CurrentCulture}] Key: {key} -> value: {CustomResources.GetText(key)}");
}

En exécutant ceci, le résultat devrait ressembler à ceci :

[Culture: en-US] Key: Action_greeting -> value: Hello
[Culture: en-US] Key: Action_cancel -> value: Finish
[Culture: es-ES] Key: Action_greeting -> value: Hola
[Culture: es-ES] Key: Action_cancel -> value: Terminar

Les deux premières valeurs proviennent de resources.resx qui sont en anglais et les dernières sont toutes deux en espagnol et les valeurs sont récupérées de resources.es.resx.

C’est ça

Dans ce tutoriel, nous avons trouvé un moyen de mélanger des ressources intégrées et externes pour les langues, c’était une solution à un problème que nous avions dans l’équipe et cela fonctionne depuis lors sans aucun problème.

Vous pouvez vérifier le code source ici.

Si vous avez des questions, n’hésitez pas à me tweeter à @emimontesdeocaa et je vous répondrai quand j’aurai le temps.

Test d'intégration à l'aide de Bot Framework et DirectLine pour les cas de flux

Wed, 25 Apr 2018 00:00:00 +0000

##Présentation

Dans les articles de blog précédents, nous avons effectué des tests d’intégration pour des cas uniques. Les “cas uniques” sont les cas dans lesquels après avoir demandé quelque chose au robot, il ne répondra qu’une seule fois, puis nous comparerons les résultats.

Ce guide n’expliquera pas comment s’effectuent l’authentification et les appels API. Si vous souhaitez le consulter, veuillez consulter le guide des cas uniques.

Qu’en est-il des conversations de flux ?

En utilisant la méthode actuelle, nous n’avons aucun type de flux dans la conversation, par exemple, si vous souhaitez demander de l’aide, un menu s’affiche avec différentes options, puis après en avoir sélectionné une, un autre menu. Cela ferait environ 2 responses ou plus. Cela signifie donc que l’utilisation de la solution de test d’intégration que nous avons utilisée auparavant ne fonctionnera pas.

Voici un schéma du fonctionnement du test d’intégration pour les cas uniques.

Et voici un schéma de la façon dont nous allons adapter la solution de test d’intégration actuelle aux cas de flux.

** L’explication suivante ne couvrira pas toutes les informations de base sur le fonctionnement du Bot Framework. Si vous ne comprenez pas, veuillez consulter la documentation officielle. **

Exemple de cas

Pour le guide suivant, j’utiliserai un bot avec une conversation de flux créée par moi, qui demande de l’aide puis sélectionne différentes options.

Nouvelle structure JSON

Maintenant que nous avons plus d’un request lorsque nous parlons au bot, nous devons modifier notre structure json pour ajouter tous les request que nous allons faire.

{
 "secret": "direct-line-secret",
 "directlineGenerateTokenEndpoint":
 "https://directline.botframework.com/v3/directline/tokens/generate",
 "directlineConversationEndpoint":
 "https://directline.botframework.com/v3/directline/conversations/",
 "entries": [
 {
 "name": "PedirAyuda",
 "requests": [
 {
 "type": "message",
 "text": "Ayuda",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Telefono",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Oficina",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 {
 "type": "message",
 "text": "Tenerife",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 }
 ],
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "922920252",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }
 ]
}

Comme vous pouvez le constater, il y a un changement important, request est désormais requests. Cela signifie que nous avons maintenant un List<Activity> au lieu d’un seul activity.

Nouveaux objets

Auparavant, nos objets étaient définis pour des cas uniques : TestEntry et TestEntryCollection. Pour les cas de flux, nous créerons de nouveaux objets : TestEntryFlow et TestEntryFlowCollection.

`TestEntryFlow`

Cet objet est pour chaque entrée que nous avons dans la collection, regardez que l’objet Requests est maintenant un List<Activity> au lieu d’un seul Activity comme je l’ai mentionné précédemment.

Puisque nous demanderons au bot plusieurs fois, nous devons avoir plusieurs activities qui seront envoyés à la conversation.

public class TestEntryFlow
{
 /// <summary>
 /// Entry name
 /// </summary>
 [JsonProperty("name")]
 public string Name { get; set; }
 /// <summary>
 /// Activity requested by the entry
 /// </summary>
 [JsonProperty("requests")]
 public List<Activity> Requests { get; set; }
 /// <summary>
 /// Activity response expected by the entry
 /// </summary>
 [JsonProperty("response")]
 public Activity Response { get; set; }
 /// <summary>
 /// Assert value in string
 /// </summary>
 [JsonProperty("assert")]
 public string Assert { get; set; }
}

`TestEntiresCollection`

Cet objet contiendra les informations pertinentes pour DirectLine comme le secret et les points de terminaison, ainsi que la liste des Entries que nous allons tester.

Notez que le Entries est désormais une liste de TestEntryFlow et non de TestEntry.

public class TestEntryFlowCollection
{
 /// <summary>
 /// DirectLine Secret
 /// </summary>
 [JsonProperty("secret")]
 public string Secret { get; set; }
 /// <summary>
 /// Endpoint to get the token using the secret for DirectLine
 /// </summary>
 [JsonProperty("directlineGenerateTokenEndpoint")]
 public string DirectLineGenerateTokenEndpoint { get; set; }
 /// <summary>
 /// Endpoint for a conversation in DirectLine
 /// </summary>
 [JsonProperty("directlineConversationEndpoint")]
 public string DirectLineConversationEndpoint { get; set; }
 /// <summary>
 /// Entries list
 /// </summary>
 [JsonProperty("entries")]
 public List<TestEntryFlow> Entries { get; set; }
}

Création du `TestMethod` pour les cas de flux

Nouveau flux

Tout d’abord, revoyez le schéma (c’est le même que celui que j’ai posté ci-dessus).

Comme vous pouvez le constater, la structure du flux pour effectuer le test est à peu près la même :

Obtenez des informations
Authentifier
Créez une conversationEt voilà ce qui change, nous devons maintenant envoyer plusieurs fois toute la demande à la conversation. Pour ce faire, nous devons boucler chaque requête, l’envoyer au bot, puis comparer la dernière réponse à notre réponse attendue.
Envoyez toutes les demandes
Recevez tous les messages
Obtenez la dernière réponse
Comparez avec la réponse attendue
Affirmer le résultat

###Code

Tout d’abord, nous devons extraire les informations du dossier, c’est la même chose que nous avons fait auparavant avec les cas individuels.

// Load entries from file
var path = System.IO.File.ReadAllText(@"C:\dataFlow.json");

// Deserialize to object
var data = JsonConvert.DeserializeObject<TestEntryFlowCollection>(path);

Maintenant, nous devons boucler pour chaque TestEntryFlow, des data.entries, avec cela nous pouvons suivre le même flux que nous avons fait dans les cas individuels jusqu’à la nouvelle partie, où nous bouclons dans le requests.

/// Arrange with current requested values
string token, newToken, conversationId;
Activity latestResponse = new Activity();

/// Act for step

/// 1 - Get token using secret from DirectLine in BotFramework panel
token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

/// 2 - Create a new conversation
var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

// This returns a new token and a conversationId
newToken = createdConversation.token;
conversationId = createdConversation.conversationId;

/// 3 - Send an activity to the conversation with new token and conversationId
string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";

L’étape suivante est assez simple, nous devons boucler le entry.requests et envoyer chaque activity à la conversation.

foreach (Activity step in entry.Requests)
{
 if (step.Type == ActivityTypes.Message)
 {
 /// Step
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(step));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];
 }
}

Nous utilisons le watermark pour obtenir le dernier message, le watermark est une valeur que l’API DirectLine renvoie lors de la demande d’informations sur la conversation.

Après cela, il ne nous reste plus qu’à remplir le globals avec nos latestReponse et expectedResponse.

/// Arrange with new values
var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

Et pour terminer le cas, nous évaluons la chaîne assert dans le entry.

/// Assert
Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));

Code final

[TestMethod]
public async Task ShouldTestFlowCases()
{
 // Load entries from file
 var path = System.IO.File.ReadAllText(@"C:\dataFlow.json");

 // Deserialize to object
 var data = JsonConvert.DeserializeObject<TestEntryFlowCollection>(path);

 /// Flow: Arrange -> Act -> arrange -> assert
 foreach (TestEntryFlow entry in data.Entries)
 {
 /// Arrange with current requested values
 string token, newToken, conversationId;
 Activity latestResponse = new Activity();

 /// Act for step

 /// 1 - Get token using secret from DirectLine in BotFramework panel
 token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

 /// 2 -Create a new conversation
 var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

 // This returns a new token and a conversationId
 newToken = createdConversation.token;
 conversationId = createdConversation.conversationId;

 /// 3 - Send an activity to the conversation with new token and conversationId
 string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";

 foreach (Activity step in entry.Requests)
 {
 if (step.Type == ActivityTypes.Message)
 {
 /// Step
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(step));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];
 }
 }

 /// Arrange with new values
 var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

 /// Assert
 Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));
 }

 await Task.CompletedTask;
}

Améliorations

Je pense qu’un meilleur flux pourrait être possible, mais cette amélioration signifie que la structure JSON devrait également être modifiée. De plus, pour que cela se produise, le json doit être davantage rempli.

Afin d’améliorer ces tests, nous devrions avoir un response pour chaque request, et nous devrions l’affirmer à chaque fois que nous envoyons un message. La façon dont nous procédons actuellement consiste à stocker tous les requests et le final response .

J’ai fait un schéma pour montrer à quoi cela ressemblerait.

Je pense fermement que cette méthode est globalement bien meilleure pour l’intégrité du test, puisque vous testez à peu près tous les comportements du flux au lieu de simplement tester la réponse finale.

Eh bien, c’est tout pour ce guide, n’oubliez pas que ce guide est censé être une continuation du guide des cas uniques, si vous vous sentez perdu, consultez ce guide qui est plus long et contient plus d’explications sur tout.

N’oubliez pas que tout le code est stocké dans mon github dans le référentiel this.

Passe une bonne journée!

Test d'intégration avec Bot Framework et DirectLine (1)

Tue, 24 Apr 2018 00:00:00 +0000

Depuis que j’ai commencé à travailler dans une entreprise pendant une courte période, j’ai été chargé de travailler sur des tests d’intégration pour le Bot Framework.

Mon travail au sein du groupe consiste à rendre le bot aussi stable que possible, mais d’abord, qu’est-ce que Bot Framework ?

Créez, connectez, déployez et gérez des robots intelligents pour interagir naturellement avec vos utilisateurs sur un site Web, une application, Cortana, Microsoft Teams, Skype, Slack, Facebook Messenger, etc. Démarrez rapidement avec un environnement complet de création de robots, tout en ne payant que ce que vous utilisez.

Vous pouvez trouver plus d’informations sur Bot Framework directement ici.

** L’explication suivante ne couvrira pas toutes les informations de base sur le fonctionnement du Bot Framework. Si vous ne comprenez pas, veuillez consulter la documentation officielle. **

Pourquoi ai-je besoin d’un test d’intégration ?

Des tests d’intégration sont nécessaires car chaque fois qu’un de mes collègues propose un correctif, une nouvelle fonctionnalité ou même un nouveau bug, ces tests seront exécutés avant de pousser le code en production et si l’un des tests échoue, le code ne sera pas mis en production, ce qui signifie que l’utilisateur final n’aura pas le bug.

Test d’intégration dans les bots ?

Je crois que dans les bots, les tests d’intégration sont assez importants. Vous ne pouvez pas avoir un bot dont certains de leurs menus ne fonctionnent pas, ou certaines fonctionnalités ne renvoient rien.

Les entreprises utilisent des robots pour leurs clients parce qu’elles ne veulent pas que les gens soient occupés avec leurs problèmes. Si un robot peut aider un utilisateur, les autres travailleurs pourront utiliser leur temps pour faire quelque chose de plus important.

Aperçu de la solution.

Pour que cela fonctionne, j’ai utilisé un projet Test dans Visual Studio, qui utilisera WebClient pour l’API Rest et un fichier Json, où nous stockerons nos cas.

Fichier JSON

{
 "secret": "direct-line-secret",
 "directlineGenerateTokenEndpoint": "https://directline.botframework.com/v3/directline/tokens/generate",
 "directlineConversationEndpoint": "https://directline.botframework.com/v3/directline/conversations/",
 "entries": [
 {
 "name": "DecirHola",
 "request": {
 "type": "message",
 "text": "Hola",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "No tengo respuesta para eso.",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }
 ]
}

Comme vous pouvez le constater, nous avons :

Secret Directline -> secret du bot publié
Point de terminaison de génération de jeton Directline -> point de terminaison pour obtenir le jeton en utilisant le secret
Point de terminaison de conversation Directline -> point de terminaison afin de jouer avec la conversation
Entrée -> le cas de test
- Demander -> ce que nous envoyons à la conversation
- Réponse -> ce que nous attendons d’obtenir
- Affirmer -> qu’est-ce qu’on compare

Désérialisation

Nous avons le fichier json parfaitement formaté, nous devons maintenant le charger dans la solution, nous allons donc utiliser JSON.NET et certaines classes. Nous avons d’abord la collection d’entrées, qui contient tout, puis nous avons, pour chaque collection, une liste d’entrées.

 /// <summary>
 /// Object to parse from the file
 /// </summary>
 public class TestEntriesCollection
 {
 /// <summary>
 /// DirectLine Secret
 /// </summary>
 [JsonProperty("secret")]
 public string Secret { get; set; }
 /// <summary>
 /// Endpoint to get the token using the secret for DirectLine
 /// </summary>
 [JsonProperty("directlineGenerateTokenEndpoint")]
 public string DirectLineGenerateTokenEndpoint { get; set; }
 /// <summary>
 /// Endpoint for a conversation in DirectLine
 /// </summary>
 [JsonProperty("directlineConversationEndpoint")]
 public string DirectLineConversationEndpoint { get; set; }
 /// <summary>
 /// Entries list
 /// </summary>
 [JsonProperty("entries")]
 public List<TestEntry> Entries { get; set; }
 }

Et c’est l’objet qui porte le nom, la requête, la réponse et l’assertion pour le scénario de test.


 public class TestEntry
 {
 /// <summary>
 /// Entry name
 /// </summary>
 [JsonProperty("name")]
 public string Name { get; set; }
 /// <summary>
 /// Activity requested by the entry
 /// </summary>
 [JsonProperty("request")]
 public Activity Request { get; set; }
 /// <summary>
 /// Activity response expected by the entry
 /// </summary>
 [JsonProperty("response")]
 public Activity Response { get; set; }
 /// <summary>
 /// Assert value in string
 /// </summary>
 [JsonProperty("assert")]
 public string Assert { get; set; }
 }

Analyse de json en objet dans le scénario de test

Avoir les classes pour l’objet d’analyse, c’est assez simple car nous devons lire en tant qu’objet.

// Load entries from file
var path = System.IO.File.ReadAllText(@"C:\data.json");

// Deserialize to object
var data = JsonConvert.DeserializeObject<TestEntriesCollection>(path);

Désormais, avec cette collection, nous pourrons la parcourir et obtenir les informations en utilisant, par exemple, un foreach.

 foreach (TestEntry entry in data.Entries)
 {
 ....
 }

Et c’est tout pour cette partie, la partie suivante inclura l’autorisation pour DirectLine, rappelez-vous que tout le code est stocké dans mon github dans le référentiel this.

Test d'intégration avec Bot Framework et DirectLine (2)

Tue, 24 Apr 2018 00:00:00 +0000

Dans cette partie, nous allons effectuer l’autorisation DirectLine et obtenir les valeurs de la réponse du bot.

Maintenant que nous avons effectué la désérialisation, il est temps d’obtenir les informations de la collection et des entiers que nous utiliserons pour obtenir l’autorisation, effectuer les appels API et affirmer le résultat.

** L’explication suivante ne couvrira pas toutes les informations de base sur le fonctionnement du Bot Framework. Si vous ne comprenez pas, veuillez consulter la documentation officielle. **

Effectuer des appels API à l’aide de WebClient

Afin de faciliter l’appel de l’API, j’ai créé une classe utils, où nous enregistrons les fonctions que nous utiliserons plusieurs fois, cette classe comprend uploadString pour POST et downloadString pour GET.

 public class Utils
 {
 /// <summary>
 /// Uploads to an URL and gets result
 /// </summary>
 /// <typeparam name="T">Type of object you are receiving</typeparam>
 /// <param name="bearer">Token</param>
 /// <param name="url">Url</param>
 /// <param name="serializedJson">Serialized JSON to send</param>
 /// <returns></returns>
 public static T uploadString<T>(string bearer, string url, string serializedJson)
 {
 string serializedResult = "";

 /// Webclient
 using (var client = new WebClient())
 {
 /// Add headers
 client.Headers.Add("Content-Type", "application/json");
 client.Headers.Add("Authorization", $"Bearer {bearer}");

 /// Upload string
 serializedResult = client.UploadString(url, serializedJson);
 }

 /// Get result and return it as an object
 return JsonConvert.DeserializeObject<T>(serializedResult);
 }

 /// <summary>
 /// Downloads from URL
 /// </summary>
 /// <typeparam name="T">Type of object you are receiving</typeparam>
 /// <param name="bearer">Token</param>
 /// <param name="url">Url</param>
 /// <returns></returns>
 public static T downloadString<T>(string bearer, string url)
 {
 string serializedResult = "";

 /// Webclient
 using (var client = new WebClient())
 {
 /// Add headers
 client.Headers.Add("Content-Type", "application/json");
 client.Headers.Add("Authorization", $"Bearer {bearer}");

 /// Download string
 serializedResult = client.DownloadString(url);
 }

 /// Get result and return it as an object
 return JsonConvert.DeserializeObject<T>(serializedResult);
 }
 }

Autorisation DirectLine

Si vous lisez la documentation officielle, vous pourrez trouver comment faire, et c’est assez simple, en utilisant nos fonctions c’est encore plus simple. Tout d’abord, rappelez-vous que nous sommes à l’intérieur de l’instruction foreach, puisque nous effectuons l’authentification pour chaque cas, au cas où nous manquerions de temps, ce qui signifierait que le test échouerait.

/// Arrange with current requested values
string token, newToken, conversationId;
/// Act

/// 1 - Get token using secret from DirectLine in BotFramework panel
token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

Nous avons maintenant le jeton, qui sera utilisé pour effectuer tous les appels suivants vers le point final de la conversation.

Créer une conversation.

Pour parler au bot, nous devons d’abord créer une conversation, cette conversation renverra un nouveau jeton qui inclut l’identifiant de la conversation.

/// 2 -Create a new conversation
var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

// This returns a new token and a conversationId
newToken = createdConversation.token;
conversationId = createdConversation.conversationId;

De plus, nous stockons les newToken et conversationId, les deux seront nécessaires à l’utilisateur pour envoyer des messages au bot.

Envoyer l’activité à la conversation

Maintenant, avec le conversationId et le conversationEndpoint, nous pouvons créer le point de terminaison final pour envoyer un Activity qui est le request du fichier json.

/// 3 - Send an activity to the conversation with new token and conversationId
string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";
Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(entry.Request));

Recevoir le dernier message

Dans l’historique des messages, après avoir envoyé l’activité, le bot aurait déjà dû répondre, nous devons donc récupérer tous les messages avec le filigrane, puis, en utilisant ce filigrane, filtrer le dernier message/activité.

/// 4 - Get all activities, we get a List<activity> and a watermark
var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

/// 5 - Get the latest activity which is the response we should be expecting
var latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];

Et c’est tout pour cette partie, la partie suivante inclura la partie où nous récupérons le texte du assert dans le json, le convertissons en code comme en utilisant eval() en Javascript mais en C#, puis en utilisant le Assert.isTrue() pour obtenir le résultat final du test.

N’oubliez pas que tout le code est stocké dans mon github dans le référentiel this.

Test d'intégration avec Bot Framework et DirectLine (3)

Tue, 24 Apr 2018 00:00:00 +0000

Ceci est la dernière partie du guide, dans cette partie, nous évaluerons le texte de l’assertion dans le json.

Maintenant que nous avons utilisé le request et envoyé comme activity au bot, nous avons obtenu le response et nous devons comparer ce que le assert dans le json (la réponse que nous avons stockée dans le json, c’est la réponse attendue) avec la réponse que nous avons obtenue du bot.

** L’explication suivante ne couvrira pas toutes les informations de base sur le fonctionnement du Bot Framework. Si vous ne comprenez pas, veuillez consulter la documentation officielle. **

Ajout de Microsoft.CodeAnalysis à la solution

Tout d’abord, nous devons inclure CodeAnalysis en tant que package NuGet.

Après l’installation, n’oubliez pas d’ajouter le pacakge au fichier .cs.

using Microsoft.CodeAnalysis.CSharp.Scripting;

Création d’un objet `Globals`

Afin d’évaluer, nous devons transmettre les paramètres à l’évaluateur. Cet évaluateur a besoin d’un fichier de configuration.

 /// <summary>
/// Object to pass parameters to Roslyn compiler
/// </summary>
public class Globals
{
 /// <summary>
 /// ExpectedResponse
 /// </summary>
 public Activity Request;
 /// <summary>
 /// ReceivedResponse
 /// </summary>
 public Activity Response;
}

Cette partie est très importante, dans ce fichier de configuration, nous inclurons les objets que nous comparerons, donc pour nous, nous devons lui transmettre la réponse attendue et la réponse reçue.

Avec ces informations, il utilisera le assert dans le fichier json et évaluera ce qui est dit.

/// Arrange with new values
var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

/// Assert
Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));

Le EvaluateAsync<T> évalue et renvoie T, dans notre cas, nous transmettons le string à évaluer et globals, qui contient les données où il sera évalué.

Je vais essayer d’expliquer cela avec un exemple, en utilisant une entrée (qui a un nom, une requête, une réponse et une assertion).

{
 "name": "DecirHola",
 "request": {
 "type": "message",
 "text": "Hola",
 "from": {
 "id": "default-user",
 "name": "User"
 },
 "locale": "es",
 "textFormat": "plain",
 "timestamp": "2018-04-09T08:04:37.195Z",
 "channelData": {
 "clientActivityId": "1523261059363.6264723268323733.0"
 },
 "entities": [
 {
 "type": "ClientCapabilities",
 "requiresBotState": true,
 "supportsTts": true,
 "supportsListening": true
 }
 ],
 "id": "61hacck8j6jg"
 },
 "response": {
 "type": "message",
 "timestamp": "2018-04-09T08:04:37.901Z",
 "localTimestamp": "2018-04-09T09:04:37+01:00",
 "serviceUrl": "http://localhost:50629",
 "channelId": "emulator",
 "from": {
 "id": "j98bbdf097a",
 "name": "Bot"
 },
 "conversation": {
 "id": "eabcie4be8ak"
 },
 "recipient": {
 "id": "default-user"
 },
 "locale": "es",
 "text": "No tengo respuesta para eso.",
 "attachments": [],
 "entities": [],
 "replyToId": "61hacck8j6jg",
 "id": "47me557ikbf7"
 },
 "assert": "Request.Text == Response.Text"
 }

Obtenons les éléments importants de cette entrée, d’abord l’assertion "assert": "Request.Text == Response.Text", cela signifie qu’il comparera le Request.Text avec le Response.Text, et renverra la valeur sous forme booléenne.

Mais lorsque nous appelons la fonction await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals) nous passons 2 paramètres :

string chaîne à évaluer -> "Request.Text == Response.Text"
globals données pour l’évaluateur -> dans ce cas, nous devons donner un Request et un Response, la demande est notre réponse attendue et la réponse est la réponse reçue.

Pendant que nous remplissons les données dans l’évaluateur, nous pouvons maintenant utiliser la chaîne et évaluer, elle renverra donc true ou false.

Terminé

Nous avons terminé, vous pouvez voir ici le TestMethod terminé

[TestMethod]
public async Task ShouldTestSingleCases()
{
 // Load entries from file
 var path = System.IO.File.ReadAllText(@"C:\data.json");

 // Deserialize to object
 var data = JsonConvert.DeserializeObject<TestEntriesCollection>(path);

 /// Flow: Arrange -> Act -> arrange -> assert

 foreach (TestEntry entry in data.Entries)
 {
 /// Arrange with current requested values
 string token, newToken, conversationId;

 if (entry.Request.Type == ActivityTypes.Message)
 {
 /// Act

 /// 1 - Get token using secret from DirectLine in BotFramework panel
 token = Utils.uploadString<DirectLineAuth>(data.Secret, data.DirectLineGenerateTokenEndpoint, "").token;

 /// 2 -Create a new conversation
 var createdConversation = Utils.uploadString<DirectLineAuth>(token, data.DirectLineConversationEndpoint, "");

 // This returns a new token and a conversationId
 newToken = createdConversation.token;
 conversationId = createdConversation.conversationId;

 /// 3 - Send an activity to the conversation with new token and conversationId
 string directlineConversationActivitiesEndpoint = data.DirectLineConversationEndpoint + conversationId + "/activities";
 Utils.uploadString<DirectLineAuth>(newToken, directlineConversationActivitiesEndpoint, JsonConvert.SerializeObject(entry.Request));

 /// 4 - Get all activities, we get a List<activity> and a watermark
 var getLastActivity = Utils.downloadString<ActivityResponse>(newToken, directlineConversationActivitiesEndpoint);

 /// 5 - Get the latest activity which is the response we should be expecting
 var latestResponse = getLastActivity.activities[Int32.Parse(getLastActivity.watermark)];

 /// Arrange with new values
 var globals = new Objects.Globals { Request = entry.Response, Response = latestResponse };

 /// Assert
 Assert.IsTrue(await CSharpScript.EvaluateAsync<bool>(entry.Assert, globals: globals));
 }
 }
 await Task.CompletedTask;
}

Diagramme

Voici un diagramme de tout le flux que nous avons suivi pour arriver à ce point, j’espère que si vous n’avez pas compris quelque chose, cela clarifie les choses.

Et c’est tout, cela est fait pour des cas uniques où le cas est 1 pour 1, l’utilisateur envoie un activity et le bot renvoie un autre simple activity.

J’espère que vous l’avez aimé, le prochain sera les cas de flux de tests avec plus d’une réponse.

N’oubliez pas que tout le code est stocké dans mon github dans le référentiel this.

À propos

Mon, 01 Jan 0001 00:00:00 +0000

À propos de moi

Je suis Emiliano Montesdeoca, un développeur logiciel uruguayen-espagnol, Microsoft MVP en Technologies pour Développeurs, et fier papa basé à Tenerife, Îles Canaries.

J’adore relever des défis techniques complexes et construire des solutions cloud évolutives avec les technologies Microsoft. Mon kit d’outils quotidien tourne autour de .NET, Azure, l’IA avec Semantic Kernel et des architectures modernes comme .NET Aspire.

Ce que je fais

En tant que Team Lead Cloud Solutions chez Intelequia Technologies, je dirige la conception et la livraison d’applications cloud-natives — en alliant vision stratégique et exécution concrète. Je m’épanouis à l’intersection de l’architecture et du code, en veillant à ce que notre équipe livre des solutions à la fois élégantes et prêtes pour la production.

Communauté

Je suis un conférencier international fréquent, ayant été reconnu comme Sessionize Most Active Speaker en 2023, 2024 et 2025. Je partage des insights pratiques du monde réel lors de conférences mondiales et à travers mes blogs.

Je suis également le créateur de The .NET Blog — une ressource pour la communauté .NET — et j’écris régulièrement sur ce blog sur ce que j’apprends et construis.

Le mentorat et la construction de communauté font partie intégrante de qui je suis. Redonner à l’écosystème qui a façonné ma carrière est quelque chose que je prends très au sérieux.

Connectons-nous

Je suis toujours ouvert à parler lors d’événements, à collaborer sur des projets ou à discuter d’architecture cloud et d’IA. N’hésitez pas à me contacter !

Email: emimontesdeoca@outlook.es
GitHub: @emimontesdeoca
X / Twitter: @emimontesdeocaa
LinkedIn: emimontesdeoca
Instagram: @emimontesdeoca
Sessionize: emimontesdeoca

Conférences

Mon, 01 Jan 0001 00:00:00 +0000

Je suis un conférencier fréquent dans les conférences technologiques internationales, en me concentrant sur .NET, Azure, l’IA et le développement cloud-native. J’ai été honoré comme Sessionize Most Active Speaker en 2023, 2024 et 2025, et je détiens la certification Microsoft MVP en Technologies pour Développeurs.

Si vous souhaitez que j’intervienne à votre événement, contactez-moi!

2026

Blazor en 2026

Un regard sur l’état actuel de Blazor en 2026 et comment il a évolué avec .NET 10. Nous passons en revue les derniers changements et améliorations, leur impact sur le développement d’applications réelles, et quel modèle d’hébergement Blazor convient le mieux à chaque scénario.

Supercharger le Support Niveau 3 avec l’IA : Azure Functions + OpenAI en Action

Comment Azure Functions, les alertes Azure Monitor et Azure OpenAI travaillent ensemble pour accélérer le support Niveau 3. Du triage automatique des alertes à l’analyse intelligente des logs — un regard pratique sur l’ajout d’IA aux workflows de support réels.

Du tableau de bord à l’agent : la prochaine étape de l’observabilité

Une session pratique reliant le monde des agents IA et l’observabilité en production. De Semantic Kernel aux agents autonomes qui interrogent les données OpenTelemetry, interagissent avec Grafana via MCP et aident à opérer et optimiser des systèmes réels.

À venir : Global Azure 2026 — Avril 2026, Madrid, Espagne

2025

Le Framework d’Agents Microsoft pour sauver Noël

Construire et coordonner plusieurs agents IA en utilisant le Microsoft Agent Framework pour trouver les cadeaux de Noël parfaits. Chaque agent se spécialise — de la génération d’idées de cadeaux à la comparaison de prix — travaillant ensemble pour des achats de Noël plus intelligents.

Booster le Support Niveau 3 avec l’IA : Azure Functions + Semantic Kernel en Action

Azure Functions, Azure Monitor et Semantic Kernel travaillant ensemble pour rendre le support Niveau 3 plus rapide et efficace — de la détection automatique des alertes à l’analyse intelligente des logs.

Quoi de neuf dans Blazor avec .NET 10 ?

Explorer les nouvelles fonctionnalités clés de Blazor pour .NET 10, y compris les améliorations de performances, les formulaires, l’état persistant et une interopérabilité JavaScript plus puissante.

IA Hybride avec C#, Semantic Kernel et Gemini : Construisez des Applications Entreprise Plus Intelligentes

Orchestration de workflows IA hybrides en C# — mêlant des modèles locaux (Phi-3) avec Gemini Pro/Ultra via Vertex AI, construisant des agents cognitifs avec des plugins Semantic Kernel et concevant des architectures adaptatives.

.NET Aspire : Construire des Applications Cloud-Native Sans les Maux de Tête

Une session pratique construisant des microservices cloud-first qui sont nés scalables, résilients et observables. Explorer comment .NET Aspire élimine 70% du boilerplate cloud.

.NET Aspire : Cloud-Native Sans le Chaos

Exemples concrets de conception d’applications nativement scalables — avec observabilité et résilience automatique intégrées dès le premier commit.

2024

L’IA Rencontre SQL : Construire une Pizzeria Intelligente avec .NET et Semantic Kernel

Des interactions IA en langage naturel qui comprennent votre code et vos données — construire une pizzeria intelligente propulsée par .NET et Semantic Kernel.

.NET Aspire : Applications Cloud-Native sans complications

Construire des microservices cloud-first sans tracas — une session pratique et démo montrant comment .NET Aspire simplifie le développement cloud-native.

Power Platform : Le Voyage du Low-code vers les Technologies Pro-code

Transition des Power Apps low-code vers des composants pro-code avancés en TypeScript, tout au sein de la même plateforme.

Automatisation Intelligente : Transformez vos Applications Entreprise avec l’IA Intégrée

Emmener les applications .NET au niveau supérieur — combinant logique traditionnelle et raisonnement basé sur l’IA avec Semantic Kernel et .NET Aspire.

Du Low-Code au Pro-Code : Approches pour le Développement d’IA dans les Solutions Entreprise

Explorer différentes approches pour les solutions entreprise — de Power Platform avec IA au développement traditionnel avec Semantic Kernel.

Contrôler les Dépenses de Voyage avec Azure

Utiliser Azure AI Vision, Document Intelligence et OpenAI avec Semantic Kernel pour automatiser la gestion des dépenses de voyage.

Badges et Reconnaissances

🏆 Sessionize Most Active Speaker 2025
🏆 Sessionize Most Active Speaker 2024
🏆 Sessionize Most Active Speaker 2023
🏅 Microsoft MVP en Technologies pour Développeurs

Voir toutes les sessions sur Sessionize →

Emiliano Montesdeoca

Blazor à partir de zéro : Chapitre 3 — Des composants qui passent à l’échelle

Ce qu’est vraiment un composant Blazor

Étape 1 : Commencer avec un composant ciblé

Étape 2 : Utiliser les paramètres pour expliciter le comportement

Étape 3 : Utiliser RenderFragment pour la composition

Étape 4 : Préférer la composition aux pages géantes

Étape 5 : Équilibrer markup et logique

Étape 6 : Une structure de dossiers pragmatique

Erreurs fréquentes au début

Chapitre suivant

Blazor à partir de zéro : Chapitre 2 — Votre première application Blazor

Étape 1 : créer le projet

Étape 2 : l’exécuter en local

Étape 3 : comprendre la structure du projet

Étape 4 : votre première modification

Étape 5 : lire Program.cs une fois

Problèmes courants

Prochain chapitre

Blazor de zéro : Chapitre 1 — Qu'est-ce que Blazor ?

Un peu d’histoire

Ce qu’est vraiment Blazor

Les modèles de rendu

SSR statique

Serveur interactif

WebAssembly interactif

Mode Auto

Mélanger les modes dans la même application

Comment Blazor se compare aux frameworks JavaScript

Ce dont vous avez besoin pour suivre la série

La suite

Blazor de zéro : une nouvelle série

À qui s’adresse cette série

Ce que nous allons couvrir

Pourquoi une série, pourquoi maintenant

Comment suivre la série

Types de syndicats C# : les syndicats discriminés arrivent enfin

Que sont les syndicats discriminés ?

Comment nous simulons les syndicats aujourd’hui

Enregistrements abstraits avec héritage

Énumération manuelle + modèle de données

La proposition C# : le mot clé union

Syndicats génériques

Unions avec méthodes

Correspondance de modèles imbriqués

Clauses de garde

Exemples pratiques

Le modèle de résultat : remplacement des exceptions pour les erreurs attendues

Modélisation de domaine : types de paiement

Machines à états

Comment l’essayer

Comparaison avec les approches existantes

Ce que cela signifie pour l’écosystème .NET

Conclusion

Construire un système RAG en C# avec Semantic Kernel

Comment fonctionne RAG

Prérequis

Configuration du noyau

Définir le modèle de données

Ingestion de documents

Recherche de morceaux pertinents

Générer des réponses avec le contexte

L’utiliser

Passage en production

Création de flux de travail d'agent avec Microsoft Agent Framework

Que sont les workflows des agents ?

Prérequis

Créer un workflow séquentiel

Définir les agents

Exécution séquentielle

Exécution parallèle

Branchement conditionnel

Ajout de plugins aux agents de workflow

Gestion des erreurs dans les workflows

Conclusion

Ressources

Cycle de vie des composants Blazor : le guide complet

Le cycle de vie en un coup d’œil

SetParametersAsync

OnInitialized / OnInitializedAsync

Étape 3 : Utiliser `RenderFragment` pour la composition

La proposition C# : le mot clé `union`