.Net Core 3.0 à .Net 8 (C#,F#, Visual basic .Net)

[Arduino-RPI]

Hello,

Pour la preview 5 du .net 7, de mon coté je n'ai rien testé.
Par contre, je me suis installé vs2022 en preview et j'ai trouvé une nouveauté plutot sympa...
Nous avons maintenant un "Blazor Hybrid" (Application .NET MAUI Blazor) et je trouve le concept génial!
MAUI remplace Xamarin et Blazor est venu se "greffer" dans MAUI. Pour moi qui ait fait quelques petites applis en Xamarin, et qui monte doucement en compétence sur Blazor, c'est le combo parfait )
Grossièrement, tu encapsules ton application blazor dans un BlazorWebView et "le tour est joué" avec un peu de retouche quand meme.
J'apprécie beaucoup car je trouve plus pratique l'architecture blazor que le concept MVVM avec le binding et pour la couche UI se passer du xaml et rester dans du web ...
En espérant que ce concept prenne vie dans une future release... D'ailleurs le projet Mobile Blazor Bindings je n'entends plus trop parler...ou est-ce ce blazor hybrid qui vient prendre la relève ?

Pour le nanoframework, j'avais vu cela il y a quelques mois mais je préférai rester sur l'ide Arduino et des bibliothèques fonctionnelles pour les différents capteurs et autres que j'utilise.
Mais intéressant aussi !

[Bud Spencer]

Salut Arduino-Pi. Toujours fidèle au new Net a ce que je vois

Je mise aussi beaucoup sur MAUI et l’intégration avec Blazor, ça deviendrait carrément excellent . Je n’expérimente encore rien là-dessus parce que je m’interdis généralement les previews (pour éviter toutes ambiguïté dans mon boulot ou beaucoup de mes devs sont critiques et ou je n’ais pas beaucoup de marge d’erreur). A aujourd’hui, je suis encore obligé d’entretenir des applis (principalement android) écrites en JAVA et j’attends justement .NET 7 et MAUI pour les réécrire en C#.

A part ça, coté .NET, je viens de finir la supervision d’une nouvelle machine. J’ai utilisé .NET 6 avec l’option Windows Desktop. Que du bonheur à programmer avec toujours cette impression de facilité croissante en utilisant les évolutions de C# et la richesse de .NET. Pourtant, l’application est du genre plutôt corsé puisqu’elle exploite 7 connexions en simultanées entre les différents automates, les robots, les liaisons avec les données de l’ERP, les services d’impressions ect ... Cerise sur le gâteau, la charge cpu est dérisoire et la gestion de la mémoire ne laisse aucune fuite. Ce n’était pas toujours évident d’arriver à ce niveau de performance avec l’ancien Framework .NET, mais avec cette nouvelle génération, c’est carrément du gateau. Tout ça tourne sur une console PC industriels sous Windows 10 IoT Entreprise. Au cours de ce projet, j’ai pus faire des tests de dialogue entre un automate Siemens S1500 en OPCUA et un PI avec les même libs que j’ai utilisé sous windows et tout a fonctionné pareil par simple déploiement autonome sans aucune modif de code sur des distri PiOs buster et bullseye ‘out of box’. Pour moi, c’est un des points les plus intéressant de .NET.

Pour ce qui en est Blazor Mobile, je suis persuadé que l’on va voir naitre quelque chose d’officiel. Je pense qu’il faut juste laisser le temps à MAUI de bien prendre place dans cette nouvelle version de .NET et le reste suivra.
L’ide Arduino je l’ai viré et avantageusement remplacé par PlatformIo avec VS Code. De toute façon, je n’avais jamais aimé bosser avec ce truc.

Edit ****************
Concernant MAUI J'avais reçu ca dans mes mails : https://devblogs.microsoft.com/dotnet/i ... e=June2022

Ca donne vraiment envie d'y passer

[Arduino-RPI]

Hello oui toujours à l'affut des news sur le .net et des différentes expériences des uns et des autres
MAUI/Blazor, j'espere que ca va aboutir dans une future version.

Pour tes projets industriels, ca me rappelle les cours d'automatismes avec Téléméca (grafcet et le lader) et Siemens (step7) et les robots staubly et ABB.
En tous cas, tout cela semble intéressant.

Merci pour le lien A suivre...

[Bud Spencer]

Pour sûr c’est très intéressant et quand tu utilises .Net pour ce genre de chose et que tu sais que tu peux profiter de toute sa puissance et sa richesse même sur un PI, c’est quand même génial.

Tu avais réussi à te démerder de ton soucis avec ninject et entity ?

[Arduino-RPI]

Hello,
Par rapport au souci de prod en interne (context has been disposed...1 a 2 fois par semaine), je n'ai pas pu replonger dedans car d'autres sujets en meme temps.
Mais j'avais fait une premiere analyse et j'avais un gros doute sur la facon dont l'injection de dépendance via ninject était implémentée.
Avec Ninject (comme d'autre framework), on fait les "registrer" (interface <-> classe) metiers et on définit le scope d'utilisation (InSingleton/InTransient/InRequest).
Ensuite dans chaque constructeur des classes metier, on vient injecter des differentes interfaces + l'interface Dbcontext, et pour chaque classe metier, on dispose le context.
Et c'est la que j'ai un gros doute...C'est "comme-ci" le meme dbcontext était partagé pour tous les utilisateurs connectés...
Du coup, un utilisateur qui dispose le context a un moment, le dispose pour tout le monde...???
Et dans l'application, un utilisateur peut importer un fichier (traitement de 30/40 minutes avec des appels a la base sql) et la si un autre utilisateur dispose le context pendant ce traitement d'import, ca plante (dbcontext has been disposed) l'import... Enfin j'ai l'impression que c'est ce qui se passe...
Je pensais que le meme context était utilisé tout le long d'une requete http...Mais de la a avoir le meme context partagé pour tous les utilisateurs connectés...Il y a quelque chose qui m'échappe...
Si tu maitrises bien ces histoires de scope lors de l'injection, je suis preneur .
En tout cas, je vais réviser un peu tout ca

[Bud Spencer]

Je ne sais pas comment Ninject est sensé gérer les dbcontext entity, mais en théorie, on n’utilise jamais un dbcontext unique (sigleton) pour ca. Avec la DI de .NET, le dbcontext est enregistré en tant que service dans une collection (et non pas comme singleton) et est injecté dans le constructeur de chaque contrôleur qui en a besoin. A chaque appel du contrôleur, une nouvelle instance est créé et automatiquement et supprimée quand elle a fini son job. Si ton dbcontext est passé comme un singleton, ça peut expliquer ton problème de perte de celui-ci et aussi tes problèmes de lenteur. De ce coté là, la DI de .NET facilite énormément les choses et la chasse aux fantômes injectés est (presque) un mauvais souvenir pour ce genre de truc

[Arduino-RPI]

Merci Bud pour ton retour.
Les injections des differents services/interfaces sont definies en inRequestScope (nouvelle instance valable tout le long de la req http) et non Singleton, donc normalement la dessus c'est bien configuré.
Pour les lenteurs, je pense que des qu'on lance un traitement long (import de fichier de 20min) dans l'application, le dbcontext n'est jamais disposé et les entites du context entity gonflent et allourdisses l'application. (j'ai fais des tests en modifiant les appels a la base, en passant par des usings() et les temps sont beaucoup plus rapides (divisé par 3 voir 4 les temps de traitement) car finalement les context entity sont utilisés tres peu de temps et bien libérés). Je vais continuer d'investiguer pour les pertes de context "partagés".

Je reviens sur le nanoframework dont tu parlais dans un post precedent.
J'ai finalement regardé un petit peu et a ma grande surprise, il y a pas mal de bibliotheques developpées pour les capteurs que j'utilise (bmp280, dht etc.. )
Du coup, je vais me lancer sur un ESP32 qui traine chez moi et installer le plugin dans VS2022 et tester quelques trucs (sauvegarde de donnees dans un xml sur la memoire du microcontroleur ?).

[Bud Spencer]

inRequestScope est je pense la bonne façon de faire et l’utilisation dans des directives using te garantit que chaque instance est bien disposée à la sortie du bloc. Sauf erreur de ma part, c’est une appli asp mvc5, donc .NET Framewok et en plus avec Ninject. C’est justement avec ce genre d’appli que l’on prend toute la mesure de l’efficacité et de la simplification de mise en œuvre qu’apporte .NET. J’ai moi-même parfois bien galéré aussi notamment avec des vielles appli aspx qui faisaient beaucoup de requêtes avec entre chacune des traitements assez complexes et qui parfois se plantaient sans réelle explications. Perso, je n’ais jamais remis en cause le Framework et je suis toujours parti du principe que c’était le développement qui posait un problème et à chaque fois je finissais par trouver une solution.

Pour le nanoframework, j’ai de très bon souvenir de mes expériences avec le NetMF (.Net Micro Framework) donc je vais forcément consacrer un peu de temps a ce nouveau framework. J’ai déjà tout ce qu’il faut pour faire et cela fera sans doute parti de mes activités pour cet hiver. J’ai été regarder la liste des devices déjà implémentés et c’est effectivement déja bien fourni

[Arduino-RPI]

Le problème chez nous en interne (dans ma boite), c'est que pour une refonte partielle de fonctionnalité ou autre (couche d'accès aux données par ex), il faut un budget pour pouvoir pointer les heures... Et comme la direction ne comprend pas qu'il faille parfois refaire/faire évoluer l'application, il n'y a donc pas de budget... Je vais voir ce qui est le moins couteux pour que les gros traitements dans l'appli ne plantent pas, je te tiendrai au courant.

[Bud Spencer]

Ouais, ce n’est pas toujours facile de faire comprendre les besoins à ceux qui paient. Beaucoup s’imaginent que parce qu’un truc fonctionne que l’on ne doit pas y toucher, même si ça devient un calvaire à entretenir pour les techniciens ( que l'on tiendra forcement pour responsables quand tout se cassera la gueule ...) .

Pendant ce temps, .NET 7 poursuit son petit bonhomme de chemin avec la sortie de la preview 7
https://devblogs.microsoft.com/dotnet/a ... preview-7/
https://dotnet.developpez.com/actu/3356 ... framework/