Discussion :

[Ninpa]

Bonjour,

Je developpe une application en Visual Basic à l'aide de Visual Studios Express 2012, utilisant les windows Forms et le framework net 4.5.

Cette application possède un petit fichier .ini placé à sa racine pour récupérer l'adresse de sa base de donnée.

Mais j'ai un souci avec la lecture de ce fichier :

Voila comment la méthode utilisé pour lire ce fichier :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
    Private Function GetCoord()
        Dim inc As Integer = 0
        Dim Server As String = ""
        Dim templine As String
 
        Dim User As String = ""
        Dim Pass As String = ""
        Dim Instance As String = ""
 
        Dim fichierTemp As String = My.Application.Info.DirectoryPath & "\config.ini"
 
        If My.Computer.FileSystem.FileExists(fichierTemp) Then
            Dim sr As StreamReader = New StreamReader(fichierTemp)
            sr.DiscardBufferedData()
            Do
                templine = sr.ReadLine()
                If inc = 1 Then
                    Server = templine
                ElseIf inc = 3 Then
                    BD = templine
                ElseIf inc = 7 Then
                    User = templine
                ElseIf inc = 9 Then
                    Pass = templine
                ElseIf inc = 11 Then
                    Instance = templine
                End If
                inc = inc + 1
            Loop Until templine Is Nothing
 
            sr.Dispose()
            sr.Close()
        End If
 
        Return ("Server=" & Server & "\" & Instance & ";Database='" & BD & "';User Id=" & User & ";Password=" & Pass & ";")
    End Function

Le fichier se est lu correctement depuis plusieurs mois. Mais j'ai récemment eu à faire a un probleme pour le moins étrange.
Quand le fichier config.ini est modifié, il arrive sur certaines machine que l'application continu toujours de lire l'ancien fichier configuration.
C'est à dire que le fichier est correctement changé, l'application appel bien le bon chemin du fichier, quand j'ouvre le fichier config il n'y a pas de doute que le fichier est bon, mais l'application s'obstine sur les anciens logs.
Et le comble, c'est que lorsque que je démarre l'application en mode administrateur, le fichier est correctement lu, et lorsque je réessai sans mode administrateur, l'ancien fichier est de nouveau lu.

Existe-t-il une cache pour les streamreader ? J'ai déjà changer de méthode de lecture, pas moyens d'obtenir systématiquement l'acces au nouveau fichier.
Je me retrouve donc coincer avec cette procédure qui donne l'impression de marcher quand elle le souhaite, alors qu'il y a un "truc" !

Merci.

[Kropernic]

Est-ce que My.Application.Info.DirectoryPath renvoie bien toujours vers la même directory suivant que tu es en admin ou non ?

[pascalCH]

Est-ce que My.Application.Info.DirectoryPath renvoie bien toujours vers la même directory suivant que tu es en admin ou non ?

Quelques failles dans la logique effectivement :

1. aucune certitude quant à la localisation physique du fichier - ou du moins celui cherché par le programme. (que vaut DirectoryPath suivant le mode user-admin ?)
2. l'utilisation d'un fichier ini en lecture/écriture aujourd'hui (j'imagine que c'est sous win7-8-8.1 ou pire encore w212-14), stocker le fichier dans le répertoire "Users" (tous les utilisateurs) est (peut-être) une alternative.
3. le plus risqué est ce "If My.Computer.FileSystem.FileExists(fichierTemp) Then" qui n'a pas de clause "else", une bonne exception déclenchée dans le else apporterait peut-etre quelques informations intéressantes.

[Ninpa]

Bonjour à vous deux,

Oui la variable

Code :

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

My.Application.Info.DirectoryPath

renvoi bien correctement le bon chemin que je soit en mode admin ou non.

J'ai deja essayer de modifier le chemin du fichiers, le souci est que meme si le fichier n'est pas présent, il prend quand meme l'ancien fichiers, comme si il ignorais tous simplement le nouveau fichier ou même l'absence de fichier.

Effectivement, il n'y a pas de clause else dans ma conditions, je vais en insérer une, mais comme il trouve l'ancien fichier à tous les coup en mode utilisateurs mais détecte bien l'absence de fichier en mode administrateur.

[pascalCH]

Le fichier se est lu correctement depuis plusieurs mois. Mais j'ai récemment eu à faire a un probleme pour le moins étrange.
Quand le fichier config.ini est modifié, il arrive sur certaines machine que l'application continu toujours de lire l'ancien fichier configuration.
C'est à dire que le fichier est correctement changé, l'application appel bien le bon chemin du fichier, quand j'ouvre le fichier config il n'y a pas de doute que le fichier est bon, mais l'application s'obstine sur les anciens logs.

• Qu'ont-elles de différent des autres machines ? (systeme d'exploitation, GPO, le chemin de recherche (path), applications installées,etc...)
• Si on change le nom du fichier par quelque chose de plus exotique "MonAppliAMoi.ini" ? ça change quelque chose ?
• sur les machines suspectes, si on installe le logiciel compilé AVEC les infos de débogage, ça change quelque chose ?
• autre chose - parfaitement improbable - si on affiche le contenu du fichier (au sein de l'application - style MessageBox ) et qu'on affiche ce qu'il y a de stocké dans les variables (user,instance,pass,server) , il y a bien la même chose ?
• il y a une bonne raison pour ne pas initialiser tempLine (c'est une histoire de confiance dans la lecture de la ligne ?)
• et si au lieu de Dim Server As String = "" on met Dim Server As String = "un truc idiot qui marche pas" et pareil pour les autres variables, il se passe quoi ?

J'ai deja essayer de modifier le chemin du fichiers, le souci est que meme si le fichier n'est pas présent, il prend quand meme l'ancien fichiers, comme si il ignorais tous simplement le nouveau fichier ou même l'absence de fichier..

le résultat est récupéré dans un composant d'interface utilisateur ? (caption - text, autre ?) qui serait prépositionné à la conception ?

[Ninpa]

Bonjour,

Les machines ne sont pas tellement différentes : Meme OS? meme version du framwork, la seule différence, et je pense que cela vient de la, c'est le repertoir d'installation. Mon application est compiler dans un répertoire placé dans le bureau, alors que sur les autres machines, l'éxécutable est placé dans un dossier placé dans Program Files. J'ai remarqué que pour toute modification dans ce dossier, j'ai besoin d'avoir accès aux droit administrateur, et c'est probablement la cause du dysfonctionnement, si l'appli est executer en utilisateur, il doit y avoir une image ou une cache windows qui renvoi les donné comme elles etaient, d'ou l'erreur de lecture.

Pour répondre à toutes tes questions, lorsque je fais tous ces changement, rien ne perturbe l'application, elle lis toujours l'ancien fichier.

Je pense donc que pour résoudre ce souci de facon "durable", il va falloir changer le répertoire d'installation par quelque chose de moins restrictif, à moins bien sur que vous ayez une solution miracle !

le résultat est récupéré dans un composant d'interface utilisateur ? (caption - text, autre ?) qui serait prépositionné à la conception ?

Je crois que je ne saisi pas ta question, le code de récupération du fichier texte est plus haut, il n'y a rien de plus.

Merci !

[Kropernic]

Regarde du côté de My.Computer.FileSystem.SpecialDirectories pour voir si tu n'y trouverais pas ton bonheur. Maintenant, p-e que cela ne change rien quant au besoin des droits admins... Jamais testé perso...

[youtpout978]

Pourquoi ne pas utiliser l'app.config ou les paramètres de l'application pour stocker tes données, l'ini est plutôt déconseillé.
J'ai l'impression que quand il te recrée un ini pour l'utilisateur il te le met dans l' appdata un endroit ou windows stock les données des applications.

[pascalCH]

Bonjour, J'ai remarqué que pour toute modification dans ce dossier, j'ai besoin d'avoir accès aux droit administrateur, et c'est probablement la cause du dysfonctionnement,

Je pense donc que pour résoudre ce souci de facon "durable", il va falloir changer le répertoire d'installation par quelque chose de moins restrictif, à moins bien sur que vous ayez une solution miracle !

Merci !

Voilà, tu as trouvé la cause, effectivement, il faut des droits spéciaux pour bricoler dans program files.
donc soit tu changes les droits du répertoire d'installation pour les utilisateurs (dangereux) soit tu stocke le fichier ini dans AppData (voir My.Computer.FileSystem.SpecialDirectories comme dit Kropernic)
mieux encore, tu migre le fichier ini dans la base de registre - dans HKU ou HKCU - pas dans HKLM qui necessite aussi les droits d'amin !!

[Ninpa]

Bonjour,

Merci à tous pour vos réponses !

Je vais migrer mon fichier ini vers le registre, ce qui me permettra de toujours garder les parametres sans mode admin, merci beaucoup à tous !

[youtpout978]

Bonjour,

Merci à tous pour vos réponses !

Je vais migrer mon fichier ini vers le registre, ce qui me permettra de toujours garder les parametres sans mode admin, merci beaucoup à tous !

Mais pourquoi de si mauvaises idées, c'est d'un autre temps, alors que le framework.net permet de gérer tout ce qui es paramètre d'application: https://msdn.microsoft.com/fr-fr/lib...vs.110%29.aspx