Dans les précédents articles de cette série, j'ai montré qu'il était très facile d'utiliser les records C# 9 comme ids fortement typés :

Les Azure Functions peuvent être déclenchées de pleins de manières possibles : http, message service bus, modifications blob storage, etc. Pour chacune de ces manières il est intéressant de récupérer les paramètre à l'origine du déclenchement de l'exécution et le lien qui permet de créer ces paramètres est un Binding. Dans cet article nous verrons comment en créer un nouveau et pourquoi c'est intéressant.

Avec la récente sortie d'ASP.NET Core 5, la génération de la documentation OpenAPI (aka la doc Swagger :)) pour décrire nos Web API est maintenant incluse par défaut à la création d'un nouveau projet.

Dans le précédent article de cette série, on avait remarqué un petit souci qu'on avait laissé de côté : les ids fortement typés étaient sérialisés de façon quelque peu étrange :

Dans une application ASP.NET Core + React, il est plutôt courant de vouloir renvoyer quelques erreurs "standard" depuis n'importe quel API endpoint, et surtout les présenter à l'utilisateur côté Front end de manière propre (grosso modo, sans que l'appli ne crash complètement par exemple :D) Pour des erreurs classiques bien connues tel que 401, 403, 404, etc., Pas besoin de customisation particulière côté ASP.NET Core si ce n'est renvoyer le bon StatusCode, et utiliser un système Front end pour les gérer tel que les interceptors axios.

Le ViewPager est un composant beaucoup utilisé sur Android : il permet d'afficher plusieurs contenus verticaux (des pages) que l'utilisateur peut retrouver en swippant. Dans cet article nous verrons comment corriger un bug très courant lié à la rotation du téléphone.

J'ai déjà consacré une longue série sur OpenIddict et cet article est une petite astuce qui vient y faire suite. Nous allons voir comment ajouter un claim au jeton créé pour le retrouver facilement sur l'utilisateur de l'HttpContext.

Dans mon précédent article, j'ai montré qu'il était très facile d'utiliser des types record C# 9 comme ids fortement typés :

Il existe de nombreuses manières de partager des composants entre plusieurs apps React (StoryBook, Lerna, registries privées npm, etc.), mais que faire si vous venez de créer 2 applications ASP.NET Core en utilisant la ligne de commande dotnet new react (Une application Front Office appelée Front et une application Back Office appelée Back par exemple) et souhaitez un moyen simple de partager des composants React entre ces 2 app ?

Les entités ont généralement des ids de type entier, GUID ou chaîne de caractères, parce que ces types sont supportés nativement par les bases de données. C'est un fait largement accepté et rarement remis en question. Pourtant, si toutes nos entités ont des ids de même type, il est très facile de les mélanger accidentellement, et d'utiliser par exemple l'id d'un produit là où l'id d'une commande était attendu. C'est d'ailleurs une source de bugs assez fréquente.

Bonjour !

Alors que certains sont des grands fans d'ARM, j'ai tendance à préférer la librairie .Net Azure Fluent. Mes environnements Azure sont donc décrits et générés via une application console avec le strict minimum d'opérations manuelles. Dans cet article, nous verrons comment créer un certificat auto-signé depuis votre code et l'utiliser dans votre AppService !

Bonjour !

L'injection de dépendances est un excellent pattern, qui peut vraiment aider à avoir du code propre, bien découplé et testable. Il existe de nombreuses bibliothèques d'injection de dépendances (DI), comme Autofac, Lamar (le successeur de StructureMap), ou encore Castle Windsor, mais ces dernières années j'utilise surtout celle fournie par Microsoft avec .NET Core : Microsoft.Extensions.DependencyInjection. C'est loin d'être la plus complète (en fait elle est même assez minimaliste), mais elle suffit généralement à mes besoins.

Dans une SPA (Single Page Application), il est souvent nécessaire de vérifier 2 fois la donnée :

Bonjour !

Dans une SPA (Single Page Application), il est souvent nécessaire de vérifier 2 fois la donnée :

Lorsque l'on écrit du code susceptible d'être utilisé sur plusieurs projets, on aime bien faire des packages nuget pour pouvoir le réinjecter un peu partout et ne le maintenir qu'une seule fois. Souvent, on référence un autre projet de notre solution via la balise ProjetReference dans notre fichier csproj et on s'attend à ce que le projet référencé soit également présent dans le package nuget généré. Que nenni : il faudra lui aussi l'exposer sous la forme d'un package Nuget.

Dans les précédents articles de cette série, nous avons vu comment utiliser les access keys et comment utiliser Azure Active Directory pour sécuriser l'accès à vos Azure Functions. Dans cet article, nous verrons comment mettre en place une sécurité par login / mot de passe.