Passage de VS 2005 à VS 2019

Bonjour,

Mon application fonctionnait en C# sous Visual Studio 2005.
Nous sommes passés à Visual Studio 2019, je rencontre quelques dysfonctionnements.
De manière complètement aléatoire l'application de répond plus, il n'y a plus d'autres moyen que le CTRL-ALT-SUPPR
En fouillant dans les propriétés de l'appli, j'ai vu qu'elle utilisait en Framework cible:
.NET FrameWork 4
Avec des postes en Windows 10, je pense qu'il faut utiliser un FrameWork plus récent, il me propose le choix jusqu'à .NetFrameWork 4.72,
et la possibilité d'installer d'autres FrameWorks

Tout ceci m'étant étranger, y a t-il intérêt ou danger à monter le plus haut possible le FrameWok?

Merci.

ca ne changera pas grand chose, on peut choisir le framework qu'on veut, et tout ce qui fonctionne dans le 4 est censé fonctionner pareil dans les suivants

si tu arrives à reproduire le problème en exécutant depuis visual studio tu peux faire pause dans celui ci et chercher quel thread est dans une boucle infinie

Bonjour Pol63,

Je ne pense pas que ce soit un problème de boucle infinie.
L'application a parfaitement fonctionné pendant des années avec VS 2005, et le problème surgit de manière complètement aléatoire à n'importe quel endroit de l'appli.

J'ai installé Visual Studio 2019 sur mon poste.
J'ai ouvert le code de mon appli.
Visual Studio a mouliné un moment sans doute pour convertir l'appli.
J'ai compilé l'appli et distribué l'exécutable.

Tout a bien marché partout, et puis de temps en temps ça se bloque sans aucun message d'erreur.

A+

Je pense c'est VS 2019, sur une des apps sur laquelle je bosse il y a des blocages de quelques secondes quand c'est pas un freeze complet de vs ...

normalement il faut retester avant de redéployer
à part vs 2005 normalement ca ne pose aucun soucis de passer à un vs plus récent, mais de 2005 à supérieur ca peut poser des problèmes
par contre c'est plus des problèmes de compilation normalement, à l'exécution il n'est pas censé y avoir de différences
après si tu étais sur un framework plus ancien (2 ou 3.5) il peut y avoir quelques différences même si elles sont rares

par contre le principe d'un bug c'est qu'il peut apparaitre du jour au lendemain, après c'est vrai que si ca a fonctionné pendant longtemps sur l'ancien exe et que seul le nouveau présente ce type de problème on aurait tendance à penser que ca vient de là...
y a t il du multithreading dans ton appli ?
des IO (type base de données ou autre) sur le thread principal ? y a t il du monitoring des temps d'exécution (genre exécution de requete ou autre) ?

Citation:

---

Envoyé par HENRYC

Mon application fonctionnait en C# sous Visual Studio 2005.
Nous sommes passés à Visual Studio 2019, je rencontre quelques dysfonctionnements.

---

Le dysfonctionnement n'est pas lié à Visual Studio en lui-même (qui n'est qu'un IDE). Par contre, le compilateur a beaucoup changé. Complètement refondu et de nombreuses optimisations.

Citation:

---

Envoyé par HENRYC

De manière complètement aléatoire l'application de répond plus, il n'y a plus d'autres moyen que le CTRL-ALT-SUPPR

---

Vu le comportement décrit, à savoir que tout fonctionnait avant et le comportement totalement aléatoire du problème, je pense qu'il s'agit d'un bug déjà présent mais qui ne se révélait pas auparavant. Cela ressemble beaucoup à un problème de concurrence (l'application est-elle multithread ?). Un changement de compilateur, donc des optimisations mises en oeuvre, peut faire apparaitre des bugs qui n'apparaissait pas avant. C'est le type de bug qui peuvent aussi apparaitre en mode release et pas en mode debug (ou inversement !).

Citation:

---

Envoyé par HENRYC

En fouillant dans les propriétés de l'appli, j'ai vu qu'elle utilisait en Framework cible:
.NET FrameWork 4
Avec des postes en Windows 10, je pense qu'il faut utiliser un FrameWork plus récent, il me propose le choix jusqu'à .NetFrameWork 4.72,
et la possibilité d'installer d'autres FrameWorks

---

Je doute fortement que cela soit la cause. Les rares changements effectués sur les APIs par Microsoft sont des changements nécessaires pour des raisons de sécurité. Ce qui se traduit généralement par la génération d'une exception. Le comportement décrit ne semble pas vraiment aller dans ce sens. Mais bon, sans le code de l'application, difficile d'en dire plus !

Citation:

---

Envoyé par HENRYC

Tout ceci m'étant étranger, y a t-il intérêt ou danger à monter le plus haut possible le FrameWok?

---

Y a-t-il un danger ? Tout dépend de ce que l'on appel danger. D'un point de vue sécurité, non. Au contraire même. Du point de vue du bon fonctionnement de l'application, oui, il y a un risque, qui, même s'il est minimum, n'est pas nul. Pour l'instant, je vous invite plutôt à conserver le même framework cible qu'avant (quitte à l'installer sur le poste) le temps de résoudre ce problème de freeze (inutile de cumuler des problèmes de sources différentes).

L'idéal serait de pouvoir deboguer le programme quand il freeze. Je vois deux solutions "simple" :

• soit le programme est lancé dans Visual Studio, et dans ce cas là, faire une "pause" au niveau du programme et regarder où en est l'exécution, regarder la pile d'appel, éventuellement faire un peu de pas à pas pour voir s'il bloque ou s'il boucle de manière infinie
• soit le programme est lancé de manière indépendante, et dans ce cas là, il est possible d'ouvrir Visual Studio, de l'attacher à un programme s'exécutant déjà pour ensuite le déboguer.

Les autres solutions que je vois font plus ou moins la même chose, mais en utilisant des techniques plus complexe (mais ne nécessitant pas l'installation de visual studio sur la machine en question), comme la création d'un dump de la mémoire du process par exemple pour une analyse ultérieure...

Bonjour à tous et merci pour votre concours, même si pour le moment on n'avance pas beaucoup ( mais ça viendra !).
Un peu d'historique de mon problème.

L'application est un ERP complet pour gérer une entreprise (Achats, ventes, production, comptabilité), bref tout sauf la paie.
Elle a fonctionné sans problèmes depuis 2007 sauf quelques bugs que j'ai corrigé au fur et à mesure.
Ce qui veut dire que ce n'est pas gourmand en ressource. Créer des commandes, faire des factures ne nécessite pas de gros besoins.
La base de données était sous SQL-Server, le serveur n'est qu'un serveur de données. Tous les calculs se font en local sur le poste, le serveur n'est là que pour répondre à des requêtes SQL.
Pas de multithreading, j'utilise des Forms pour la saisie de données et envoie de requêtes SQL au serveur. Bref, il ne s'agit pas d'envoyer une fusée sur la lune.

Juin 2019, nous décidons d'évoluer vers Visual Studio 2019, Windows 10 sur les postes, et MY-SQL au lieu de SQL Server.

Je commence par convertir l'ERP en Visual studio 2019. Je fais tous les tests, dont des tests de charge.
Le programme le plus gourmand consiste à calculer les besoins en achat, sous-traitance, main d'oeuvre, occupation des postes de travail à partir d'un plan de production.
J'ai testé à plusieurs reprises, un plan de production bien chargé!
Je l'ai lancé en même temps sur 5 machines différentes, alors qu'habituellement un seul poste fait cette opération. Tout s'est bien déroulé.
Nous avons donc tourné quelques mois dans cette config VS 2019 et Windows 10, pour préparer la migration vers MY SQL

Mars 2020 , la migration MY SQL est terminée, le refais une batterie de tests, tout marche, on passe en prod.
De temps en temps sur un seul poste on a un blocage, purement aléatoire, à n'importe quel endroit de l'appli.
Je vérifie toutes les connexions, change le PC, rien à faire! Et ensuite le problème apparait sur d'autres postes, à des moments tout à fait banaux, comme le simple affichage d'une fiche article!

Et là, je me dis que ce n'est pas possible que cela vienne du programme, et je ne dis pas cela parce que c'est moi qui l'ai écrit! (lol).

D'avance merci.

Citation:

---

Envoyé par HENRYC

Juin 2019, nous décidons d'évoluer vers Visual Studio 2019, Windows 10 sur les postes, et MY-SQL au lieu de SQL Server.

---

Si on ne nous dis pas tout on peut oublier des pistes ! MySQL et SQL Server sont très différents dans la gestion des requêtes concurrentes, et notamment des verrous. La lecture d'une table peut être bloquée car elle est mise à jour dans une autre transaction par exemple. Lorsque le prochain freeze se produit, je vous invite à regarder au niveau de MySQL s'il n'y a pas une requête de bloquée.

Au passage, le choix de MySQL est un peu surprenant dans le cadre de l'usage d'un ERP. C'est un SGBD qui est malheureusement connu pour présenter des problèmes (corruption de données lors de crash, backup non cohérant sans précautions, etc... sans aborder les problèmes de performances par rapport à d'autres SGBD). Si cela ne pose pas de gros problème pour des blogs, site vitrine, etc... cela l'est plus dans le cadre d'une utilisation centrale comme un ERP. Dans ce cas, et pour rester dans du libre, je recommande plutôt Postgresql.

D'accord, ne négligeons aucune piste.

J'ai connu par le passé des systèmes un peu pourave qui bloquaient toute la table article parce qu'un utilisateur était en mode modification sur un article!

L'appli fonctionne ainsi:
A chaque ouverture d'une Form, on ouvre une connexion MY SQL entre le PC et le serveur
L'appli lit les données, les affiche dans des variables locales, ferme le datareader, et garde la connexion ouverte.
S'il faut lire d'autres données je me sers de la connexion ouverte, ouvre le datareader , récupère les données, et referme le datareader.
Les données ne sont donc enregistrées que si l'utilisateur valide la saisie. (Vieux souvenir des systèmes pouraves cités plus haut).
La connexion est fermée à la fermeture de la fenêtre.

Le risque d'interblocage intervient si 2 personnes mettent à jour la même donnée en même temps ( le temps d'un Update).
On a une quinzaine de postes, chacun ayant son job, il y a vraiment peu de chance que 2 personnes fasse la même chose en même temps.

Par contre ce que j'ignore:
Que ce passe t-il lorsqu'un utilisateur lit plein de données en rafale dans une table, qu'un autre utilisateur lit ou met à jour?
Peut-on savoir avant de faire un update, ou une simple lecture que la table est verrouillée ?

Merci.

quelle est la taille de la base de données ? est-ce bien indexé ?
une base de données ca grandit dans le temps, et arrivé à un moment le comportement peut changer, des requetes peuvent changer radicalement leur temps d'exécution
le mieux serait de voir si tu peux enregistrer ce qui se passe à ce niveau, pour sql server je sais qu'il y a sql server profiler où on peut lui dire par exemple d'enregistrer toutes les requetes qui dépassent quelques centaines de millisecondes ...
concernant mysql je ne sais pas

ce qui est sur c'est que quand une appli freeze c'est que du code est en cours d'exécution quelque part sur le thread principal
aussi de nos jours on essaye de mettre de l'asynchrone quand on fait quelque chose dont le temps peut potentiellement dépasser quelques centaines de ms

s'il n'y a qu'un poste concerné ca peut aussi être une défaillance au niveau de la carte réseau, c'est rare mais ca peut arriver, et là toute connexion peut devenir instable et bloquer un certain temps

salut,

Je pencherais vers le connecteur pour Mysql en fonction de la version du framework.
En 4 tu as System.Data.Mysql et en 5 tu as Microsoft.Data.Mysql (préconisé).
Je vérifierais aussi le pool de connexion (trop connexion ouverte et pas fermer).
En plus MySql est chiant avec son regroupement par defaut.

Citation:

---

Envoyé par HENRYC

A chaque ouverture d'une Form, on ouvre une connexion MY SQL entre le PC et le serveur
L'appli lit les données, les affiche dans des variables locales, ferme le datareader, et garde la connexion ouverte.
S'il faut lire d'autres données je me sers de la connexion ouverte, ouvre le datareader , récupère les données, et referme le datareader.
Les données ne sont donc enregistrées que si l'utilisateur valide la saisie. (Vieux souvenir des systèmes pouraves cités plus haut).
La connexion est fermée à la fermeture de la fenêtre.

---

Donc, si je comprends bien, la connexion à la base de données est ouverte tant que la Form est ouverte. C'est un peu risqué, dans le sens où la connexion est ouverte beaucoup de temps pour faire 2 ou 3 requêtes de lecture à l'ouverture de la forme et éventuellement une requête de mise à jour à la fermeture de la Form sans rien entre les deux. Une grande partie du temps de la connexion ne sert donc... à rien !

Il est plutôt conseillé dans ce cas de fermer la connexion une fois que les données sont lues (toutes les données, il n'est pas utile d'ouvrir une connexion par requête) et d'en rouvrir une pour effectuer la mise à jour.

Cela facilitera grandement le travail du SGBD derrière, qui au lieu d'avoir une quinzaine de connexion longue simultanée n'aurait qu'une à deux connexion courte à gérer. C'est d'autant plus intéressant que les mécanismes de verrouillage (qu'il soit de table, de colonne ou de ligne) sont associées à une connexion. Si la connexion est fermée, les verrous sont automatiquement libérés.

Citation:

---

Envoyé par HENRYC

Le risque d'interblocage intervient si 2 personnes mettent à jour la même donnée en même temps ( le temps d'un Update).
On a une quinzaine de postes, chacun ayant son job, il y a vraiment peu de chance que 2 personnes fasse la même chose en même temps.

---

Pas forcément. Le verrouillage est un sujet complexe et dépend fortement du SGBD. Sans une très bonne connaissance du SGBD en question et un examen minutieux du plan d'exécution d'une requête, je ne parierai pas sur un verrouillage d'une seule ligne car je n'accède qu'à une seule ligne. Il peut arriver des cas où la modification d'une ligne entrainera le verrouillage de toute une table (présence de trigger, de vue matérialisée, etc...). Je ne connais pas suffisamment MySQL pour savoir comment il réagit.

Citation:

---

Envoyé par HENRYC

Par contre ce que j'ignore:
Que ce passe t-il lorsqu'un utilisateur lit plein de données en rafale dans une table, qu'un autre utilisateur lit ou met à jour?
Peut-on savoir avant de faire un update, ou une simple lecture que la table est verrouillée ?

---

La encore, tout dépend du SQBD. Si l'utilisateur exécute 100 requêtes de lecture sur la même table, le SGBD peut très bien décider de donner un lock exclusif à cet utilisateur le temps qu'ils fassent ses lectures, pouvant bloquer de ce fait les mises à jour. D'où mon conseil ci-dessus de fermer la connexion. Fermer la connexion indique au SGBD que tout est terminé et qu'il peut donc libérer toutes les ressources associées, notamment les verrous.

Bonjour à tous,

Pour répondre à vos commentaires

Taille de la base de données 2.5 Go
Pas de trigger.
Pas de relation Table mère - table fille, qui empêcherait par exemple de supprimer un entête de commande avant de supprimer les lignes.
(J'ai perdu le nom de cette option, mes cours base de données remontent à .... 35 ans)

Les clefs sont définies de manière très classique, c'est le numéro de facture, commande etc .. qui détermine la clef unique de la table.
et le couple Numéro + ligne détermine la clef unique des tables de lignes de facture, commandes, ordre de fabrication etc..
La grande majorité des requêtes se fait sur la clef de la table, quelquefois, mais rarement sur un champ non clef.

La connexion reste effectivement ouverte pendant tout le temps de l'ouverture de la Form.
Comme un utilisateur peut empiler l'ouverture de Forms les unes derrières les autres il peut effectivement avoir 5 à 6 Forms ouvertes.
Dans le pire des cas 6 connexions x 15 postes = 90 connexions à gérer, je les regardent travailler, on n'y est jamais.

Notre serveur a 18 mois, il peut gérer. Il a été prévu pour héberger en multi-machines plusieurs base de données, ainsi qu'un site internet
Nous avons fait des mesures de charge, il y a largement de quoi faire, et pour le moment il ne gère qu'une seule base de données.

Je vais d'abord paramétrer l'appli pour lui faire utiliser Framework 6, et on verra bien.
Refermer les connexions après chaque lecture demanderait trop de boulot. Donc si ce n'est pas indispensable on va éviter.

Merci pour votre concours, je vous tiens informés.

Bonjour,

Je suis allé dans les propriétés de l'appli, pour le FrameWork cible, j'ai le choix jusqu'au Net FrameWork 4.7.2.
Il me propose d'installer d'autres FrameWorks, je tombe sue le site de téléchargement de Microsoft, qui me propose :

Visual Studio 2019 NET 6.0 en X64 SDK, ou X86 SDK

Je télécharge et installe le X64, et rien ne se passe ...

Il n'y a pas de nouveau FrameWork dispo pour mon appli, et rien d'installé dans les programmes et fonctionnalités de Windows 10.

J'ai donc sélectionné le 4.7.2, regénéré mon appli et installée sur tous les postes (sur une base de test, soyons prudent...)

Pour le moment personne ne hurle.

Dans la liste des FrameWorks disponibles je trouve aussi

Unity 3.5 net full class libraries
Unity 3.5 net subset class libraries
Unity 3.5 micro base class libraries
Unity 3.5 web base class libraries

Savez-vous où je peux trouver une doc correcte sur ces outils.

Merci

Il faut que tu récupères les sdk .NET Framework en bas de page
https://dotnet.microsoft.com/downloa...al-studio-sdks

A moins que tu veux passer sur net core, un conseil si tu veux passer sur les dernières versions récupère la version 5.0, la version 6.0 est en beta, et met bien à jour visual studio et relance le, mais ça risque d'impliquer de gros changement dans ta solution

Citation:

---

Envoyé par youtpout978

A moins que tu veux passer sur net core, un conseil si tu veux passer sur les dernières versions récupère la version 5.0, la version 6.0 est en beta, et met bien à jour visual studio et relance le, mais ça risque d'impliquer de gros changement dans ta solution

---

Ne surtout pas passer en .NET 5 si tu ne souhaites pas passer en .NET Core, car .NET 5 est .NET Core !

Le framework .NET "legacy" s'arrête en 4.8, et ce qui peut être trompeur, c'est que .NET Core abandonne le terme "core" pour les versions >= 5.

Citation:

---

Envoyé par François DORIN

Ne surtout pas passer en .NET 5 si tu ne souhaites pas passer en .NET Core, car .NET 5 est .NET Core !

Le framework .NET "legacy" s'arrête en 4.8, et ce qui peut être trompeur, c'est que .NET Core abandonne le terme "core" pour les versions >= 5.

---

Oui j'ai mal formulé ma phrase je pense, c'est ce que je sous-entendais

J'ai réussi à retrouver un article que j'avais vu passer en news concernant MySQL :

https://sqlpro.developpez.com/tutori...-mysql-mariadb

À méditer avant de faire le grand plongeon.