Reprise du message précédent :
Bonjour, je repose la question ici : est ce qu'il y a des gens ici qui ont l'expérience d'Avalonia ?
 
https://github.com/AvaloniaUI/Avalonia
 
Ce Framework permettant de de réaliser des applications multi plateformes en C# / Net.Core 3, auraient ils des retours d'expérience surtout dans le domaine de la "maintenabilité" des applications ?  
 
L'idée serait de profiter de la refonte d'une application de gestion pour la rendre multi-plateforme : W10, OS/X, Linux (desktop uniquement à priori).

Wow
 
Je connais pas du tout, mais j'ai un besoin pour ça assez rapidement.
Je vais tenter, me renseigner

 
Je crois avoir lu tout ce qu'il est possible de lire sur le Net, à priori le projet est séduisant mais certains commentaires sont assez critiques, après on ne connait pas le niveau des mecs qui critiquent... voilà pourquoi j'aurais bien aimé avoir un retour de quelqu'un qui "pratique" réellement le truc.
 
C'est toujours le problème de passer quelques semaines pour apprendre et mettre en œuvre un outil qui, au final, risque de se retrouver inadéquat !
 

 
m'en parle pas...
 
Silverlight  

On est bien d'accord

 
 
Ah toi aussi ?

     

J'ai failli de faire l'erreur sur un gros projet où j'avais carte blanche  

Officiellement c'est supporté jusque 2021 donc c'est pas grave .

Si jamais il y a du monde ici qui bosse avec les Azure Functions et qui souhaitent migrer leurs projets de .Net Core 2.x à 3.x, pensez à changer la version de vos Functions !
 
=> en local, modifiez dans le .csproj la balise "AzureFunctionsVersion" et spécifiez "v3"
=> sur Azure, modifier la variable d'environnement "FUNCTIONS_EXTENSION_VERSION", en passant la valeur à "~3"
 
Vous aurez aussi besoin de mettre à jour le NuGet "Microsoft.Sdk.NET.Functions" en >=3.0.0 (3.0.2 pour LTS)
 
Bref, j'ai perdu du temps pour rien car je n'avais pas jugé nécessaire de lire le paragraphe dédié dans la doc du coup je partage
https://docs.microsoft.com/fr-fr/az [...] m-2x-to-3x

Tiens les gars, petite question flash comme ça.
 
En WPF, à l'heure à laquelle on vit (VS2019, projet .NET Core 3.0, WPF avec MVVM), c'est toujours obligé de décrire les propriétés full dans les ViewModels, avec NotifyPropertyChanged(); dans le setter ?
 

 
C'est pas automatique désormais, même pour une propriété simple publique ?

 
ou à la rigueur
 

Regarde du coté de Fody peut-être ?
 
https://github.com/Fody/PropertyChanged

C'est beau !
Bon, après c'est dommage que ce soit pas encore natif, mais bon, ça m'ira très bien, j'ai pris l'habitude désormais.

Merci

Je suis surpris qu'il n'y ait toujours pas d'annotation dédié au mvvm depuis le temps que ce pattern existe..

C'est clair !
Je me demande bien quelle est la proportion d'applications WPF qui sont écrites en natives (code behind, je sais pas comment on dit) par rapport au MVVM.
A mon avis, y en a pas des tonnes...

Bah surtout quand tu fais du DDD ça s'y prête vraiment bien..

Y'en a qui suivent toujours Blazor? C'est sensé sortir avec .NET 5 en novembre...

Qui a utilisé blazor server side ?

A votre avis, c'est l'avenir ou pas ? ou plus généralement webAssembly ?

On est sur le point de techno de front end ici

Perso je ne vois qu'un intérêt à Blazor, ou du moins qu'une originalité par rapport à ce qui existe actuellement : la partie Web-Assembly. Donc compiler du code spécifique C# vers l'IL Web-Assembly pour booster les perfs côté client.
 
Utiliser ça pour faire du "vrai" front (donc remplacer entièrement le JS par du C#), c'est voué à l'échec comme GWT, JSP, ASP et équivalents. Surtout que les dev front sont à ma connaissance tous passés sur les frameworks JS (Angular / React / Vue).
 
Sinon le mode server est déjà dispo dans .NET Core 3

 
Oui le mode serveur est dipo, c'est pour ça que je demande si certains sont passés en prod avec
 
Remplacer le c# par du JS c'est un super avantage pour moi et ma boîte . Et de plus on a pas toute la machinerie propre au front (transpilation, bundling, etc..)
 
Le partage de lib avec .Net standard pour le front et back c'est cool aussi

Comme je disais en dessus, justement remplacer js par C# c'est ça la mauvaise idée. Il restera toujours ces problèmes :
- Une latence élevée et un serveur surchargé en mode server
- Du code généré à partir de C#, et donc un debug sur le browser plus complexe
- JS et le DOM ont été prévus pour fonctionner ensemble. A voir avec Blazor, mais sur ASP & Co, quand une fonctionnalité n'étais pas incluse, tu repassais en JS. Et là bon courage pour maintenir pour ton databinding avec le server
 
Il reste le partage de lib effectivement, mais quand les conditions suivantes sont réunies, ce qui n'est pas gagné :
- A exécuter côté client uniquement, sinon tu es déjà bon en ASP.Net classique
- Traitements lourds ou avec une latence réduite (pour soulager respectivement ton server ou ton client, sinon tu le ferais tourner direct sur le server)
- Code dont l'implémentation n'est pas protégée, car ton client peut alors récupérer ton code
- Code dont l'implémentation est suffisamment complexe ou avec un gain de perfs important, et ne peut donc pas être traduit facilement en JS/TS
- Code dont le résultat n'a pas besoin d'être transmis au server (on ne se fie habituellement pas aux calculs des clients)
 
Bref, mieux vaut apprendre à faire du JS/HTML pour la partie front, surtout que c'est pas non plus si complexe que ça à apprendre, et que tu as des tonnes de dev front sur le marché

Ouep les gars, moi je suis en galère sur un projet avec des potes.
On bosse sur une application WPF, designée MVVM, en .NET Core 3.0.

Je bosse sur un module d'édition de documents, donc naturellement, je m'orientais "à l'ancienne" vers un éditeur HTML (à la TinyMCE / RadEditor...), qui offrirait des templates avec des balises (cette partie-là, ça va...) et qui stockerait les fichiers édités en base de données (en HTML donc, à priori).
Autant en web, j'aurai géré la chose, autant là je sèche...

J'ai téléchargé / essayé des tonnes d'exemples à base de RichTextBox ou autres WebBrowser, mais rien ne convient pour le moment.
La principale contrainte que j'ai, c'est qu'il faut que l'éditeur soit WYSIWYG, car il s'adresse à des néophytes, hors de question de les laisser galérer avec du balisage en texte brut.

Il existe apparemment des solutions commerciales en DIY sous forme de toolkit ou carrément de solutions toutes prêtes...

Mais avant de craquer ma tirelire (on est en mode garage là pour le moment...), j'ai essayé quelques démos/billets mais sans succès, je finis toujours par bloquer :
- https://www.codeproject.com/article [...] ext-editor
-> c'est basé sur un helper qui ajouter une propriété bindable au RichTextBox. C'est beau, et c'est le plus avancé que j'ai réussi à implémenter... mais ça requiert de la conversion HTML > XAML avec perte (les fichiers sont stockés au format XAML du coup et accessoirement j'arrive même pas à créer un document vide...)
- https://www.c-sharpcorner.com/artic [...] using-wpf/
-> celui-ci se base sur des contrôles vieillots, et non MVVM ce qui le rend compliqué à mettre en oeuvre dans mon cas
- https://www.codeproject.com/tips/87 [...] tml-editor
-> pareil pour celui-ci, en plus d'être extrêmement lent (conversion XAML > HTML probablement)
- https://archive.codeplex.com/?p=smi [...] dId=234531
-> celui-ci me plait bien, je l'adapterai assez facilement à ma solution MVVM, mais il repose sur des dépendancies (Windows.Forms notamment) auxquelles je n'ai pas accès en .NET Core

[Attention, certains de ces modules comportent des noms suspects de fichiers, dans l'URL notamment, donc Chrome s'insurge, mais soyez tranquilles, j'ai épluché tout ça, c'est safe, pour ceux que ça intéresserait].

Bref, certains par ici ont-il été soumis à une même problématique ?

Bonjour,

J'aurais besoin d'un peu d'aide pour lire proprement le port série d'un arduino pour mon petit observatoire astro.

Pour le moment j'ai un timer dans mon programme VB qui appelle la fonction de lecture du port une fois par seconde.
L'arduino lui envoie l'état des différents éléments une fois toutes les 2 secondes, sous la forme "111"
correspondant à l'état d'un capteur effet hall pour connaitre la position du télescope, la position ouverte ou fermée du toit de l'abri, et l'état de l'alimentation.

Quand j'envoie un ordre ça me retourne l'action sur le port série, par exemple "Ouverture du toit"
j'aimerais que ces actions soient affichées dans le cadre TextBox, mais pas les valeurs "xxx" pour donner l'état.

J'ai donc mis une condition "If Incoming.Length.Equals(3) Then" pour traiter différemment ces valeurs, mais ce n'est pas la bonne solution parce que quand j'effectue une action, l'état des capteurs est vérifié beaucoup plus rapidement, pour les limit switchs du toit notamment,
et tout est lu n'importe comment, ca m'affiche des "10110101111001111101010101111111"

Enfin bref, j'imagine qu'il faudrait mettre des caractères de début et fin de chaîne?
Est-ce que vous auriez un petit exemple?
J'imagine qu'il ne faut pas saturer le port non plus?
Si mon programme VB lit bien les chaînes "xxx" une par une, mais que des centaines sont en attente sur le port...

Ou alors augmenter la frequence de lecture?
Je suis à une seconde parce que c'était dans l'exemple que j'avais vu, mais qu'est-ce qu'il se passe si on l'augmente?
À partir de quel moment ça peut ramer/déconner?

Voici ma fonction pour le moment :

Merci

édit : petit screenshot de mon programme pour que ce soit plus parlant

et j'ai un deuxième arduino, et une deuxieme partie dans mon programme qui lit un peu plus de données (temperature, humidité, tensions, position moteur pas à pas...) donc dans l'idéal il faudra que j'applique la solution au deuxième

Des news sur Blazor : MS a l'air vraiment décidé à le pousser en le transformant en mobile native, façon React Native / Flutter : https://devblogs.microsoft.com/aspn [...] xperiment/
 
Je commence à être hypé : comparé à Xamarin, je préfère largement les syntaxes web que XAML (notamment pour tout ce qui est mise en forme / CSS). A voir si ça fait décoller Blazor, Flutter par exemple n'a pas l'air d'avoir été trop adopté pour l'instant (du moins dans ma région).

C'est pas comme .Net FW 5 qui vient de mourir alors  

Bienvenue  
 
Bel avatar au fait

Entre bonnes personnes donc

Messieurs, encore une question, cette fois-ci d'ordre architectural.
 
J'ai une application WPF (.NET Core) connectée à une base de données SQL Server par l'intermédiaire d'un service WCF (.NET Framework).
La mise en place et l'intégration ça roule, mais au runtime j'ai remarqué un truc rigolo.
 
J'ai écrit 2 variantes d'une même méthode côté service.
La première retournant directement une collection d'entities (générées automatiquement depuis un EDMX dans la DAL) (en rouge)
La deuxième retournant une collection d'objets déconnectés, que je mappe un à un au résultat (entities) que la DAL me fournit (en bleu).
 

 
Au runtime, l'appel à la méthode retournant des entities crashe, avec une erreur réseau (??!).
La deuxième, fonctionne, je récupère bien ma collection d'objets.
 

 
Vous avez une idée de ce qui empêche l'utilisation "tout-en-un" de la première solution ?
C'est le "partial" de la classe entity ?  
C'est le fait que l'entity comporte des propriétés de navigation complexes que je n'ai pas encore reproduites en DTO ?

Vu que c'est un EDMX, c'est de l'EF6 ou inférieur. Donc des entités usine à gaz qui doivent être bien sympa à serialiser.
Selon le volume retourné et la gueule des objets ça doit faire un truc énorme dans le cas qui marche pas, et tout petit dans le second parce que là tu renvoies bien des objets POCO avec juste des propriétés auto implémentées.

J'imagine que le contrat du service dans le premier cas doit être imbitable ?

Ca peut venir aussi venir du binding qui ne supporterait pas le volume (en fonction de la complexité du graphe, de la quantité à transférer, etc) mais normalement ça renvoie des exceptions explicites, sauf si la conf du serveur les intercepte.
Au moins côté serveur tu dois avoir les exceptions.

Et côté EF on ne sait pas si il va chercher les enregistrements liés à ta table de départ au moment de la serialisation. Si tu as des Include et de l'eager loading si ça se trouve il tente de te serialiser toute ta base de données et pas juste ta table .

Bref, renvoyer des entités EF6 sur un web service, même si tu ne précises pas le protocole exact utilisé et la conf de tout ça, ça me semble une très mauvaise idée rien que pour toutes ces raisons et sans doutes d'autres encore .

Quand tu fais ton tolist dans la première méthode, wcf va sérialiser ton objet entier. Vu que tu as fermé ton contexte, au moment de récupérer les références étrangères ça va planter.

Dans la seconde méthode tu as fait un select donc tu n'as plus d'objet entity donc plus de problème : tu as tout chargé au moment où ton contexte était valide. Il va sans dire que c'est la méthode propre.

Par curiosité, tu as de l'existant pour avoir wcf ? Vu que c'est pas compatible .Net core, ni spécialement pratique niveau intégration, il vaut sans doute mieux partir sur du rest...

Édit  

Je suis bien d'accord avec ta piste de l'exception en accédant aux propriétés de navigation, c'est aussi pour ça que je disais de voir l'exception côté serveur. Là on a plein de raisons pour dire que le truc est mal branlé, mais on ne sait pas à quel niveau ça a coincé en premier.

A propos de WCF : on sait que c'est du WCF mais on ne sait pas du tout le binding utilisé, on a juste un indice pour dire que c'est du protocole http .

Pour info en .Net Core on peut consommer les bindings interopérables de WCF : SOAP, REST JSON, et même NetTcp. Il y a des bidouilles à coup de svcutil pour récupérer le contrat facilement.
Et il y a des portages plus ou moins aboutis/officiels de WCF vers .Net Core :
https://github.com/dotnet/wcf
https://github.com/CoreWCF/CoreWCF
Ca n'a pas grand chose à voir avec la question mais c'est pour partager, histoire de dire que WCF n'est pas si abandonné ou peu pratique que tu semblais le dire.

Mouais. Vu que le cas 1 plante et pas le second, c'est quasi sûr que le plantage vient de là. Et de toute façon renvoyer un objet entity en dehors de son contexte c'est avoir une exception tôt ou tard, surtout quand tu as un serialiser après (wcf ou MVC d'ailleurs), sauf à bourrer le code d'annotations.

Après pour wcf, effectivement pas de souci niveau client (MS a été obligé de le rajouter pour gérer les servers legacy). Par contre niveau server, MS a l'air d'avoir abandonné : c'est pas dans la roadmap dotnet 5. A voir ce que fait la communauté, mais en tout cas pour les nouveaux projets depuis 2 ans je ne vois plus de wcf, mes clients (bancaire) partent sur du rest alors qu'ils poussaient avant le soap.

Oui bien sûr ça vient de là. Mais comme j'expliquais ça peut aussi bien venir de la partie "serialisation" des résultats, parce que le truc ramasse un graphe monstrueux et le contrat qui va avec, ou parce qu'il se vautre en allant chercher les propriétés associées, mais ça pourrait aussi venir de la partie "transport réseau" parce que le binding n'est pas configuré pour balancer tout ce qu'on lui demande même si par miracle la serialisation a réussi.
Si on veut vraiment les détails c'est côté serveur, pas client, qu'il faut choper l'exception.
Mais dans les deux cas la cause initiale est bien la même : on ne balance surtout pas de l'EF sur un service web.

Pour le fait de partir vers du REST (et surtout du JSON) c'est pas juste lié à WCF, c'est surtout les effets de mode qui font (à juste titre !) qu'on abandonne SOAP et ses  monstrueux XML (qui ont été très à la mode entre fin 90 et 2010 en gros) et qu'on associe souvent à tort à WCF (en tant que successeurs des ASMX) pour se tourner vers du JSON en REST. WCF n'est pas un protocole, juste une implémentation. Et WCF contient pleeeeeiiiin d'autres trucs que REST, SOAP, NetTcp, MSMQ dont certains que personnellement je n'ai *jamais* vus mis en oeuvre nulle part .
Pour du binaire ou de la communication "locale" REST/JSON n'est pas forcément adapté.
Je ne cherche pas à plaider pour WCF (qui a aussi pas mal de défauts, en tant que solution abstraite de haut niveau qui permet d'exposer plein de protocoles c'est une usine à gaz pour certaine chose), juste à situer un peu chaque chose.

Oui en effet quand je parle wcf je pense à soap. Et soap a ses avantages . Je pense notamment à quand tu as un bus pour communiquer, dans des environnements bien "corporate". On utilisait notamment du soap over jms. Pour le machine to machine ça reste pertinent aussi.

Pour moi la limite c'est surtout quand tu as un navigateur dans l'équation : obligé de mettre en place des serveurs rest intermédiaires pour communiquer avec la partie soap.

Merci pour vos réponses, c'est sympa
 
En effet, c'est un applicatif que je réécris, mais j'utilise des données déjà en place. Par contre en effet, les couches DAL / Service etc sont réécrites aussi donc je peux très bien utiliser d'autres technos.
 
J'ai décidé de partir sur du Framework côté serveur pour pas me faire chier (j'envoie ça avec WebDeploy sous IIS 8).
C'est des technos que je connais et maîtrise et ça me coûte pas cher de convertir mes requêtes Linq to Entities de la v2, vers des contrats dans mon service WCF.
 
Par contre côté client par contre, je voulais m'essayer au Core (tout en conservant WPF), avec une simple web référence connectée à mon service (contrairement à la v1, qui se connecte en direct à la BDD)

Et du coup ça a fait une différence par rapport à .Net ? J'aurais dit que pour du desktop / WPF ça ne faisait pas de différence à part un ou deux ajustements et l'installation des libs .Net core sur le poste client. Si tu as des retours sur l'import de dll natives en particulier ça m'intéresse, faudra un jour que j'y passe.

Pour info côté ASP.net core ça transforme pas mal par contre, mais en bien : avec le système d'IOC et d'initialisation tu gagnes énormément de temps.

A mon niveau, je n'ai pas trouvé de réelle grosse différence.
 
J'ai constaté une différence sur 2 points :
- la configuration du projet tout en JSON au lieu de XML (fichiers de config, fichiers CSPROJ...)
- les packages NuGet que j'ai l'habitude d'utiliser ne sont pas toujours dispos en version Core, donc il m'a fallu tester des alternatives à mes bonnes vieilles habitudes

Je confirme que ASP.Net Core m'a fait gagné beaucoup de temps sur des projets API, que ce soit sur l'architecture des services développer ou leur hébergement (Azure)

Les gars, je vais commencer à avoir besoin d'automatiser des sauvegardes de bases de données SQL Server.
J'ai déjà posé la question sur d'autres topics, mais je suis convaincu qu'il existe des choses toutes prêtes nativement dans SQL Server (via des jobs, non ?)
Comment vous faites-vous, pour ce besoin (petites bases de données, budget "amateur", serveur local, avec un gros NAS sur le réseau, un backup quotidien suffira pour le moment).

Oui tu fais des plan de maintenance via les jobs, backup full tous les jours et backup incremental à ton interval de temps qui correspond au rpo souhaité (ça peut être toutes les heures, demi heures etc).
Il vaut mieux sauvegarder sur un autre disque que celui du serveur, mais attention au réseau si tu passes par un nas, sauf si tu es en 10gb entre les deux ou si tu travailles directement avec des disques dans le serveur ou une baie San avec le réseau qui va bien.

Mais si les bases sont pas énormes ça va bien.
Pas oublier la replication ailleurs si tu veux un pra.