Discussion :

[Gluups2]

Bonjour tout le monde,

Quand je me suis lancé dans le développement de mon programme, je ne me figurais pas qu'il allait faire l'objet d'un concours d'absurdités, rien que pour lui.

Pour commencer, il est destiné à une machine de 32 Go sur laquelle Microsoft a imposé Windows 10. Mettre 32 Go et Windows 10 dans la même phrase, déjà, faut oser. Parce que ... vous avez bien compris, il ne s'agit pas de 32 Go de mémoire.

Ensuite, maintenant quand on écrit un "Hello World" en WinForms, il faut viser .Net 8, et ça impose l'installation de .Net Core ET de Windows Forms.

Et quand on lance une recherche sur "Windows Forms runtime", on se retrouve à télécharger quelque chose qui contient SDK dans son URL. Deuxième absurdité.

Par ailleurs, sur la machine de développement, bon sous Visual Studio 2022 Community le programme fonctionne très bien en mode débugage, mais après si je vais dans le sous-répertoire bin\debug, comme d'habitude, et dans le sous-répertoire dédié à la version de Windows, j'ai bien un programme, je peux double-cliquer dessus, ça ne génère aucune erreur. Du moins, de ce que voit l'utilisateur. Mais, pas de Hello World. Le machin se tait. Tout au plus un vague petit coup de sablier, rapide. Quand même en y regardant de plus près, index hors limites sur la ligne de Program.cs qui appelle Form1.

Donc, forcément, si je copie ça vers une machine qui déjà n'a pas .Net au départ, ça ne se passe pas mieux. Sur les deux kits requis il en réclame un, mais pour l'autre c'est moins évident.

Bon alors on dit Hello World, mais ... on ne prévoit pas de le répéter sur la machine utilisatrice ?

J'ai vu des gens déclarer qu'ils avaient passé une heure pour réussir à enfin faire dire Hello World à ce machin, alors que sous Visual Studio ça marchait très bien depuis la semaine d'avant.

Rassurez-moi ... C'est ça, qu'on appelle le progrès ?
Ah oui je sais : c'est pour nous obliger à tout migrer vers PowerShell ?

[Pol63]

je pense que moi aussi avec un peu de mauvaise volonté tu me donnes n'importe quel environnement que je ne connais pas et je peux te pondre une "critique" dans le genre ...

déjà il faut compiler en release pour déployer qqch pas en debug
ensuite avec .net 8 tu as le choix entre déployer le framework sur la machine et ton programme en light (qq centaines de ko) ou ton programme contenant le framework (le dossier release fera alors plus de 100Mo, mais ca revient quasi au même)
dans les 2 cas en copiant le contenu du dossier release ca démarrera sur une autre machine sans rien avoir à faire de plus qu'un copier coller

si tu manques de place, tu peux peut etre tenter de faire un projet sur le framework .net 4.8, qui doit être plus léger (de peu je pense), là le framework doit être installé sur la machine pour que l'exe démarre (et là aussi tout ce qu'il y a à côté de l'exe a des chances d'être nécessaire)

après si t'as pas assez de place ce n'est pas de la faute de visual studio ...

[Gluups2]

Effectivement, depuis l'apparition de la plateforme, bientôt vingt ans, je suis toujours allé chercher mon programme dans bin\debug.

C'est probablement critiquable dans le principe, mais je dois dire que c'est la première fois que ça pose un problème bloquant.

Merci pour ces précieuses infos.

Apparemment, je dois encore ajouter autre chose.

J'ai créé le répertoire de release, je l'ai déclaré dans les propriétés du projet, j'ai cliqué sur Publier, et le programme est apparu dedans.

Malheureusement, quand je double-clique dessus, il se passe la même chose que sur la machine utilisatrice : rien.

En debug ça fonctionne très bien, en release non.

Pour ce qui est de la plateforme, je pense que la version 2 aurait très bien fait l'affaire. Quand on crée un nouveau projet, on écrit tellement en gros que ah non attention ces versions-là il n'y a plus de support dessus, que ... j'avoue, je me suis laissé influencer.

Pour ce qui est du manque de place, effectivement, c'est plutôt la faute des mises à jour inappropriées. Vouloir caser 240 Go de mises à jour sur une machine de 32 pour laquelle on a versé des pots de vin pour installer Windows 10, c'est obligé que ça coince.

[Gluups2]

Le sujet m'a donné l'occasion de mettre mon nez dans la procédure de publication, ce qui certes est intéressant.

Je dois avouer que le problème était ailleurs. J'ai prévu que l'application va chercher sur la ligne de commande le chemin du fichier qu'elle doit créer, et en l'absence je n'ai pas bien testé la valeur par défaut.

Une fois fourni un chemin pour le fichier, ça fonctionne impec sur la machine utilisatrice.

Je note d'ailleurs que .Net impose à présent la même procédure de sécurité que PowerShell : si on ouvre une fenêtre de ligne de commandes sur le répertoire où se trouve le programme, en tapant le nom du programme on se fait jeter.

Il faut taper

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
.\Programme

(en supposant que le programme s'appelle ... Programme)