La casa del .NET

Mise à l'échelle d'une application ASP.NET Core SignalR

Fri, 17 Feb 2023 18:00:00 GMT

ASP.NET Core SignalR, ou juste "SignalR" pour les intimes, est une bibliothèque pour ASP.NET Core qui va permettre d'ajouter des fonctionnalités temps-réel à vos applications.
Vous pourrez par exemple créer envoyer des notifications en temps réel à vos utilisateurs, ou créer des jeux multijoueurs.

Le but de cet article n'est pas de parler de la technologie elle-même, mais de la façon de gérer sa mise à l'échelle.
Si vous ne connaissez pas déjà SignalR, je vous invite à aller la découvrir dans sa documentation officielle.

Mise à l'échelle

Lorsqu'on utilise SignalR sur un seul serveur, tout fonctionne très bien puisque notre serveur garde en mémoire la liste des clients connectés, et va pouvoir envoyer des messages à chacun d'entre eux.
Mais si on veut gérer beaucoup de clients connectés, on risque d'arriver aux limites de notre serveur (en mémoire utilisée, ou en nombre de connexions ouvertes simultanées).

Si on peut bien sûr passer sur un serveur plus puissant, on envisagera aussi la possibilité de lancer plusieurs serveurs derrière un load-balancer. C'est bien sûr possible, mais il va nous falloir un peu de configuration pour que ça fonctionne.

Connexion du client au serveur

Si on déploie notre serveur SignalR sur un 2ème serveur avec un load-balancer, on va directement avoir des soucis, puisque les clients auront des erreurs à l'ouverture de la connexion.

Ceci est du au fait que SignalR va pouvoir gérer plusieurs transports : un premier appel est faite pour négocier le meilleur transport (WebSocket si le client le supporte, sinon Server-Sent Events ou Long-Polling), puis un second qui ouvre la vraie connexion.
Entre ces deux appels, les informations restent en mémoire sur le serveur, et donc si le client ne se connecte pas à la même instance, la connexion échoue.

Pour remédier à ce problème, nous avons 3 possibilités :

Affinité de session
Ceci est à configurer au niveau du load-balacer. Chaque client sera lié à l'un de vos serveurs, et ses appels arriveront toujours sur le même.

Forcer l'usage de websocket
Si vous êtes sûr que les clients supportent WebSocket, alors vous pouvez oublier l'étape de négociation, et forcer la connexion en SignalR.
Ainsi, plus besoin d'affinité de session, vu qu'il n'y a qu'une requête - elle fonctionnera quel que soit le serveur qui la traitera.

En Javascript, on modifiera la connexion de la manière suivante :

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/appHub", {
        skipNegotiation: true,
        transport: signalR.HttpTransportType.WebSockets
    })
    .build();

Utiliser Azure SignalR Service
Si vous hébergez votre application dans le Cloud Azure, vous pouvez utiliser le service dédié Azure SignalR Service. Ce service sert de proxy entre les clients et les serveurs, et va gérer ces problématiques de connexion pour vous.

graph BT

    subgraph Serveurs
        web1[Web]
        web2[Web]
        azsignalr(Azure SignalR)
        azsignalr<-->web1
        azsignalr<-->web2
    end

    clientA(Client A)
    clientB(Client B)
    clientC(Client C)

    clientA<--ws-->azsignalr
    clientB<--ws-->azsignalr
    clientC<--ws-->azsignalr

Pour configurer SignalR avec Redis, il faut référencer le package Nuget Microsoft.Azure.SignalR, et appeler la méthode suivante lors de la configuation de SignalR :

services.AddSignalR().AddAzureSignalR(azureSignalrConnectionString);

Communication entre clients sur instances différentes

Maintenant qu'on a résolu notre problème de connexion, il reste un problème à régler.
Les clients sont bien connectés, mais chacun de nos serveurs n'a connaissance que d'une partie des clients, il n'est pas possible d'envoyer des messages à un client connecté sur un autre serveur.

Si on veut envoyer un message à tous les clients connectés, il va nous falloir trouver une solution. La documentation d'ASP.NET nous en propose deux.

Avec Azure SignalR Service

Si vous avez déjà choisi cette option dans la première partie, rien de plus à faire :
tous les clients sont bien connectés au même service Azure, tout est géré de manière transparente pour vous.

Avec Redis

L'autre solution est d'utiliser un backplane Redis. Cette fois, on n'a pas un proxy qui gère les connexions, mais Redis et ses fonctionnalités PUB/SUB permet aux serveurs de communiquer entre eux.

graph BT 

    subgraph Serveurs
        web1[Web]
        web2[Web]
        redis[Redis]
        web1<-->redis        
        web2<-->redis
    end

    clientA(Client A)
    clientB(Client B)
    clientC(Client C)

    clientA<--ws-->web1
    clientB<--ws-->web2
    clientC<--ws-->web2

Si l'un de vos serveurs veut envoyer un message, ça se passe en 3 temps :

Il envoie le message au serveur Redis, avec le message et les clients visés
Tous les serveurs (dont l'émetteur du message) reçoivent une notification du serveur Redis
Chacun des serveurs envoie le message aux clients qu'il connait

Pour configurer SignalR avec Redis, il faut référencer le package Nuget Microsoft.AspNetCore.SignalR.StackExchangeRedis, et appeler la méthode suivante lors de la configuation de SignalR :

services.AddSignalR().AddStackExchangeRedis(redisConnectionString);

Multi application

Si vous avez plusieurs applications SignalR, il est possible de les configurer pour qu'elles utilisent le même serveur Redis, mais avec des canaux différents pour éviter qu'elles ne se marchent dessus :

services.AddSignalR()
    .AddStackExchangeRedis(connectionString, options => {
        options.Configuration.ChannelPrefix = "App1";
    });

graph BT
    
    redis(Redis)

    subgraph Application web
        web1[Web]
        web2[Web]
    end
    subgraph API mobile
        api1[API]
        api2[API]
    end

    web1<--channel_web-->redis
    web2<--channel_web-->redis
    api1<--channel_api-->redis
    api2<--channel_api-->redis
    navigateur1<--ws-->web1
    navigateur2<--ws-->web2
    navigateur3<--ws-->web2
    mobile1<--ws-->api1
    mobile2<--ws-->api2
    mobile3<--ws-->api2

Mais ce à quoi on ne pense pas forcément, c'est qu'on peut vouloir que ces deux applications utilisent les mêmes canaux.
Imaginons que dans notre exemple, on veuille qu'une action d'un utilisateur mobile envoie des notifications vers des utilisateurs du site web, en mettant le même ChannelPrefix (ou en laissant la valeur vide), les deux applications pourront communiquer sans problème

Le cas particulier de Blazor Server

Blazor permet de développer des applications web dynamiques, en utilisant uniquement C# et razor.
Il existe deux modes de déploiement : Webassembly, où le code est exécuté dans le navigateur, et Blazor Server, où le code est exécuté sur le serveur, et la communication avec le client se fait via une connexion SignalR.

Et donc si on utilise Blazor Server, on risque de se retrouver avec les mêmes problèmes pour gérer la mise à l'échelle de la connexion SignalR. Mais Blazor arrive avec ses spécificités dont nous allons devoir tenir compte :

Concernant le premier problème de connexion, Blazor va lui aussi nécessiter un premier appel, avant d'initialiser la connexion SignalR. Ce premier appel initialise l'état du composant, et on ne pourra pas y couper, cette fois l'affinité de session est obligatoire dans tous les cas.

Si vous utilisez Azure SignalR Service, il faudra aussi configurer cette affinité auprès entre le serveur et le service :

builder.Services.AddServerSideBlazor().AddAzureSignalR(options =>
{
    options.ServerStickyMode = Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

Le deuxième problème ici n'en est finalement pas un : Blazor utilise la connexion SignalR pour avoir échanger entre le client et le serveur, mais les clients sur différentes instances n'ont pas forcément besoin d'échanger des messages. Dans ce cas, le backplane Redis n'est pas nécessaire.

Si vous souhaitez plus d'informations sur le déploiement d'une application Blazor Serveur, je vous renvoie vers la documentation dédiée.

Calculer un itinéraire grâce à Itinero et aux données OpenStreetMap

Wed, 30 Nov 2022 15:00:00 GMT

Maintenant que nous savons afficher des cartes, on va essayer d'aller un peu plus loin ; aujourd'hui, nous allons calculer et afficher un itinéraire entre 2 points.

Le serveur de carte que nous avons installé précédemment ne va pas pouvoir nous aider, nous allons devoir utiliser un autre service pour ça. Il en existe plusieurs, j'ai décidé d'utiliser Itinero, qui est une librairie .NET, et qui propose aussi une api déployable directement.

Vous pouvez lire la documentation complète d'Itinero pour entrer plus en détail dans le sujet.

Création du fichier RouteDb

Nous avons déjà du effectuer une conversion des données OpenStreetMap vers un format vectoriel, le principe ici est le même, puisqu'Itinero ne va pas travailler non plus sur les données brutes, mais sur des données ne contenant que le nécessaires pour calculer un itinéraire (uniquement les routes, inutiles de s'encombrer des batiments ou des cours d'eau).

Les données OpenStreetMap peuvent toujours être récupérées par région depuis le site Geofabrik, et ensuite Itinero Data Processor permets d'effectuer la conversion en ligne de commande.

Tout ce que permets IDP est faisable par code grâce à un packge Nuget, et c'est ce que j'ai choisi de faire, afin d'automatiser complètement la récupération des données OSM, la conversion, et l'envoi du résultat vers un stockage cloud.

Pour cela, j'ai créé une application console, dans laquelle j'ai référencé les packages Nuget Itinero et Itinero.IO.Osm.
Puis quelques lignes de code pour récupérer les données de Midi-Pyrénées, les convertir, et sauvegarder le résultat.

var routerDb = new RouterDb();
var client = new HttpClient();

var url = "http://download.geofabrik.de/europe/france/midi-pyrenees-latest.osm.pbf";
using (var response = await client.GetAsync(url))
{
    routerDb.LoadOsmData(response.Content.ReadAsStream(), Vehicle.Car, Vehicle.Bicycle);
}

using (var stream = new FileInfo(@"midi-pyrenees.routerdb").Open(FileMode.Create))
{
    routerDb.Serialize(stream);
}

Deux choses importantes à voir dans ce code :

routerDb.LoadOsmData : cette méthode lis le fichier OpenStreetMap, et récupère les informations nécessaires au calcul d'itinéraire.
Une liste de Vehicle est passé en paramètre, car selon le type d'itinéraire qu'on veut calculer, les données à utiliser ne seront pas les mêmes.
routerDb.Serialize : cette méthode permets d'enregistrer nos données dans un fichier RouterDb, ensuite nous n'utiliserons que ce fichier pour tous nos calculs d'itinéraires.

On a une liste de profils de véhicules prédéfinis (voiture, vélo, piéton ou camion…), et on peut définir d'autres profils personnalisés.

Vous pouvez lancer cette application, et la laisser tourner quelques minutes, ça sera plus ou moins long selon la taille de la zone à convertir, et le nombre de profils de véhicules que vous souhaitez gérer.

Calcul d'un itinéraire

Maintenant qu'on a un RouterDb, on va pouvoir l'utiliser pour calculer nos itinéraires.

On commence par charger les données depuis le fichier, puis on crée un Router utilisant ces données

RouterDb routerDb;
await using (Stream routerDbFile = await container.GetFile("midi-pyrenees.routerdb"))
{
    routerDb = RouterDb.Deserialize(routerDbFile);
}

var router = new Router(routerDb);

Il nous faut ensuite créer un Profile : avec quel type de véhicule on souhaite calculer l'itinéraire, et si on veut le plus rapide ou le plus court.

Là aussi, je reste sur les profils prédéfinis :

var profile = Vehicle.Car.Fastest();            // Trajet le plus rapide en voiture
var profile2 = Vehicle.SmallTruck.Shortest();   // Trajet le plus court en camionnette

Puis on choisit le point de départ et d'arrivée avec leurs coordonnées GPS, et on peut calculer l'itinéraire

var start = router.Resolve(profile, 43.60442f, 1.44403f);
var end = router.Resolve(profile, 43.23370f, 1.57595f);

var route = router.Calculate(profile, start, end);

L'objet Route contient toutes les informations qui nous intéressent, notamment :

Shape et ShapeMeta : les coordonnées de tous les points représentant la route, et les métadonnées associées
TotalDistance et TotalTime : la distance totale et la durée estimée du trajet

Ces informations suffisent maintenant à connaitre toutes les informations du trajet. Pour le dessiner sur une carte, on peut par exemple dessiner un trait entre chaque point du tableau Shape.

Cependant, plutôt que de faire ça manuellement, on préfèrera certainement utiliser le format GeoJson pour envoyer les données à une librairie compatible. Il suffit d'appeler la méthode ToGeoJson()

// Envoi du résultat depuis une API ASP.NET
return Ok(route.ToGeoJson());

Il suffit ensuite de récupérer les données en JavaScript et de les passer à la librairie MapLibre pour pouvoir l'afficher :

// On fait un appel à l'API pour recevoir les informations de l'itinéraire
const response = await fetch('/Itineraire');
const data = await response.json();

const map = initMap(); // voir les articles précédents pour l'initialisation de la carte

// On crée une source de données avec les informations geojson reçues
map.addSource('route', {
    type: 'geojson',
    data: data
});

// On affiche les données de la source avec l'id "route"
map.addLayer({
    'id': 'route',
    'type': 'line',
    'source': 'route',
    'layout': {
        'line-join': 'round',
        'line-cap': 'round'
    },
    'paint': {
        'line-color': '#888',
        'line-width': 8
    }
});

Démonstration

Voilà donc le résultat : j'ai repris l'affichage de la carte existant, et on peut afficher par dessus le trajet entre Toulouse et Saverdun.

Partager ses clés OpenPGP et trouver celles de vos correspondants

Mon, 14 Nov 2022 12:00:00 GMT

OpenPGP est un format de cryptographie utilisé pour le chiffrement des e-mails de bout en bout.
Le chiffrement avec OpenPGP est géré nativement par Thunderbird, et fonctionne avec n'importe quelle adresse e-mail. Des services comme Proton vous proposent un usage simplifié en embarquant directement son usage dans leur webmail.
Vous pouvez trouver une liste de logiciels compatibles sur le site OpenPGP.org

Le chiffrement repose sur une paire de clés (publique et privée) associée à chaque adresse e-mail : lorsque vous écrivez à quelqu'un, vous utilisez sa clé publique pour chiffrer le message, le destinataire utilisera sa clé privée pour le déchiffrer et lire son contenu.

S'il est bien sûr possible de partager sa clé publique en la donnant en main propre à ses correspondants, ce n'est pas forcément le plus pratique ; la question se pose ainsi de savoir comment partager sa clé publique par internet de manière sécurisée.

Partager sur un serveur de clés

Historiquement, on partageait ses clés sur un réseau de serveurs de clés décentralisés. Cette approche a trouvé ses limites, et aujourd'hui plusieurs projets OpenPGP se sont rassemblés pour créer et utiliser un serveur de clés principal de confiance : https://keys.openpgp.org/.

Ceci ne vous empêche en rien d'utiliser d'autres serveurs, mais en envoyant vos clés sur celui-là, votre adresse e-mail sera vérifiée (empêchant quiconque de fournir une fausse clé pour votre adresse), et les utilisateurs qui auront ce serveur configuré trouveront votre clé plus facilement.

Pour envoyer votre clé, allez sur la page "gérer votre clé" et entrez votre adresse e-mail. Vous allez recevoir un message avec un lien vous permettant d'envoyer vos clés ou de les supprimer du serveur.

Lorsque la clé est sur un serveur, elle est trouvable par l'API :
https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=test@lacasa.fr

Il est bien sûr toujours possible d'héberger son propre serveur de clés, et ça peut être pertinent si vous êtes en position d'autorité de confiance pour un grand nombre de clés. C'est par exemple ce qu'a fait Protonmail pour distribuer les clés de tous ses utilisateurs.

Cependant, il faut que les utilisateurs enregistrent manuellement votre serveur de clés dans leurs logiciels pour pouvoir en profiter, vous aurez probablement du mal à convaincre beaucoup de monde de le faire. C'est pour ça que nous avons un autre système de partage de clés : WKD

Partager directement avec Web Key Directory

Plutôt que de passer par un serveur externe en qui il faut avoir confiance, il est possible d'héberger ses propres clés.
L'idée est simple : si une adresse e-mail est en '@lacasa.fr', on doit pouvoir faire confiance au site web https://lacasa.fr pour fournir sa clé publique.

N'importe quel hébergement statique sera capable de fournir les clés, puisqu'il suffit de créer une arborescence et de donner le bon nom aux fichiers

https://[domaine]/.well-known/openpgpkey/hu/[Hashed-UserId]?l=[UserId]

Le nom du fichier est un hash du userId. Ainsi, pour l'adresse e-mail test@lacasa.fr, le hash de test est iffe93qcsgp4c8ncbb378rxjo6cn9q6u

La clé de cette adresse e-mail peut donc être publiée à cette adresse :
https://lacasa.fr/.well-known/openpgpkey/hu/iffe93qcsgp4c8ncbb378rxjo6cn9q6u?l=test

Certains serveurs WKD ont besoin d'avoir le userId passé en clair, on l'ajoute donc le paramètre si besoin : l=test

Il existe un mode avancé pour proposer ses clés, quand pour des raisons pratiques on ne peut pas ou on ne souhaite pas héberger ses clés directement sous le domaine racine.
Ce mode avancé permets aussi de centraliser l'hébergement des clés de plusieurs domaines sur un seul serveur.

Pour ça, il faut créer un sous-domaine openpgpkey au domaine de l'adresse e-mail, et ajouter aussi un dossier avec le nom du domaine dans le dossier .well-known/openpgpkey

https://openpgpkey.[domaine]/.well-known/openpgpkey/[domaine]/hu/[Hashed-Userid]?l=[UserId]

La clé de mon adresse e-mail est donc aussi accessible à cette adresse :
https://openpgpkey.lacasa.fr/.well-known/openpgpkey/lacasa.fr/hu/iffe93qcsgp4c8ncbb378rxjo6cn9q6u?l=test

Ainsi on peut héberger les clés en dehors de son site web principal, et héberger plusieurs domaines sur le même serveur en faisant pointer les différents sous-domaine sur ce site web avec un CNAME.

Le serveur de clés keys.openpgp.org propose ainsi un service WKD utilisable avec votre propre domaine :
Créez le CNAME qui pointe vers wkd.keys.openpgp.org, et vos clés déjà hébergées sur leur serveur deviennent accessible en WKD sur votre propre domaine.

.NET et les clés OpenPGP

Si je me suis plongé dans le partage de clés OpenPGP, c'était aussi pour pouvoir chiffrer des e-mails envoyés depuis mes applications métier. J'ai donc fait une librairie .NET standard Pericia.OpenPgp pour retrouver facilement des clés sur un serveur de clés ou par WKD, que vous pouvez ensuite utiliser avec BoucyCastle.

var key1 = openPgpSearch.SearchWebKeyDirectory(mailAddress);
var key2 = openPgpSearch.SearchHttpKeyServer(mailAddress);

Cette librairie propose aussi une extension à ASP.NET pour distribuer vos clés via WKD (aussi bien en mode direct qu'en mode avancé). Il vous suffit de mettre vos clés publiques dans un dossier, et elles seront distribuées automatiquement.

// Configure services
var keyDirectory = builder.Environment.ContentRootFileProvider.GetDirectoryContents("Keys");
builder.Services.AddWebKeyDirectory(keyDirectory);

// Configure app
app.UseWebKeyDirectory();

Générer ses propres tuiles vectorielles à partir des données OpenStreetMap

Sat, 23 Apr 2022 12:00:00 GMT

Dans l'article précédent je vous ai montré comment il était possible d'héberger son propre serveur de carte, et donc de ne plus être dépendant de services externes pour afficher des cartes sur un site web. À un détail près, puisque même si on peut être autonome avec le serveur, il fallait quand même passer par un service payant pour pouvoir récupérer et mettre à jour les données cartographiques. Nous allons voir maintenant comment faire ça nous même.

Pourquoi les données cartographiques sont-elles payantes ?

On peut légitimement se poser cette question : puisque les données cartographiques viennent d'OpenStreetMap, leur usage est censé être libre - dans ce cas, pourquoi le téléchargement des données pour le serveur de tuile est-il payant ?

La réponse est toute simple : parce que les données OpenStreetMap ne peuvent pas être utilisées directement, et nécessitent donc une phase de conversion.

Il est tout à fait possible d'héberger une copie du site OpenStreetMap, avec son serveur de tuiles «images», et donc d'utiliser directement les données existantes. J'ai déjà mentionné le site Switch2OSM si le sujet vous intéresse.

Mais le rendu de ces tuiles images se fait vieillot, et je préfère proposer un affichage vectoriel, qui n'a que des avantages, maintenant que c'est supporté correctement sur tous les appareils un peu récents : format plus léger, zooms et déplacements plus fluides.

Nous allons donc voir comment effectuer la conversion des données natives OpenStreetMap vers un format vectoriel.

Le format OpenMapTiles

Les équipes de MapTiler, le service qui propose de télécharger les données cartographiques, sont à l'origine du format de tuiles verctorielles OpenMapTiles, distribué sous licence libre et gratuit à utiliser.
C'est ce format que j'ai utilisé dans mes articles précédent lorsque je parlais de tuiles vectorielles.

Étant donné que le format est libre, nous avons donc pu avoir différentes initiatives pour proposer des serveurs compatibles, ainsi que des projets pour convertir les données OpenStreetMap vers ce format. Nous pouvons citer en vrac (liste non exhaustive) : Openmaptiles-tools, Tilerator, Tilemaker, ou Planetiler

C'est ce dernier projet que j'ai décidé d'utiliser et que je vais vous présenter

Génération d'un fichier mbtiles avec Planetiler

Après avoir essayé différents outils pour générer mes données cartographiques vectorielles, j'ai décidé d'utiliser Planetiler car il est le plus simple à utiliser : il suffit d'une ligne de commande pour obtenir un fichier de mbtiles, qu'il ne nous reste plus qu'à envoyer sur notre serveur.

Tout d'abord, il faut savoir quelle zone on veut convertir. Vous pouvez vous contenter d'une région ou d'un pays, mais si vous souhaitez la planète entière il vous faudra beaucoup de mémoire RAM, et quelques heures à attendre.

Les données par région sont fournies par le site Geofabrik, et seront téléchargées automatiquement par l'outil. De mon côté, je me contente de la carte de France (métropole + corse)

Pour lancer la conversion, 2 options.

Utilisation de l'outil Java :

wget https://github.com/onthegomap/planetiler/releases/latest/download/planetiler.jar
java -Xmx32g -jar planetiler.jar --download --area=france

Avec l'image Docker:

docker run -e JAVA_TOOL_OPTIONS="-Xmx32g" -v C:\data:/data ghcr.io/onthegomap/planetiler:latest --download --area=france

Ces lignes de commande viennent du REAMDE de l'outil, que j'ai très légèrement adaptées :

l'option Java -Xmx32g représente la mémoire utilisable par l'outil. Elle est limitée à 1Go dans leur exemple, suffisant pour la principauté de Monaco, mais limite pour la France
et j'ai remplacé la variable shell $(pwd) par un chemin en dur, car je le fait tourner sous Windows et que la syntaxe Powershell n'est pas exactement la même (j'avoue que je n'ai pas cherché comment l'écrire plus proprement)

Après trois quarts d'heure à mouliner sur mon PC, j'ai enfin obtenu ma carte, qu'on peut maintenant mettre sur un serveur de tuiles.

Si vous souhaitez convertir la planète entière, il vous faudra idéalement plus de 100Go de RAM, et de nombreux cœurs dans votre processeur. Vous pouvez lire une documentation spécifique dans laquelle je ne rentrerai pas en détail.
Personnellement, je n'ai même pas essayé de lancer ça sur mon PC, il faudra certainement préférer utiliser des machines virtuelles cloud pour ça. Pour exemple, la conversion complète de la planète a été effectuée en un peu plus de 3h sur une machine avec 16 cœurs et 128Go de ram.

Avec ce 3ème article, vous avez maintenant tout le nécessaire pour héberger vos cartes et les mettre à jour régulièrement, et j'espère vous avoir convaincu de le faire !

Héberger son serveur de cartes OpenStreetMap

Mon, 04 Apr 2022 14:00:00 GMT

Dans un précédent article, j'ai montré comment on pouvait afficher des cartes grâce aux données d'OpenStreetMap. Mais même si ça a l'avantage indéniable de permettre de se passer de Google, on doit toujours passer par un service externe.
Nous allons voir maintenant comment nous pouvons héberger nous-même nos cartes, afin de supprimer cette dépendance.

Démarrage du serveur de cartes

Il existe plusieurs façon d'héberger nos cartes. Vous pouvez déployer un clone du site OpenStreetMap lui même, en suivant cet article de Switch2OSM.

De mon côté, je préfère avoir un rendu vectoriel de mes cartes, j'ai donc préféré utiliser un serveur TileServer GL - qui a de plus l'avantage de pouvoir être déployé très simplement, grâce à une image Docker.
D'autres logiciels serveurs existent, une liste est disponible sur le wiki d'Openstreetmap

Ouvrez un terminal Powershell, aller dans un dossier vide (dans lequel les données de cartographie seront stockées), et tapez la commande suivante :

docker run --rm -it -v ($pwd.Path+":/data") -p 8080:80 maptiler/tileserver-gl

Le serveur démarre, et vous pouvez y accéder directement sur http://localhost:8080

Pour le moment, nous n'avons pas récupérées les données cartographiques d'OpenStreetMap, le serveur a donc du télécharger des données d'exemple. Si vous jetez un œil dans le répertoire de travail, il devrait donc y avoir un fichier zurich_switzerland.mbtiles, qui vous permets de visualiser la carte de la ville de Zurich.

Déploiement dans Azure

Pour mettre ça en ligne, j'ai créé un App Service sur Azure, dans lequel j'ai déployé l'image Docker.
Vous pouvez bien sûr déployer ça où vous voulez, tant que vous avez accès à du Docker ou du NodeJS. Je vous laisse vous adapter, l'important est de pouvoir écrire dans le répertoire data.

Pour que ça puisse démarrer, j'ai du modifier quelques options dans la configuration de l'App Service :

L'application démarre en interne sur le port 80, ce qui est bloqué pour raisons de sécurité. On va démarrer à la place sur le port 8080, en ajoutant en "commande de démarage" : -p 8080.
Il faut aussi ajouter une variable d'environnement WEBSITES_PORT, avec la valeur 8080, pour qu'Azure sache où chercher notre site.
- UPDATE (29 novembre 2022) : dans la dernière version de tileserver-gl, le port utilisé est maintenant 8080 par défaut
On va aussi avoir besoin d'un endroit pour stocker le fichier mbtiles. Commencez par créer un compte de stockage, et à l'intérieur ajouter un nouveau Partage de fichier.
Revenez ensuite dans la Configuration de l'App Service, et dans Mappages de chemin d'accès, ajoutez le Partage de fichier que vous venez de créer, avec le chemin de montage /data
Et tant que vous êtes dans l'interface, pous pouvez aller dans la section CORS pour définir les domaines autorisés à utiliser votre serveur de carte

Téléchargement des données

En effet, maintenant que votre serveur tourne, il faut ajouter les données des cartes. Le format utilisé ici, avec les fichiers mbtiles, n'est pas le format natif d'OpenStreetMap. Vous pouvez télécharger les données converties sur le site d'OpenMapTiles.

Il s'agit d'un service payant qui fournit les données avec des mises à jour hebdomadaires, mais vous pouvez récupérer des données gratuitement pour des projets non-commerciaux/open-source, ou pour vos tests. Si vous ne souhaitez pas vous inscrire, vous pouvez télécharger directement la carte de Toulouse.

Mettez ce fichier .mbtiles dans le répertoire /data, et redémarrez : maintenant le serveur est prêt, et devrait afficher votre carte.

Sélection d'un style

Nous avons pu démarrer notre serveur, qui nous permets déjà d'afficher une carte, avec un style par défaut "Basic preview". Sur la page d'accueil, vous pouvez voir un lien noté "GL Styles", qui pointe vers un fichier Json. Si vous vous souvenez de l'article précédent, c'est ce fichier là qui est référencé lors de l'initialisation de la carte avec la librairie Mapbox GL. Vous pouvez utiliser directement ce style, mais on peut aussi en ajouter d'autres.

Nous n'allons pas rentrer dans les détails de la définition du style, nous allons nous pour le moment prendre l'un des styles existant proposés par OpenMapTiles. Histoire de changer un peu de ce dont on a l'habitude, j'ai choisi le style Positron, vous pouvez télécharger sa branche gh-pages sur Github.

Une fois téléchargé, il va falloir le modifier un peu avant qu'il ne soit utilisable.

Première chose, prenez le fichier style-local.json, et cherchez les lignes suivantes :

"openmaptiles": {
  "type": "vector",
  "url": "mbtiles://{v3}"
}

Ici l'url correspond au fichier de données associé. Il faut la remplacer par le nom de notre fichier, mettez donc "url": "mbtiles://2017-07-03_france_toulouse.mbtiles"

Ensuite, il faut installer les polices utilisées pour l'affichage des textes sur la carte. Vous pouvez récupérer les fonts sur Github.

Maintenant que vous avez récupéré tout ce dont vous avez besoin, uploadez tout ça dans le dossier /data de votre serveur, les fonts dans un sous-dosser fonts, et tout les fichiers du style dans son sous-dossier styles/positron-gl.

Dernier point, on va devoir ajouter un fichier de configuration pour faire connaitre toutes ces informations à tileserver. Créez un fichier config.json avec le contenu suivant :

{
  "options": {
    "paths": {
      "root": "",
      "fonts": "fonts",
      "styles": "styles",
      "mbtiles": ""
    }
  },
  "styles": {
    "positron-gl": {
      "style": "positron-gl/style-local.json",
      "serve_rendered":false
    }
  },
  "data": {
    "toulouse": {
      "mbtiles": "2017-07-03_france_toulouse.mbtiles"
    }
  }
}

Ajoutez ce fichier dans /data et redémarrer une nouvelle fois le serveur. Cette fois on est bon, vous pouvez récupérer l'url du fichier "GL Style" et l'utiliser pour afficher vos cartes.

Si vous souhaitez aller plus vite dans l'installation de différents styles sur le serveur, j'ai partagé sur Github une configuration avec les différents styles et les fonts ; vous pouvez copier les fichiers directement dans votre répertoire /data, il vous faudra juste mettre à jour le fichier mbtiles et ses références.

Installer une instance Matomo pour remplacer Google Analytics

Fri, 11 Feb 2022 14:00:00 GMT

Une décision de la CNIL a fait grand bruit hier dans les communautés d'informaticiens, puisqu'elle estime maintenant que l'utilisation de Google Analytics est illégale en Europe. En effet, lorsque un site web intègre ce service, Google récupère et analyse les données personnelles des visiteurs, sans aucun respect pour le RGPD.

Cette décision me donne l'occasion de reparler d'un sujet qui me tient à cœur : l'utilisation de services décentralisés et respectueux des utilisateurs.
La CNIL propose plusieurs solutions de mesure d'audience, je vous propose aujourd'hui de voir comment installer et configurer l'une d'entre elles : Matomo.

Installation de Matomo

Matomo est un outil de mesure d'audience open-source. Si vous ne souhaitez pas vous embêter avec la partie technique, vous pouvez directement vous inscrire sur le service Matomo Cloud, et passer directement à la partie "Conformité RGPD" plus bas.

De mon côté, je préfère utiliser la version on-premise, nous allons donc voir ça ensemble.
Pour installer Matomo, il faut un hébergement PHP avec une base de données MySQL. Si vous n'avez pas déjà ça sous la main, un hébergement de ce type commence à 2,99€ HT par mois chez OVH.

Commencez par télécharger Matomo, et vous aurez un fichier zip qu'il vous suffira de décompresser et d'envoyer par FTP sur votre hébergement.

Il vous suffit ensuite d'aller sur le site, et suivre les différentes étapes pour configurer l'accès à la base de données et ajouter votre premier site. Je ne vais pas rentrer dans les détails ici, il n'y a rien de compliqué - la documentation d'installation se trouve par là.

Configuration dans Clever Cloud

Update: Si vous souhaitez déployer Matomo dans Clever Cloud, c'est maintenant géré nativement. Choisissez simplement l'add-on Matomo Analytics et laissez vous guider.

Comme pour mon blog, j'ai décidé d'installer mon instance chez Clever Cloud, et nous allons vois ensemble comment optimiser notre déploiement sur ce cloud.

On va profiter de la configuration automatique de la base de données par des variables d'environnement. Pour ce faire, récupérer ce plugin EnvironmentVariablesCleverCloud, et dézippez son contenu dans le dossier /plugins de votre installation Matomo. Puis depuis l'interface d'administration, allez dans "Système" -> "Composants" pour l'activer.
Dès que c'est fait, Matomo récupèrera sa configuration MySQL directement depuis l'environnement Clever Cloud, ce qui sera utile si vous souhaitez plus tard prendre une instance plus grande.

Dernier point : le nombre de connexion simultanées à la base de données est limité, et si vous avez plusieurs utilisateurs en même temps, vous aurez des erreurs. Pour éviter ça, on va activer ProxySQL, qui va gérer un pool de connexions à la base de données, et s'assurer de ne pas dépasser les limites. Il suffit d'ajouter 2 variables d'environnement :

CC_ENABLE_MYSQL_PROXYSQL=true
CC_MYSQL_PROXYSQL_MAX_CONNECTIONS=10

La première pour activer ProxySQL, la seconde pour définir le nombre de connection maximum à ouvrir : mettez la valeur maximale autorisée par l'instance MySQL que vous avez choisie (ou un peu moins si vous souhaitez vous connecter directement à la base).

Conformité RGPD

Le fait d'utiliser Matomo ne suffit pas à lui seul à respecter le RGPD. Par contre, configuré correctement, vous pourrez l'ajouter à vos sites web sans avoir besoin d'ajouter un de ces horribles bandeau de consentement.

La CNIL décrit en détail comment faire dans son Guide de configuration Matomo Analytics, que je vous conseille de lire ; nous allons voir rapidement les principaux points ensemble :

Désactiver les exports de données :
dans l'administration, section "Système" -> "Paramètres généraux", cochez la cas «Désactiver le journal des visites et le profil du visiteur»
Proposer un opt-out :
il faut permettre aux visiteur de refuser le tracking, en ajoutant une iframe vers une url spéciale de Matomo :
https://stats.monsite.com/index.php?module=CoreAdminHome&action=optOut

Le document de la CNIL propose aussi plusieurs points à vérifier, si vous n'avez pas touché aux paramètres par défaut de Matomo, ils sont déjà préconfigurés correctement.

Une fois que vous avez fait tout ça, il ne vous reste plus qu'à supprimer les scripts de Google Analytics, et vous pourrez enfin dire fièrement à vos utilisateurs que le respect de leur vie privée est une priorité.
Profitez-en aussi pour vérifier les autres dépendances à des services externes que vous pourriez avoir sur votre site. L'extension Kimetrak pour navigateurs peut vous aider à faire le point.
Je pense notamment à des Google Fonts que vous pourriez héberger sur vos serveurs plutôt que de pointer directement sur ceux de Google. Vous pouvez aussi remplacer l'affichage des cartes Google Maps par celles d'OpenStreetMap.

J'ai déployé des apps chez Clever Cloud

Mon, 01 Nov 2021 14:00:00 GMT

J'ai découvert il y a peu le service d'hébergement cloud français Clever Cloud, quelques jours après avoir lu l'article de Guillaume Champeau sur la souveraineté numérique.

J'ai eu l'occasion de déployer des projets professionnels sur Microsoft Azure, Amazon AWS, ainsi que sur du Windows Server. Mon blog était hébergé sur Azure car je voulais un service managé : je ne veux pas perdre de temps à gérer le serveur ; et ça limite les options.

Donc en voyant un service français qui promettait un déploiement facile de mes applis .NET, je me suis empressé de tester.

Voici mes quelques petits retours, à l'usage des développeurs .NET

Le service

Le principe est simple : Clever Cloud nous fournit des machines virtuelles pour héberger nos applications. On pousse notre code, on configure nos nom de domaines, le type de VM et le nombre d'instances, et on les laisse gérer le reste.
La montée en charge est aussi gérée automatiquement, en définissant le nombre minimal est maximal d'instances, et la taille minimale et maximale de chaque VM.

Tout ça tourne sous Linux, comme vous vous en doutez sûrement, pas question donc de faire tourner des applications sous le vieux .NET Framework. Ici, uniquement du .NET Core ou .NET 5.

Ensuite, tout se configure à l'aide de variable d'environnement, autant les options de déploiement que les paramètres de notre application.

Déploiement d'une application

Le déploiement se fait directement depuis le dépôt Git de l'application. Pas question ici de pousser vos dll depuis Azure Devops Pipelines, c'est Clever Cloud qui fera le dotnet publish directement.

C'est assez déroutant pour quelqu'un comme moi qui aime bien customiser son déploiement, puisqu'il faut uniquement définir le dossier de l'application (avec la variable d'environnement' APP_FOLDER) et espérer que le dotnet publish fonctionnera bien.

Il est néanmoins possible de se brancher sur différents Hooks, pour exécuter des tâches avant ou après la compilation ; donc en théorie rien n'empêche de créer ses propres scripts pour faire tout ce dont on a besoin.

HTTPS

J'ai été surpris de ne pas trouver d'option pour activer HTTPS, mais en fait elle n'est pas nécessaire puisque tous les domaines ajoutés sont automatiquement protégés par Let's Encrypt.
Configurez le domaine dans la console Clever Cloud, faites pointer vos DNS, et attendez quelques minutes : c'est tout bon.

Il est aussi possible d'utiliser vos propres certificats si vous préférez, il faudra passer par l'API pour l'installer.

Les Addons

Étant donné qu'une application se limite rarement à du code qui s'exécute dans un container, nous avons ici ce qu'ils appellent des Addons : différent services managés à brancher à notre application : stockage de fichiers, bases de données, Redis ou Elastic Search.

Une fois lié à notre application, les informations de connexion sont automatiquement ajoutées en tant que variable d'environnement, pour pouvoir s'y connecter directement.

Stockage

Pour le stockage de fichier, le service proposé se nomme Cellar, et est compatible avec l'api de AWS S3. Il suffit donc d'utiliser le package Nuget AWSSDK.S3, pour s'y connecter de la manière suivante :

    private AmazonS3Client GetS3Client()
    {
        var host = "https://" + configuration["CELLAR_ADDON_HOST"];
        var s3config = new AmazonS3Config
        {
            ServiceURL = host
        };

        var accesskey = configuration["CELLAR_ADDON_KEY_ID"];
        var secretkey = configuration["CELLAR_ADDON_KEY_SECRET"];
        var credentials = new BasicAWSCredentials(accesskey, secretkey);

        var client = new AmazonS3Client(credentials, s3config);
        return client;
    }

Il est aussi possible de monter un dossier cloud en tant que dossier dans notre VM avec l'add-on File System Bucket. Mais à moins de vouloir déployer une application qui utilise déjà le file system, il est recommandé de préférer Cellar : moins cher, et mieux adapté à la montée en charge.

Bases de données

Concernant l'utilisation des bases de données, rien de compliqué : on ajoute l'addon, et on s'y connecte depuis notre application avec les identifiants générés.

Pour une base relationnelle, on a le choix entre MySQL et PostgreSQL. Pas de MS SQL Server ici, et ça sera certainement le plus gros frein à la migration d'applications .NET existantes, étant donné la popularité du serveur dans le monde du développement Microsoft.

Entity Framework Core est cependant parfaitement compatible avec ces deux SGBD, rien de bloquant donc si on démarre de nouveaux développements.

Nous avons aussi d'autres addons tels que MongoDB pour les amateurs de noSQL, ou Redis, qui sera vite indispensable si vous souhaitez par exemple utiliser SignalR dans vos applications cloud.

Conclusion

Après quelques jours d'utilisation sur mes projets personnels, j'adore le service. C'est moins poussé que d'autres services de cloud beaucoup plus connus, mais l'essentiel est là, et je pense qu'il ne manque pas grand chose pour déployer dessus de gros projets.
Si la migration de projets existant sera probablement compliquée dans de nombreux cas, les services de base et la possibilité de déployer des images Docker devrait permettre de faire à peu près tout ce dont on a besoin si on démarre un projet avec tout ça en tête.

Afficher une carte grâce aux données OpenStreetMap

Fri, 21 Aug 2020 12:00:00 GMT

Cette semaine est sorti le jeu Flight Simulator 2020, et certains joueurs se sont amusés de la présence d'un immense monolithe au nord de Melbourne.
Ce bug a pour origine une erreur dans le service cartographique OpenStreetMap (qui a entre-temps été corrigé), et cette anecdote m'a rappelé que ça faisait un moment que je voulais vous en parler.

OpenStreetMap, pour ceux qui ne connaissent pas, est ce qu'on pourrait appeler le « Wikipedia de la cartographie ». Il s'agit d'un service de cartographie libre, utlisable gratuitement, et pouvant être mis à jour par n'importe qui.
Vous pouvez donc tout à fait corriger la carte si vous voyez des erreurs dans votre voisinage, ou la compléter avec les noms de vos magasins préférés.

Je tiens un blog de développement web, donc je ne vais pas approfondir le sujet de la cartographie, bien que le sujet soit passionnant, mais nous allons plutôt voir comment nous pouvons utiliser les données d'OpenStreetMap pour afficher une carte sur nos applications web, à la place de Google Maps qui est un peu trop souvent utilisé sans se poser la question des alternatives.

Licence

Avant de commencer, on va voir rapidement la partie légale.

Les données brutes sont distribuées sous la licence libre Open Data Commons Open Database License (ODbL). Comme indiqué sur la page copyright d'OpenStreetMap, vous pouvez utiliser les données dans vos applications, à condition de créditer les contributeurs d'OpenStreetMap, et de redistribuer les données sous la même licence.
Lorsqu'on veut afficher la carte, on va utiliser les tuiles (les images des cartes, générées à partir des données brutes). Ces images sont sous licence Creative Commons CC-BY-SA 2.0 - les conditions d'utilisation sont globalement les mêmes que pour les données brutes : n'oubliez pas de mettre le copyright.

Affichage d'une carte avec Leaflet

Pour afficher une carte dynamique dans une page web, il va tout d'abord falloir choisir un serveur de tuile, le serveur qui nous fournira les fonds de carte.
La fondation OpenStreetMap n'a pas les moyens de financer des serveurs de tuiles utilisables librement par tout le monde, mais les données étant libres, de nombreux services proposent d'utiliser leurs serveurs - certains gratuitement pour des usages modérés, d'autres fournissant des services professionnels contre rémunération. Notez que vous pouvez aussi installer votre propre serveur de tuiles, si vous souhaitez être autonome.

Mon choix pour cet article s'est porté sur celui de l'association OpenStreetMap France.

On va maintenant utiliser une librairie JavaScript pour l'affichage. De nombreuses solutions existent, les plus utilisées sont OpenLayers et Leaflet ; j'utilise ce dernier dans cet exemple.

Pour afficher la carte, créer un div qui la contiendra, en lui précisant obligatoirement une taille.
Ensuite, vous pouvez initlialiser la carte, avec cet exemple de code :

<div id="mapDiv" style="width:800px; height: 400px;"></div>

<script>
    // Initialisation de la carte
    var map = L.map('mapDiv'); 

    // Initialisation des tuiles 
    var tileUrl = "https://a.tile.openstreetmap.fr/osmfr/{z}/{x}/{y}.png";
    var copyright = '&copy; Contributeurs de <a href="https://www.openstreetmap.org/">OpenStreetMap</a>';
    L.tileLayer(tileUrl, {
        attribution: copyright,
        maxZoom: 18,
        tileSize: 512,
        zoomOffset: -1,
    }).addTo(map);
    
    // On zoome sur Toulouse
    map.setView([43.60, 1.44], 10); 
</script>

Ce qui nous donne le résultat suivant :

Vous pouvez ensuite afficher toutes sorte d'informations sur la carte ou intéragir avec l'utilisateur ; je vous laisse jete un œil à la documentation pour ça.

Affichage vectoriel avec OpenMapTiles

Les données brutes étant libres, il est possible d'afficher les cartes autrement qu'en chargeant des images d'un serveur de tuiles. C'est ce que fait le projet OpenMapTiles, en proposant un système de tuiles vectorielles.
Au lieu d'afficher des images, c'est le navigateur qui dessine les objets de la carte ; permettant ainsi un affichage plus fluide et des plus d'interactions possibles (essayer de bouger avec le clic droit dans l'exemple plus bas). C'est le choix qu'a fait Qwant pour son service de cartographie Qwant Maps.

Ceci a malheureusement un coût, puisque le navigateur de l'utilisateur est plus fortement mis à contribution, et peut poser des problèmes de performances sur des ordinateurs peu puissants ou certains mobiles.

Pour afficher une carte vectorielle, j'utilise cette fois les serveurs de MapTiler, et la librairie Mapbox GL JS. OpenLayers et Leaflet ne gèrent pas l'affichage vectoriel nativement, mais peuvent fonctionner avec des plugins.

Pour afficher la carte, l'API est un peu différente, mais le système reste le même, je vous laisse regarder le code :

<div id="mapDiv" style="width:800px; height: 400px;"></div>

<script>
    var map = new mapboxgl.Map({
        container: 'mapDiv',
        style: 'https://api.maptiler.com/maps/bright/style.json?key=apikey',
        center: [1.44, 43.60],
        zoom: 10
    });
</script>

Vous pouvez ainsi voir le résultat - et voir la différence avec la carte précédente :

Vous noterez que même si l'affichage est différent, les cartes sont les mêmes. Les rues, les bâtiments ne changent pas de l'un à l'autre, car la source des données est la même.

J'espère que je vous ai donné envie d'essayer ça, et que la prochaine fois que vous devrez afficher une carte dans l'un de vos projets vous étudierez l'option OpenStreetMap.

Utiliser un composant Blazor dans une application ASP.NET Core MVC

Wed, 31 Jul 2019 12:00:00 GMT

Blazor est un nouveau framework qui arrive avec ASP.NET Core 3, et qui permets de faire du développement web client en C# au lieu de Javascript. Il propose 2 modèles d'hébergement : un mode client, où les dlls sont envoyées au client avec un runtime .NET, et exécutées grâce à WebAssembly ; et un mode serveur, où le code est exécuté par le serveur, et le client reçoit les mises à jour par une connexion SignalR. Pour plus d'informations, je vous invite à aller lire la documentation de Blazor.

Lorsque vous démarrez un nouveau projet ASP.NET Core3, vous avez la possibilité de créer un projet pur Blazor, ou un projet MVC, mais il est tout à fait possible d'ajouter des composants Blazor à une ou plusieurs page d'un projet MVC.

Note : cet article utilise Blazor en mode server-side, et est basé sur la preview 7 - il peut y avoir des changements dans les prochaines versions.

Migration vers ASP.NET Core 3

Blazor est une nouveauté d'ASP.NET Core 3. Si vous démarrez un nouveau projet ASP.NET Core 3, vous pouvez passer au paragraphe suivant.

Si vous souhaitez utiliser Blazor sur un projet existant sur un framework précédent, il vous faudra d'abord le migrer vers la dernière version : comme d'habitude, lisez la documentation pour effectuer la migration, notamment le passage sur la migration du code de routage pour utiliser .UseEndpoints().

Configuration de Blazor dans le Startup.cs

Pour activer Blazor dans le projet, il y a 2 modifications à faire dans le Startup.cs :

Dans la méthode ConfigureServices, ajoutez services.AddServerSideBlazor(); : enregistrement du service Blazor
Dans la méthode Configure, allez dans le UseEndoints et ajoutez endpoints.MapBlazorHub(); : configuration du hub SignalR utilisé par Blazor

On se retrouve avec le code qui ressemble à ça :

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddServerSideBlazor();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }

    app.UseStaticFiles();

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
        endpoints.MapBlazorHub();
    });
}

Ajout d'un composant Blazor dans une page

Pour mon exemple, j'ai repris le composant Counter du template Blazor, sans l'attribut @page

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

Puis on peux référencer le composant depuis notre vue MVC :

@(await Html.RenderComponentAsync<BlazorInMvc.Components.Counter>(RenderMode.Server))

Vous pouvez lancer la page : vous verrez le composant s'afficher avec le "Current count" à 0, et le bouton. Mais si vous cliquez dessus, rien ne se passe. Il faut ajouter un fichier javascript pour établir la connexion SignalR :

@section Scripts{
    <script src="~/_framework/blazor.server.js"></script>
}

Si l'url de votre page n'est pas à la racine du site, la connexion ne pourra pas s'effectuer correctement. Dans ce cas, il faut rajouter un élément dans l'en-tête de votre page pour préciser le dossier où elle se trouve. Si l'url de ma page est /Home/Counter, le dossier est /Home. J'ajoute donc à ma page :

@section Header{
    <base href="~/Home" />
}

Maintenant vous pouvez retester, et le composant fonctionne : les clics sur le bouton mettent bien à jour le compteur.

Utilisation de la navigation Blazor

À priori, l'utilisation de la navigation Blazor avec le routing MVC risque de poser soucis, mais en étant rigoureux dans la définition de ses routes, on peut faire fonctionner les 2 ensembles.

J'ai 2 pages MVC : /Home et /Home/Counter (même si l'une contient un composant Blazor, c'est toujours une page MVC), et je veux créer 2 pages Blazor : /Nav/Page1 et /Nav/Page2, qui fonctionneront en mode SPA lorsqu'on navigue de l'une à l'autre (et seulement entre ces 2).

Pour faire ça, on va créer un contrôleur qui recevra les requêtes vers les pages Blazor, et on configure le routing pour que toutes les pages sous l'url /Nav pointent vers la même Action.

NavController.cs :

public class NavController : Controller
{
    public IActionResult Index()
    {
        return View();
    }
}

Startup.cs :

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "blazor",
        pattern: "Nav/{page?}/{id?}",
        defaults: new { controller = "Nav", action = "Index" }
    );

    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");

    endpoints.MapBlazorHub();
});

L'action Index va contenir un composant Blazor, qui servira de routeur pour les 2 pages :

Nav.razor :

<Router AppAssembly="typeof(Startup).Assembly">
    <Found Context="routeData">
        <RouteView RouteData="routeData" />
    </Found>
    <NotFound>
        <h1>Page not found</h1>
    </NotFound>
</Router>

Puis les composants Blazor correspondant à nos pages :

@page "/Nav/Page1"
@using Microsoft.AspNetCore.Components.Routing

<h3>Page1</h3>

<NavLink href="/Nav/Page2">Aller à la page 2</NavLink>

@page "/Nav/Page2"
@using Microsoft.AspNetCore.Components.Routing

<h3>Page2</h3>

<NavLink href="/Nav/Page1">Aller à la page 1</NavLink>

Les composants commencent par l'attribut @page, qui permets de définir à quelle url le composant doit répondre.

Maintenant vous pouvez passer de la page1 à la page2 sans avoir un rechargement complet de la page, la navigation se fait par la connexion SignalR. Si vous naviguer vers ou depuis une autre page, la navigation est une navigation html classique.

Code source

Vous pouvez récupérer le code source de cet article sur ma page Github : https://github.com/glacasa/Blog-BlazorInMvc.

Pour le compiler, vous devez avoir la dernière version de Visual Studio 2019 preview, ainsi que le framework dotnet core 3 preview 9 minimum.

packages.config vs PackageReference - le fonctionnement de Nuget avec le nouveau format csproj

Thu, 06 Dec 2018 21:00:00 GMT

Si vous développez un projets sur le framework .NET "classique", et que vous avez décidé de passer à .NET Standard pour les projets liés, vous avez peut-être eu droit à une erreur FileNotFoundException au chargement d'une dll (utilisée par votre projet .NET Standard) - vous obligeant à référencer le package Nuget en question directement depuis l'application appellante.

Depuis quelques temps, les développeurs .NET peuvent utiliser un nouveau format de fichier .csproj (et pour les développeurs Visual Basic, tout ce que j'explique ici à propos des csproj s'applique aussi aux vbproj), dans les projets .NET Core ou .NET Standard.
Voici par exemple les 2 formats de csproj, l'un étant un projet console en .NET classique, l'autre en .NET Core :

Outre le gain évident en terme de lisibilité, le nouveau format apporte une nouvelle gestion des packages Nuget. Voyons comment tout ça fonctionne maintenant.

L'ancien fonctionnement : le fichier packages.config

Si vous êtes développez avec l'ancien format csproj, lorsque vous référencez un package Nuget, il est ajouté dans le fichier packages.config, qui se trouve à la racine du projet.

<?xml version="1.0" encoding="utf-8"?>
<packages>
    <package id="Newtonsoft.Json" version="12.0.1" targetFramework="net471" />
</packages>

Si le package en référence d'autres, toutes les dépendances seront ajoutées dans ce fichier. On peut donc très vite arriver à un assez grand nombre de packages référencés ici.

Le fonctionnement de Nuget est ensuite très simple : il va télécharger le package et le mettre dans un dossier packages, situé au même niveau que le sln. Il va ensuite modifier le csproj pour ajouter la référence vers la ou les dll. Ces dll seront ensuite copiées dans le répertoire de destination en même temps que le projet.

Le nouveau fonctionnement :

La refonte du format csproj a été l'occasion d'améliorer la gestion des packages, et donc de gérer Nuget nativement. Cette fois, plus de fichier packages.config, si vous référencez un package il est directement ajouté dans le csproj en tant que package :

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp2.1</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Newtonsoft.Json" Version="12.0.1" />
    </ItemGroup>
</Project>

Contrairement à l'ancien csproj, où toutes les références étaient des liens vers des dll, ici on sait que la référence vient de Nuget quand on utilise la balise <PackageReference>.

Autre différence avec l'ancien format : nous n'avons plus le dossier packages. Maintenant, les dll sont téléchargées dans le profil utilisateur (allez jeter un œil dans %userprofile%\.nuget\packages sur votre disque dur pour voir la liste), et elles ne sont pas copiées dans l'output lors de la compilation.

Utiliser les deux à la fois

Si vous avez des projets .NET Standard référencés par un projet .NET classique, vous allez vous retrouvez avec les 2 systèmes à la fois, qui ne sont pas vraiment compatibles, et c'est ce qui va causer la FileNotFoundException.

Supposons que votre projet .NET Standard référence Newtonsoft.Json. Il utilise le nouveau Nuget, et ne va pas copier la dll dans l'output.
Votre projet .NET classique lui utilise toujours l'ancien système de références de projets : il va récupérer l'output de l'autre projet, mais ne récupèreras donc pas Newtonsoft.Json. Et donc, lorsque vous aurez besoin de sérialiser des données à l'exécution, ça plante.

Un moyen simple de réparer ce problème est de simplement ajouter le package Nuget dans le projet principal, pour être sûr qu'il le récupère. Mais il y a mieux.

Utiliser `PackageReference` dans l'ancien csproj.

En fait, il est possible d'utiliser les dans les anciens csproj, la documentation se trouve ici :
Migrate from packages.config to PackageReference.

Attention, ça ne fonctionne que dans Visual Studio 2017 (v 15.7 minimum), et les projets C++ et ASP.NET ne sont pas encore supportés.
Pour utiliser PackageReference, il suffit d'ajouter <RestoreProjectStyle>PackageReference</RestoreProjectStyle> dans le csproj :

</PropertyGroup>
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
</PropertyGroup>

Attention, si vous avez déjà un packages.config, il faut désinstaller tous les packages avant de les remettre. Visual Studio 2017, vous propose de le faire automatiquement, il suffit de faire un clic droit sur le fichier packages.config, et cliquer sur "Migrate packages.config to PackageReference".

Si tout se passe bien, ça marchera du premier coup (sinon bon courage pour débuguer les conflits de version). Une fois sur le nouveau Nuget, vous ne devriez plus avoir de soucis de fichiers manquants.