Discussion :

[zpliz]

Bonjour à tous,

J'ai créé un petit bout de développement pour un client en Visual Studio, avec le peu d'outils et de codage que je connais.

Cela fonctionne bien lorsqu'on lance ce développement qui est automatique et qui me génère des fichiers txt basiques.

Jusque là pas de souci.

Ma demande (en 2 parties), est qu'après utilisation de mon dev, mon client me demande de le faire évoluer avec les besoins suivants.
Premièrement, il souhaiterait que je journalise dans un fichier log, les différents traitements que mon dev réalise. Est-ce que simplement dans VS, j'ai la possibilité de lui dire de me faire ça ? genre dans une option de mon projet.
ou faut-il que je "m'amuse" à créer un nouveau fichier texte dans lequel j'écrirais au fil de l'eau de mon dev, ce qu'il est sensé avoir réalisé ?

Deuxièmement, mon client a pu lancer 2 fois mon développement en même temps. Bien évidemment, en soi c'est pas très gênant, mais il souhaiterait bloquer cette possibilité là. Comment puis-je faire pour que si je relance ledit dev, cela soit bloqué par le système.

Merci d'avance

[umfred]

1) tu as les Trace, TextTraceWriter, ... mais dans tous les cas, c'est à toi de définir ce qui doit être tracer (quel message), où (quel fichier) et quand (à quel moment dans mon code je dois écrire une trace), donc des lignes à rajouter aux endroits voulus (il y a aussi EventLogTraceWriter qui écrit dans le journal des événements de windows)
https://learn.microsoft.com/fr-fr/do...t-7.0#examples
https://learn.microsoft.com/fr-fr/do...r?view=net-7.0 (et pages voisines)

2)si c'est en vb.net, tu dois avoir une case à cocher dans les propriétés du projet "application à instance unique"; si en C#, il faut ajouter du code au niveau du point d'entrée de l'application
https://learn.microsoft.com/en-us/tr...-a-named-mutex

[zpliz]

Merci @Umfred déjà pour ta contribution.

Pour ce qui est du fichier "log", j'ai opté pour une façon plus trivial, en écrivant directement dans un fichier txt à chaque fois que j'ai une "public sub" qui se termine. Ca vaut ce que ça vaut, mais ça a le mérite d'exister.
La coche sur "application à instance unique" en revanche elle, me va à merveille.

Est-ce que dans le même esprit, il y aurait une option basique de VS qui permet de générer un fichier de code retour "ok" ou "nok" quand le dev s'est exécuté ?

Merci encore.

[umfred]

Je n'ai pas compris ce que tu voulais faire ...

[papajoker]

bonjour

pas tout compris, git ne fait pas le job désiré ? Et pour dernière question : créer un git hook ?

[zpliz]

Ce que je voudrais, c'est savoir s'il y a une option simple de Visual Studio (genre une coche à valider), qui permettrait que, lorsque le développement a fini de s'exécuter, il renseigne une information dans un fichier temporaire ou autre signifiant que tout est ok (bien déroulé), ou au contraire que ça se soit arrêter pour une erreur. Donc genre un code retour pour dire "ok" ou "non ok" pour le déroulement du dev.

[umfred]

le mode debug non ?
comment tu détermines si le déroulement a été ok ou pas ? ce n'est pas le but aussi des fichiers log ?
Sinon un booleen global mis à vrai au début et qui passe à faux quand il y a eu mauvais truc et à la fin le tester, et faire l'indication ?
Si c'est une application console, ça doit se renvoyer à la fin de la fonction principale, sinon à voir.

[StringBuilder]

Si ton programme est verbeux et que tu te moques de voir ce qu'il te raconte, et aussi qu'il ne demande pas de saisie, tu peux aussi simplement créer un raccourci qui pointe dessus :

programme.exe >> journal.log

Toute la sortie de ton programme (les Console.WriteLive()) seront ajoutés à la fin du fichier "journal.log".
C'est pas le plus propre, mais ça a l'avantage de ne pas nécessiter de modifier le programme

[StringBuilder]

Ce que je voudrais, c'est savoir s'il y a une option simple de Visual Studio (genre une coche à valider), qui permettrait que, lorsque le développement a fini de s'exécuter, il renseigne une information dans un fichier temporaire ou autre signifiant que tout est ok (bien déroulé), ou au contraire que ça se soit arrêter pour une erreur. Donc genre un code retour pour dire "ok" ou "non ok" pour le déroulement du dev.

Oui, c'est le principe du ERRORLEVEL.

Sinon un booleen global mis à vrai au début et qui passe à faux quand il y a eu mauvais truc et à la fin le tester, et faire l'indication ?
Si c'est une application console, ça doit se renvoyer à la fin de la fonction principale, sinon à voir.

Attention, la norme ANSI défini le ERRORLEVEL à :
0 : pas d'erreur
<> 0 (positif ou négatif) : erreur

Donc il vaut mieux s'y tenir, car si un jour tu veux planifier ton programme, la tâche va tout le temps tomber en erreur si le programme renvoie autrechose que 0 (ou rien).

Voici un exemple complet :

Programme (C#) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
int res;
Console.WriteLine("Démarrage...");
for (int i = 0; i < args.Length; i++)
{
    Console.WriteLine($"\tParamètre {i} reçu : {args[i]}");
}
if (args.Length != 2)
{
    Console.WriteLine("Le programme attend 2 paramètres");
    res = 1;
}
else if(args[0] != args[1]) {
    Console.WriteLine("Les deux partamètres sont différents");
    res = 2;
}
else
{
    Console.WriteLine("Les deux paramètres sont égaux");
    res = 0;
}
Console.WriteLine("Fin");
return res;

Script (test.bat)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
@echo off
TestError.exe > journal.log
IF %ERRORLEVEL% EQU 0 (echo "Pas d'erreur") ELSE (echo "Erreur : %ERRORLEVEL%")
 
TestError.exe toto le haricot >> journal.log
IF %ERRORLEVEL% EQU 0 (echo "Pas d'erreur") ELSE (echo "Erreur : %ERRORLEVEL%")
 
TestError.exe 1 2 >> journal.log
IF %ERRORLEVEL% EQU 0 (echo "Pas d'erreur") ELSE (echo "Erreur : %ERRORLEVEL%")
 
TestError.exe toto toto >> journal.log
IF %ERRORLEVEL% EQU 0 (echo "Pas d'erreur") ELSE (echo "Erreur : %ERRORLEVEL%")

Sortie (console) :

Code :

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

1
2
3
4
5
6
 
C:\Users\sylva\Source\Repos\TestError\TestError\bin\Debug\net7.0>test.bat
"Erreur : 1"
"Erreur : 1"
"Erreur : 2"
"Pas d'erreur"

Journal (journal.log) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Démarrage...
Le programme attend 2 paramètres
Fin
Démarrage...
	Paramètre 0 reçu : toto
	Paramètre 1 reçu : le
	Paramètre 2 reçu : haricot
Le programme attend 2 paramètres
Fin
Démarrage...
	Paramètre 0 reçu : 1
	Paramètre 1 reçu : 2
Les deux partamètres sont différents
Fin
Démarrage...
	Paramètre 0 reçu : toto
	Paramètre 1 reçu : toto
Les deux paramètres sont égaux
Fin

A noter que ce EXIT CODE sera aussi récupérable si tu fais un Process.Start()