Discussion :

[star]

Pourriez-vous m'expliquer comment Microsoft procède à la diffusion des correctifs de bugs du .NET Framework ?
Est-ce effectué au fil de l'eau intégré aux Windows Update au fur et à mesure des mises à jour ?
Ou faut-il attendre les nouvelles releases du Framework 4.7.x ?
Merci
.

[Pol63]

Un programme .net cible un framework (genre 4.6)
Et quand ils ont une mise à jour de celui ci c'est genre 4.6.1 et windows update fait le reste
Et j'ose imaginer que c'est automatiquement le nouveau qui est utilisé.

Mais il y a très peu de bugs dans le Framework conventionnel

[star]

Sauf que le peu de bugs qu'il puisse y avoir est dans certains cas très bloquant... Comme ici : https://www.developpez.net/forums/d1...a/#post9450831

[DotNetMatt]

Yes, avec Core ca risque de changer un peu car la plupart des assembly "systeme" sont disponibles via NuGet, donc il suffira de mettre a jour ses packages. A voir ce qui va se passer de ce cote !

Sinon pour ton probleme, vu que tu n'as receuilli aucun vote sur ton bug, je doute que ca soit la priorite de Microsoft En effet plus il y a de votes, plus c'est considere comme genant et impactant pour la communaute.

Comme indique sur ton autre post, pourquoi ne pas changer de technique et utiliser MVVM ?

- Les DataTables, DataSet, etc. ca fait partie de la prehistoire de .NET. C'etait utile a l'epoque ou les listes (IEnumerable, ICollection, IList, etc.) n'existaient pas. Ces classes viennent avec un certain overhead du a toutes les fonctionnalites embarquees par defaut et que tu n'utilises probablement pas (je dis bien, probablement, car je ne connais pas ton projet).
- WPF s'utilise avec des patterns, comme MVVM ou encore Prism. Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF...

Bref, pour ton bug, la patience surement sera ton meilleur allie.

[star]

Merci DotNetMatt pour ta contribution à ce post.

Tu as sans doute raison en disant que ADO.NET est d'un autre temps, sans doute un peu comme moi. Pour tout te dire, je me suis réellement adonné au .NET à partir de l'année dernière, bien que ma première approche remonte en 2012 avec VS2008 après les MFC. Si l'on reprend l'historique du .NET Framework et du C#, sa mise sur le marché date de l'année 2000, donc il y a 16 ans. Pas si préhistorique que cela à comparer à d'autres technos, comme par exemple, le langage Cobol utilisé avec le moniteur transactionnel DTF qui tournait sous GCOS6 - Bull DPS6000. On parle alors d'y a 30 ans avant même l'invention de l'IBM PC. Le grand frère, le BULL DPS8000 sous GCOS8 est toujours en exploitation, me semble-t-il.

Non, à mon goût ADO.NET est une bonne API pour la gestion des données, efficace et complète, qui épargne l'écriture de code par le développeur. Je ne connait pas encore assez bien le pattern MVVM, mais c'est ce que je compte aborder assez rapidement maintenant. Toi qui manifestement maitrise ce pattern ainsi que ADO.NET, peux-tu dire lequel des deux demande plus d'écriture de code pour des fonctionnalités minimalistes identiques ?

Sur ta dernière remarque "Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF", je ne suis pas tout à fait d'accord avec toi. Mon projet de test qui reproduit une interface utilisateur de type Maitre/Détails avec l'utilisation de contrôles DataGrid WPF en lieu et place de contrôles DataGridView WinForms, et d'ADO.NET pour l'accès aux données, reste assez simple à réaliser et pas du tout hasardeux. Toutes les fonctionnalités d'affichage, de mise à jour CRUD, de validation et d'interface avec la source de données sont reproduites avec très peu de différences dans l'écriture du code. Je ne sais pas encore si avec le pattern MVVM on peut très bien en faire autant et aussi facilement. J'ai juste ce bug avec l'API WPF (voir mon autre post pour une présentation du bug) et qui ne concerne nullement ADO.NET, je tiens à le préciser.

Pour ceux que cela intéresse, un lien sur mon projet de test : https://drive.google.com/file/d/0B64...ew?usp=sharing
Mon feedback au Support Microsoft : https://connect.microsoft.com/Visual...wupdated-event
Le compteur commence à grimper. Allez-y voter (:

J'en profite pour te demander s'il te serait possible de me suggérer un lien sur un bon tutorial portant sur le pattern MVVM et une référence de livre sur le sujet ? Que veux-tu difficile de changer passer un certain âge. De mon époque Internet n'existait pas (il n'y avait que le minitel rose) et nous n'avions alors que la documentation officielle en langue anglaise, s'il vous plait.
.

[DotNetMatt]

Tu as sans doute raison en disant que ADO.NET est d'un autre temps, sans doute un peu comme moi.

Attention je n'ai pas dit qu'ADO.NET etait d'un autre temps, je parle juste des classes DataSet, DataTable, etc. ADO.NET est toujours utilise aujourd'hui et je confirme que c'est une tres bonne API, pas de souci de ce cote-la. Les classes Dataxxx sont juste des "modules" qui utilisent l'API ADO.NET sous le capot.

Ce qu'il faut retenir c'est qu'a l'epoque ou .NET est sorti (on parle des annees 2000 comme tu l'as indique), les listes d'objets n'existaient pas. Pour pemettre de gerer cela, Microsoft avait alors mis au point ces fameuses classes DataSet, DataTable, DataView... Mais depuis, Microsoft a publie d'autres mecanismes de gestion de listes d'objets plus simples a utiliser et sans tout l'overhead genere par les vieilles classes. On peut utiliser LinQ sur ces listes d'objets pour les manipuler. LinQ equivaut a un pseudo SQL en C# / VB.NET.

Ces nouvelles classes sont basees sur les interfaces IEnumerable, ICollection, IList, etc. On pourrait les comparer a des Array mais avec des fonctionnalites un poil plus evoluees, mais en restant tres light compare aux classes Dataxxx. Avec ces nouvelles classes, c'est a toi d'utiliser l'API ADO.NET, l'avantage etant que tu controles finement ce que tu fais, et que tu ne codes que ce dont tu as besoin.

Pour tout te dire, je me suis réellement adonné au .NET à partir de l'année dernière, bien que ma première approche remonte en 2012 avec VS2008 après les MFC. Si l'on reprend l'historique du .NET Framework et du C#, sa mise sur le marché date de l'année 2000, donc il y a 16 ans. Pas si préhistorique que cela à comparer à d'autres technos, comme par exemple, le langage Cobol utilisé avec le moniteur transactionnel DTF qui tournait sous GCOS6 - Bull DPS6000. On parle alors d'y a 30 ans avant même l'invention de l'IBM PC. Le grand frère, le BULL DPS8000 sous GCOS8 est toujours en exploitation, me semble-t-il.

Effectivement je devrais mesurer mes propos par rapport a l'histoire de l'informatique

Non, à mon goût ADO.NET est une bonne API pour la gestion des données, efficace et complète, qui épargne l'écriture de code par le développeur. Je ne connait pas encore assez bien le pattern MVVM, mais c'est ce que je compte aborder assez rapidement maintenant. Toi qui manifestement maitrise ce pattern ainsi que ADO.NET, peux-tu dire lequel des deux demande plus d'écriture de code pour des fonctionnalités minimalistes identiques ?

C'est probablement MVVM qui va te demander un peu plus travail, mais au final tu auras une application mieux structuree et decoupee. Apres, vaut-il mieux avoir une application "brouillon" (je met les guillemets) ou une application plus professionnelle, ca depend de ton projet, du budget, des delais, de la strategie IT, etc.

Au final pour resoudre le genre de probleme que tu rencontres, tu finiras peut-etre par ecrire autant de code, ou par perdre enormement de temps pour trouver un paliatif. Tu es le seul et meilleur juge pour determiner ce qu'il faut faire.

Sur ta dernière remarque "Il peut etre hasardeux de vouloir reproduire exactement du code WinForms en WPF", je ne suis pas tout à fait d'accord avec toi. Mon projet de test qui reproduit une interface utilisateur de type Maitre/Détails avec l'utilisation de contrôles DataGrid WPF en lieu et place de contrôles DataGridView WinForms, et d'ADO.NET pour l'accès aux données, reste assez simple à réaliser et pas du tout hasardeux. Toutes les fonctionnalités d'affichage, de mise à jour CRUD, de validation et d'interface avec la source de données sont reproduites avec très peu de différences dans l'écriture du code. Je ne sais pas encore si avec le pattern MVVM on peut très bien en faire autant et aussi facilement. J'ai juste ce bug avec l'API WPF (voir mon autre post pour une présentation du bug) et qui ne concerne nullement ADO.NET, il faut le préciser.

En effet, le bug concerne le WPF j'en ai bien conscience, mais il peut etre induit par l'utilisation des classes Dataxxx, qui je le repete ne sont pas l'API ADO.NET elle-meme.

Pour ceux que cela intéresse, un lien sur mon projet de test : https://drive.google.com/file/d/0B64...ew?usp=sharing
J'ai le compteur qui commence à grimper. Allez-y voter (:

Merci de partager ca ! Si tu ne connais pas, tu peux utiliser GitHub pour heberger gratuitement tes projets en ligne en Open Source (differentes licenses sont disponibles). L'avantage c'est que ca te permet de beneficier d'un gestionnaire de code source gratuitement, tout en t'offrant de la visibilite dans la communaute. Voici un exemple de projet heberge : https://github.com/joeaudette/clouds...Web.Navigation

J'en profite pour te demander s'il te serait possible de me suggérer un lien sur un bon tutorial portant sur le pattern MVVM et une référence de livre sur le sujet ? Que veux-tu difficile de changer passer un certain âge. De mon époque Internet n'existait pas (il n'y avait que le minitel rose) et nous n'avions alors que la documentation officielle en langue anglaise, s'il vous plait..

Il y a pas mal de tutos sur notre communaute : Windows Presentation Foundation. Si tu remontes tout en haut de la page, tu verras qu'il y a aussi des tutos sur pas mal de sujets autour de C#, incluant un cours complet sur C# : Cours complet pour apprendre C#

[EDIT} Voici un tuto MVVM en Francais : Comment tirer efficacement parti des avantages de WPF tout en gardant une application maintenable et testable ?

A noter, il n'y a pas que MVVM, il existe aussi MVP ou encore Prism, voire meme MVVM Light....