Reprise du message précédent :

 
https://github.com/DubyaDude/WindowsMediaController ?

Bon sang !
Je trouvais que des vieux trucs de 2012~2014 avec WMP12.
 
Merci, j'essaie !

 
Non
Mais je suis cependant content de t'avoir aidé
 
Cela dit le bénéficiaire de tes remerciements devrait surtout être l'auteur de cette chouette extension !  
Clairement comme tu l'as vu c'est bien mieux que le scaffolding en ligne de commande, y a plein d'avantages (hautement paramétrable, ne nécessite pas que le projet compile, pas besoin de faire un .bat pour réutiliser le truc...)

Des gens ont essayé Maui ? Je vais devoir initialiser un projet desktop, mais les alternatives .net ne me semblent pas super attirantes, wpf a l'air semi mort notamment.

J'aurais aimé savoir si les docs / composants sont matures,  vu que c'est neuf. Mais tout retour est bienvenu, même sur d'autres technos desktop

Bonne question ! Je suis curieux de ce qui est à la mode et pérenne en client lourd. Et qui n'impose pas des trucs pénibles du genre signature, store Microsoft, etc pour leur diffusion.

Ca fait des années que j'ai fait que du Web dans le cadre pro, du coup quand je fais du client lourd je me tourne vers les seuls trucs que je maitrise : Winform et parfois WPF.
Je ne parle pas des applis "web locales" genre Blazor, etc mais d'une vraie appli lourde.

Dans ton cas tu veux juste le support de Windows, RAF du cross platform ? C'est quand même très à la mode donc les frameworks "récents" en tiennent compte, ce qui les limite parfois par rapport aux bonnes vieilles technos pleines de possibilités et de contrôles en tout genre, même moribondes...

Ah bah j'ai exactement le même "profil" pour le développement .NET
Je fais que du web depuis 10 ans, j'ai totalement décroché depuis WPF pour le lourd, et ça m'intéresse bien de savoir ce qui est à la mode

Je n'avais pas un gros besoin de multiOS, et entre-temps j'ai vu que Maui est bien orienté mobile, avec support éventuel de desktop.

L'un dans l'autre le meilleur candidat semble être WinUI : bon look&feel, des libs de composants dispos, assez perf (fait en C++). Et surtout des devs sont trouvables, contrairement à MFC.

Et pareil, j'avais décroché du desktop pour le web, mais pour une fois j'ai un use case où on commence à atteindre ses limites : des grids de plusieurs centaines de milliers de lignes, avec des images, et en prime du multi fenêtre. Donc gros risque avec du JS.

Aidez moi à y voir clair SVP, en gros on a vu passer :
- WPF
- UWP (cross platform)
- WinUI (qui est un modèle de développement orienté desktop, mais pas adossé à UWP ou peut être que si, j'ai pas réussi à comprendre )
- MAUI Windows (cross platform)
Sans parler des trucs comme Uno ou Avalonia qui reposent sur UWP (ou autre ?) en venant les enrichir ?
Et des Xamarin, et technos "desktop web" comme Blazor.

Je suis largué en fait, heureusement qu'on peut toujours faire du Winform et du WPF

 
J'essaye un peut de répondre (c'est pas forcément bon, mais je dois pas être très loin je crois)
 
Windows Form : application "à l'ancienne", orienté évènement
WPF : application modernes, changement de paradigme dans la programmation des interfaces avec l'arrivée du MVVM
Silverlight : oublié dans ta lise, mais mort de chez mort. Nous pourrions le qualifier comme du WPF tournant dans un navigateur façon Flash mais sans l'accès aux API bas niveau du système (début de la portabilité)
UWP : c'était arrivé à l'époque où nous avions les Windows Phone, les premières Surface, le début de Windows Store avec application full screen via Windows 8 (MetroApp)... et Windows qui devait cohéxister. Ca a quand même permis de faire apparêtre la notion de Shared project dans Visual Studio
WinRT : remplacement de MetroApp (Win 8.1 ?) et surtout une alternative aux API Win32
Xamarin : portage du framework .Net et outils de builds sur de multiples plateformes
Mono : portage du framework .Net d'abord sur Linux puis d'autres plateformes
WinUI : bibliothèque d'interface avec du fluent design, agrégation / remplacement de WinRT et UWP
MAUI : principe de UWP mais via une évolution Xamarin.Forms et enfin compatible Mac desktop et Windows desktop
Blazor : Web UI (compatible desktop) - permet de faire du SPA avec les Framework .Net
(et j'ai pas parlé ni WebForm ni Asp.Net)
 
En version simple le grand historique des outils de développement graphiques chez Microsoft c'est :
1. WinForm
2. WPF (xaml) et AspNet
3. Blazor et MAUI
 
 
EDIT : perso je ne fais plus que de l'API Rest et du serverless sur Azure et AWS  
EDIT 2 (16/09/22): complément d'info sur WinUI, MAUI et Blazor

Bon résumé. Pour préciser, de ce que j'ai glané, WinUI remplace winrt et UWP en combinant leurs fonctionnalités (uwp n'est pas obligatoire par contre)

Tu peux aussi faire du desktop avec électron.net  

Oui c'est vrai. Je veux pas dire de bêtises mais c'est ainsi qu'est fait VS Code ?

C'est du électron tout court vs code, et en Typescript  

Bien résumé, mais ce sur quoi je me disais largué dans le sujet c'est surtout l'angle "Qu'est ce qui vit encore dans ce bordel, qui a un designer graphique digne de ce nom et qui n'est pas chiant à déployer (Store MS, etc)" .  
A moins que ça n'existe même plus un truc qui remplit tous ces critères, hors techno legacy
 
Les trucs morts genre Xamarin ou Silverlight c'est facile de s'en souvenir, le piège c'est plutôt de trouver ceux qui Microsoft n'a pas encore buté
 
Bon, la mode du moment c'est WinUI avec MAUI mais en général les trucs multiplateforme c'est l'enfer niveau outils.

Il fut un temps j'ai fait 2~3 trucs en GTK# aussi

Bon... ce serait à refaire je serais resté sur du winforms

Et personne qui parle de winJS

j'avais oublié ça tient
On peut aussi parler de BabylonJS !

Donc ça veut dire qu'avec MAUI, on fait de l'UWP like, avec Xamarin ?
Ca peut être intéressant de le cadre d'un projet multi plateforme (iOS + Android + Windows) pour le coup, en full C# .NET !

Ca se diffuse / se betateste / s'installe comment côté Windows ? Via le MS Store (ça produit des .exe ?) ?

C'est une bonne façon de le résumer

Perso, je préfère faire appel à des développeurs iOS et Android pour le multi-platforme, rien que pour avoir une intégration UX correcte propre à chacune des plateforme. En plus, ça permet de paralléliser les développements

Pour Android, ça se debug via un emulateur https://docs.microsoft.com/en-us/do [...] n-emulator
Pour iOS, il y a un simulateur https://docs.microsoft.com/en-us/do [...] -simulator . Il ne semble pas qu'il y ai besoin d'avoir un téléphone à la pomme sous la main

Merci beaucoup

On me dit dans l'oreillette que MAUI est une évolution de `Xamarin.Forms` avec comme changement majeur la possibilité de target des plateformes tel que Mac desktop et Windows desktop. Les habitués de Xamarin.Forms ne sont normalement pas perdus.
Je n'étais donc pas loin dans ma compréhension
 
 
Et moi, pendant ce temps là, je suis entrain de suivre un module de formation EF Core car je suis un peu largué... mais pas suffisamment largué pour comprendre qu'ils ont fait de la merde sur le projet que je viens de rejoindre.

Ah, ça ça m'intéresse.
EF Core je l'ai pris au vol tout seul et je suis presque sûr d'avoir fait 80% de merdier.
Tu pourrais (légalement, bien sûr) me partager quelques infos, voire le support de formation, si ça ne t'embêtes pas ?
 
En fait toutes la plateforme Core, de l'ASP .NET Core à EF Core j'ai vraiment l'impression que tout le monde la subit un peu sans trop maîtriser le truc... du coup y a toujours 70 façons de faire chaque concept, et parfois certains patterns paraissent meilleurs mais te bloquent pour la suite ...

J'ai un abonnement Pluralsight, je fais presque toutes mes formations avec, du coup ça va être difficile de te partager quoi que ce soit
Sinon la doc MS est pas dégueux pour EF Core : https://docs.microsoft.com/en-us/ef/core/

Perso je suis pas fan des ORM (autre que Dapper) et ai horreur du code-first. La raison est simple : je me retrouve systématiquement sur des projets avec des problèmes de performances dès qu'un ORM est utilisé (généralement EF ou NH). Pour moi c'est bon pour du prototyping ou des applications non critiques et à faible trafic

 
Une bonne stack Autofac/Dapper/Automapper y'a rien de tel pour garder le contrôle  

Et encore Autofac, on peut facilement s'en passer maintenant (sauf utilisation très spécifiques)
Dapper est nécessaire que pour de la base de données relationnelle.
Chez mon précédent client, nous étions sur une architecture event-driven construite autour de cloud functions (AWS Lambda) avec la data dans des tables nosql (AWS DynamoDB) => quelques utilisations d'Automapper, mais à la marge uniquement.

Ok merci bien

Il faut garder en tête qu'EF core a bien progressé niveau perfs. En mode no tracking, la différence par rapport à dapper s'est bien réduite (5% de mémoire sur des benchs officiels avec .net 6).

Une stratégie commune, surtout en cas d'utilisation de CQRS, est d'utiliser dapper pour la lecture et EF pour les écritures : on obtient ainsi le meilleur des mondes.

En fait ce que je constate très souvent se sont des problématiques de traitement de la données via de nombreuses jointures. Déjà on fait souvent des A/R pour rien entre l'app et l'instance SQL, puis on se retrouve avec des requêtes générées dégueulasses. Bon alors oui c'est un million de fois mieux maintenant qu'il y a 10 ans ce qui est généré. Par contre l'un des gros soucis dès que l'on quitte le simple select CRUD c'est que les plans d'exécutions ne sont pas prédictibles sur ce type de requêtes provenant d'ORM. C'est très souvent des traitements qui devraient s'exécuter au sein même de l'instance SQL, dans une proc stock donc. Après encore faut-il savoir écrire une proc de façon optimale et surtout savoir l'observer pour l'optimiser.
Avec une approche CQRS, j'ai tendance a privilégier une transformation de la données pour avoir une lecture sur une base noSQL (A défaut, des tables à plat)

Le truc dont 99% des entreprises se tamponnent bien profond...
Si c'est pour retrouver du métier dans les SP et dans le code appli, au secours ....

Clair, rien que le suivi des modifications des SP dans la majorité des boîtes fait peur...

Étonnamment c'est pas mon expérience. Le gros de mes missions ces 15 dernières années sont liés à la monétique, au contrôle réglementaire (finance et comptabilité), à l’industrie (ordonnancement de systèmes de calcul haute dispo faible latence)
Encore une fois si tu bosses sur des services internes (du tooling par exemple) où à faible trafic, ouais tu peux t'en foutre. C'est une question de contexte.

Séparation des domaines : comme pour tout, faut choisir où on met son code et avoir un contrôle pour s'assurer que c'est respecté (via revue de code par exemple), et avoir des développeurs qui maitrise le paradigme de programmation ensembliste. Dans ce cas il ne faut que de l'ordonnancement côté C#, sinon c'est horrible.

Comme le code, suffit de stocker la source des proc dans Git, je vois pas où est le soucis ?
Après se sont des problématiques de CI-CD, avec suivi de versions déployées mais il existe de nombreux patterns pour ça.

Je continue de suivre ma formation EF Core 6, ça a bien changé depuis EF classique et du coup je revois un peu ma position dessus :
-> si le SQL généré par EF se trouve être pourri, c'est globalement juste que ça reste facile de faire de la merde pour un développeur qui ne se pose aucune question en code-first.
 
Bon par contre j'ai une question pour vous. Là pour un client je bosse sur un projet pas des plus propres (reprise d'un POC fait par des stagiaires). Dans la solution, j'ai plusieurs dBContext. Déjà ça c'est discutable je trouve, surtout qu'ils target la même base (et le même schéma)
-> On est d'accord qu'une entité ne doit être déclarée que dans un seul modelBuilder (OnModelCreating) d'un dbContext ? S'il se retrouve dans plusieurs contextes, on peut se retrouver avec une incohérence de schéma qui s'écrasent l'un-l'autre ? J'ai peur de voir ce que ça va faire de déclencher une migration, sachant qu'ils n'en ont pas pour le moment.

Si les préco sont suivies et que c'est bien SQL Server (ou tout autre SGDB supporté) qui gère les PK des tables, à priori t'es à peu près safe.
Par contre si vous avez fait les manouches "qui savent faire" et que c'est les dbContext qui gèrent ça, là ça pue oui

Je crois qu'EF autorisait la seconde hypothèse, mais qu'EF Core impose de déléguer ça au SGDB.

J'ai regardé un peu plus en détail, globalement on a des QueryFilter, ça ne devrait pas poser de soucis ça. Au pire, suivant le context utilisé, les filtres sont pas les mêmes et c'est ce qui est attendu je crois.
 
Par contre, j'ai repéré aussi des "HasColumnType" dans le modelBuilder, et c'est là que ça peut poser problème : j'ai la property d'une entité qui est déclarée comme "text" dans un contexte, et comme "jsonb" dans un autre (on target du Postgresql)
 
EDIT
J'ai aussi repéré des modèles qui sont pas ou plus utilisés, mappé sur des tables à l'arrache qui ne sont pas non plus utilisés et qui semblent avoir été supprimées à la main dans la base de dev  
J'ai généré les DbContext diagrams avec EF Core Power Tools, on est loin de matché ce que j'ai vu dans la DB. J'ai déjà mal au crâne

Bon, à priori ces 2 types sont compatibles mutuellement (je ne connais pas Postgre, mais je ne vois pas ce qui pourrait poser problème dans la conversion json > text, pour peu que l'encodage soit propre).

Techniquement ils sont compatibles (sauf si on crée des requêtes qui exploitent le json, on peut lire le contenu a la volée en Postgres en navigant dedans), mais ça veut dire qu'une migration d'un contexte va changer la colonne en type "text", l'autre migration va changer en "jsonb". Ca sera celui qui aura été run en dernier qui aura le dernier mot. C'est juste très moche

aaaah oui, en effet
C'est moins grave qu'un int vs bigint par exemple, mais ouais ça ajoute quand même un peu de flou

Pour le fait d'avoir plusieurs dbContext, pour moi c'est normalement utilisé dans le but de couvrir plusieurs domaines, voir target des bases différentes. Il y a d'autres utilités ? Ca ne me semble pas être une approche des plus standards

Moi je me sers régulièrement de plusieurs dbContext dans mes projets, mais c'est, comme tu le dis, pour accéder à plusieurs bases de données distinctes, qu'on veut garder séparées.
 
Sinon, pour le fait de connecter plusieurs dbContext à une seule base de données, je peux tenter d'imaginer 2 trucs :
- 2 chaines de connexions différentes pour la même base de données, donc potentiellement une "mini" gestion de droits pour l'utilisateur ciblé ?
- un fonctionnement un peu analogue aux vues, avec une fonction métier qui regroupe 2~3 tables et une autre fonction qui regroupe 2~3 autres tables + quelques une en commun ?

dites vous avez des sites/twitters/autres pour monitorer les problemes sur azure ?
 
ya une panique au taf car visiblement les DNS sont en mode loterie et ça foire sur 50% des calls, et j'aimerais être sûr que ça vient pas de chez azure avant de me tirer une balle

Tu as cette page : https://status.azure.com/fr-fr/status
et sinon Azure Service Health sur ton portail
ensuite, sur presque chaque ressource Azure, tu as accès à un menu "Resource health" qui peut aider à analyser, ainsi que "Diagnose and solve problems" qui fait un certain nombre de check sur ta ressource et son setup