framboise314.fr

L’avantage d’Entity c’est que ça permet de réduire énormément le code quand tu utilises des bases de données et qui dit moins de code dit developpeur fainéant plus heureux, maintenance plus facile et surtout moins de bug potentiel. Un autre gros avantage, c’est que ça t’oblige à avoir une structure de données très propre et ça c’est vachement important sur le long terme. SI tu te mets à utiliser Entity, tu vas voir que tu prendras beaucoup plus de soins dans la construction de tes bases et de tes objets et juste grâce à ça, contrairement à ce que beaucoup peuvent penser, tu finiras par y gagneras meme en en performance. Pour résumé, Entity est un excellent ORM qui regorge de bonnes surprises. En plus, ce n'est pas un truc tiers développé par on ne sait qui, on ne sait ou et pour combien de temps, c'est du vrai .NET donc c’est vraiment dommage de s’en priver quand on peut l’utiliser.

Je ferais peut etre un petit exemple de code avec ca a l'occase.

.Net Core 5 preview 5 -> https://dotnet.microsoft.com/download/dotnet/5.0

Un peut la tète dans le guidon pour le boulot pour passer par ici, j'avais oublié de vous informer de la sortie de la preview 6 de la version 5 sortie vendredi dernier.
https://dotnet.microsoft.com/download/dotnet/5.0

Nouveau build de la version 5 (preview 7) : https://dotnet.microsoft.com/download/dotnet/5.0

Comme je commence à retrouver un peu de dispo pour des projets ‘secondaires’, je me suis tranquillement remis sur le projet ‘Chronos’. Je ne sais plus si je vous en avais déjà parlé, mais l’idée, c’est une solution complète de pointage horaire évoluée (avec options de saisie de poste de travail, du rattachement à des ordres de fabrications ou des commandes, de la synchro de données ect …).

Je m’étais dit que ce genre de projet qui requiert un large panel de type d’applicatif était un bon exercice pour voir ce que l’on pouvait tirer de ce .Net Core. Il y a en effet :
- bien évidement un serveur data (j'ai opté pour SQL Server)
- des librairies communes
- un serveur d’application web (MVC Razor) (supervision, configuration, reporting, messaging …)
- un serveur d’API Rest (MVC) pour les dispositifs de pointage (smartphone, pc, pointeuse ..)
- plusieurs petits modules et services de synchro de données (erp, gpao, paie …)
- une application GUI (Blazor) en dispositif de pointage tactile avec option RFID (autodetecté)
- et d'autre idées sous le coude qui verront le jour suivant la trajectoire du projet

Et J’ai pu faire tout ça exclusivement avec ce qui est fourni out-of-box avec .Net Core 3 et sans utiliser aucune librairie tierce (à l’exception des javascripteries classiques pour les pages du serveur d’application). Tous les applicatifs (serveurs, services, moudules, gui) tournent sans aucune différence sur tous les systèmes testés (Windows 10 et Server 2016,2019, Linux (Debian 10, Ubuntu 20) et exactement de la même façon sur le PI (PI 3 Rasbian Stretch) et tout ça sans installer aucune dépendance spécifique sur aucun des systèmes. Je n'ais pas de Mac pour tester, mais cela devrait tourner tout pareil sur une pomme. Alors évidement quand on bricole un petit programme de temps en temps pour s’amuser, on ne peut pas comprendre ce que cela représente, mais je peux vous dire par expérience que cela fait très très longtemps que beaucoup de développeurs rêve de ça.

La suite du projet Chronos, c’est la mise en production expérimentale. Il sera testé à partir de septembre dans une petite entreprise de 20 personnes. Pour ce test, j’ai fait le pari de n’utiliser QUE des Raspberry PI. Dans un premier temps, je vais utiliser 6 PI.
1 pour le serveur SQL Server
1 pour les serveurs web, api et services
4 pour construire 4 pointeuses à identification RFID

Une petite photo de la ‘pointeuse’ prototype que je dois encore ‘mettre en boite’. C’est une application Blazor multi-formulaire qui tourne en kiosk dans Chromium et le lecteur RFID est un Mrfc522 connecté en spi. A noter que je n’ai pas écrit la moindre ligne de code en javascript dans cette appli et qu’elle utilise la même libraire de models que les autres applications du projet. Tout le dynamisme est codé en C# directement dans chaque page et ça, c’est carrément du bonheur

La même appli 'pointeuse' mais cette fois exécutée sur un pc windows ordinaire.

Ici il n’y a pas de GPIOs donc pas de lecteur rfid sur une spi, donc l’appli ne propose pas l’option ‘Présenter Badge’ et ignore tout ce qui est rattaché aux GPIOs. Je reviens là-dessus parce qu’au début des exemples .Net Core, j’avais écrit ceci :

Bud Spencer a écrit : ↑

mer. 11 déc. 2019 20:49

...
Alors bien sur si maintenant je démarre l’appli sur le pc, j’ai un merveilleux message qui me dit qu’il ni a pas de contrôleur de GPIO mais Je pense qu’il y a moyens de détecter ça et de conditionner pour pouvoir malgré tout démarrer l’appli pour profiter de tout ce qu’elle contient n’utilise pas de gpio.
...

En fait, la solution est toute simple. Il suffit de tenter l’instanciation d’un contrôleur GPIO dans un block try de façon à initialiser une variable static qui définit l’usage ou pas de tout ce qui est GPIO. Perso, j’ais mis ça dans le constructeur de la classe Startup, donc au plus tôt, de façon à pouvoir conditionner toutes les injections de dépendances et les services qui font es appels à des GPIOs (en vignette sur l’image)

Le prototype de pointeuse mis en boite.
Ça reste un proto (pas forcément très esthétique et juste assemblé ‘pour que ça marche’) mais il est parfaitement fonctionnel. Le bloc à gauche dans la boite est une alimentation 5v 5A et à droite, le lecteur rfid MRFC522 ainsi qu’une led qui clignote et qui indique que le système est en attente de lecture d’un badge. La plaque de face avant à été taillée dans celle livrée avec le boitier mais comme c’est de l’alu qui fait moins de 1 mm d’épaisseur, cela manque un peut de rigidité. Pour les modèles ‘en production’, je vais faire découper au laser des face avant de 2 ou 3 mm ainsi que des pattes et brides de support de façon à n’avoir aucune vis visible à l’extérieur du boitier. Il n’est pas non plus exclu que je passe sur des boitiers en profilé d’alu. J’ai aussi prévu quelques trous d’aération coté alimentation et un ventilo piloté par le programme (en référençant la température cpu). Cela dit, avec le Pi3 le truc ne chauffe pas du tout, mais la bonne nouvelle, c’est que compte tenu du faible cout des composants de ces pointeuses, je vais pouvoir les équiper directement de PI4 8 Go tout en restant bien inferieur à l’enveloppe qui m’a été attribuée pour ça.

Comme convenu, la mise en prod expérimentale débutera en septembre en version .Net Core Core 3.1 dans une petite entreprise d’une vingtaine de salariés (5 pointeuses + 1 server) avec objectif de passer sous Alpine en remplacement de Raspbian et en version .Net Core 5 des qu'elle aura dépassée le stade de preview. Si tout fonctionne comme il faut, j’aurais un autre déploiement pour société de ~100 personnes (10 à 15 pointeuses) a faire avant la fin de l’année.

A titre informatif, avec un pi3 (les tout premier modèle) et une vielle SD class 6, il faut seulement 35 secondes après allumage ou un reset pour que la pointeuse soit opérationnelle en sachant qu'elle est en dhcp et que l'application télécharge sa configuration sur le serveur.

Hello Bud!
Super projet que tu nous montres la.
.Net Core sur des raspberry me semble vraiment bien approprié pour ce type de projet.
Si tu continues de poster ici, je vais suivre avec attention l'évolution de ton projet et de sa mise en prod
Je serai curieux de voir un sql server tourner sur rpi 3 ou 4 ?
Par rapport a tes micro-services que tu as mis en place, cela s'appui sur docker ?

Bha oui, je pense que je vais continuer à poster quelques trucs ici. Je ne suis pas convaincu que cela intéresse beaucoup de monde parmi les habitués de ce forum, mais les Infos concernant .Net Core sur le PI sont plutôt rare et il y a surtout beaucoup d’interrogations, donc forcément ça devrait servir.

Globalement Je suis assez surpris du très bon comportement de .Net Core sur le PI et plus généralement partout ailleurs. Je suis developpeur .Net depuis la toute première version sous Windows et je fais aussi partie de ceux qui ont essuyés les plâtres sous Linux avec Mono et pourtant je perçois .Net Core comme une véritable révolution. Tout me semble plus facile, moins verbeux, plus autonome, plus performant et surtout, tout fonctionne comme prévue du premier coup quelle que soit la cible et sans avoir à se battre avec chaque système et ses dépendances (ce qui n’avais jusque-là jamais été vraiment le cas sous Linux meme avec Mono).

Concernant le PI, on développe exactement comme pour n’importe quel autre système sans aucune contrainte supplémentaire et System.Device.Gpio nous sert toutes la partie hardware sur un plateau sans avoir à se poser de question. Pour se simplifier encore plus la vie il y à Iot.Device.Bindings qui map déjà pas mal de composant parmis les plus utilisés. Pas de bol, le capteur rfid MRFC522 n’en fait pas (encore) partie. Qu’à cela ne tienne. J’ai juste utilisé une lib qui était à l’origine écrite en c pour l’arduino, puis qui avait été portée en C# pour Windows 10 IoT (Windows.Devices.Spi), que j’avais ensuite modifié pour Mono (Wrapp bcm2835) et puis finalement je l’ai adapté à System.Device.Spi

Pour l’instant, je n’ai encore rien conteneurisé sur ce projet, mais j’ai déjà testé la création d’images Docker d’applications .Net Core et c’est tellement évident que l’on a l’impression que s’est fait pour. Si j’ai du temps pour ça, j'en ferais peut etre l’essais sur un PI.

Concernant SQL Server, ce n’est pas officiellement pris en charge sous ARM, mais a aujourd’hui, en bricolant un peu, on peut faire tourner tout sur n’importe quoi (ou l’inverse). Bon cette partie, c’est surtout pour le fun parce que je n’envisage absolument pas de mettre un serveur sql en prod sur un PI d’autant que j’ai déjà des batteries d’instance SQL Server à haute disponibilité à ma disposition. Cela dit, comme j’utilise EF Core pour l’accès aux données, il ni a aucune requête sql dans aucun des programmes donc je pourrais très facilement interfacer un autre SGDB sans aucune modif de code.

A titre d’info, j’ai aussi utilisé avec succès Identity pour la partie authentification et je suis en train de regarder du côté des gRPC pour les échanges entre services. Le seul truc que je n’ai pas réussi à faire tourner sous Raspbian c’est la transformation du programme de pointeuse (Blazor) en appli Electron mais je n’ai pas trop insisté non plus et cela ne concerne plus trop .Net Core mais plutot Electron

Bref, il y a une richesse incroyable dans ce .Net Core et le plus gros morceau reste a venir avec le très attendu .Net 5 ...

Une image de la page de paramétrage dune pointeuse 'PI' dans le programme de gestion. Chaque pointeuse à un GUID et a chaque fois qu'il y a un changement de paramètres ou d'objets (ajout suppression ou édition de salarié, d'affaire, de poste ...) un flag lui indique les paramètres à recharger. Cela simplifie beaucoup le déploiement de nouvelles pointeuse puisqu'à la mise en route il suffit de leur renseigner le GUID, l'URL du serveur d'API et la valeur de l'ApiKey. Là, je suis en train de regarder pour ajouter aussi une mise à jour automatique du programme embarqué quand il y a un changement de build.

L'application pointeuse possède un service interne qui repose sur un timer totalement asynchrone avec des ticks toutes les secondes (voir les premières page du topic). Pour contrôler le ventillo, j'ai ajouté un compteur pour mesurer la température cpu toutes les 30 secondes et déclencher la ventilation si la température mesurée est supérieur au paramètre de seuil de ventilation. Pour ca j'ai juste utilisé iot.Device.CpuTemperature et une pin System.Device.Gpio. L'envois d'un signal à la fin de la fonction permet de lever un évènement dans la page courante de façon à afficher la valeur de température. voila ce que ca donne en code test :
Pour l'affichage de la température dans les pages Blazor, il y a une balise HTML Et le code de l'évènement du signal