Version imprimable
Bonjour,
Il m'arrive un truc étrange. Le code suivant:
Dans une instance de C#, ça m'affiche C:\.Code:
2
3
Dans une seconde instance, évidemment sur le même poste, ça affiche D:\
8O
Oui oui, c'est bien le même code, j'ai fais un copier-coller devant un collègue qui a servi de témoin :D
Me serais-je transformé en gérard majax pendant la nuit ?
Papy !
Ou alors un abus de substances psychothropes ? :mouarf:Citation:
Envoyé par Papy214
Vous partagez beaucoup de choses avec ton collègue témoin ? :mrgreen:
lolll
et pourtant je rigole pas ... Je pourrais en faire une vidéo et la mettre en ligne tellement c'est bizarre.
La seule différence entre les 2 projets, c'est qu'un est en .net 2.0 et l'autre en .net 3.5
LocalApplicationData étant spécifique à l'utilisateur, est-ce que les deux projets tournent avec la même identité ?Citation:
Envoyé par Papy214
J'étais en train de modifier mon code sur mon projet.
Comme ça m'affichait un résultat erroné, j'ai ouvert une seconde instance de VS 2008 express. J'ai fais un copier du code dans un simple clic bouton.
Même machine, même utilisateur (moi), rien changé ...
la bonne réponse:
http://alphomega.free.fr/image/Bon.jpg
la mauvaise réponse
http://alphomega.free.fr/image/PasBon.jpg
juste pour montrer que je dis pas de bétise :D
J'en crois pas mes yeux ...
Je viens de changer la version du framework dans les propriétés de mon projet de test. Je l'ai passé de 3.5 à 2.0 et là, le code me renvoie D:\ au lieu de C:\ 8O
Pire ... si je repasse en 3.5, ça ne change plus rien ... ça me renvoie maintenant tout le temps D:\ , ce qui est une réponse fausse puisque mon LocalApplicationData est sur C:\
une troisième instance de VS ...
Je fais l'identique du premier ... je laisse en .net 3.5
Ca me renvoie C:\ comme tout à l'heure ...
J'enregistre cette fois mon projet sans changer la version du framework.
je le relance, et hop : D:\
Je vais devenir fou :cfou:
Surprenant.
Mais bon, au final, faut en conclure quoi ... ?
Ton projet est enregistré ou? ton framework est enregistré ou? l'utilisateur avec lequel tu es connecté à quoi comme dossier de démarrage?
C'est super bizarre un truc pareil, faudrait essayé de trouver des pistes ^^
Bon, pour les résultats différents après enregistrement, je vois pas.
Pour le code, le suivant fonctionne et me renvoie bien la bonne réponse:
Je me contenterai de cette solution et je chercherai le reste plus tard.Code:MessageBox.Show(Directory.GetDirectoryRoot(System.Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)));
Merci à tous !
arf, j'ai compris ... je suis un :boulet:
Application non enregistrée: Environment.SpecialFolder.LocalApplicationData.ToString() renvoie "LocalApplicationData"
Il semble que
renvoie le répertoire en cours de l'application si le chemin passé en paramètre est invalide. Enfin, je pense parce que la doc ne le précise pas, ou alors j'ai rien vu.Code:Directory.GetDirectoryRoot(Environment.SpecialFolder.LocalApplicationData.ToString())
Du coup, le projet non enregistré renvoie C:\.
Une fois enregistré sur D:\mesdevs , ça me renvoie D:\
Ce n'est pas une question d'une application non enregistrée. C'est une question d'utiliser les bonnes méthodes et de lire la doc ^^
Le fait d'utiliser une énumération (Environment.SpecialFolder.LocalApplicationData) avec un ToString en tant que valeur pour un paramètre d'une méthode doit déjà amener à se poser une question : dans quel cadre cette énumération est-elle utilisée ? Car l'utiliser ainsi n'a à priori aucun sens :)
Si tu prends la documentation qui va avec cette énumération, tu devrais arriver sur la documentation de la méthode Environment.GetFolderPath
Et au final ton code donnerait
Par ailleurs, si on prend la documentation de la méthode Directory.GetDirectoryRoot il est dit queCode:DriveInfo dr = new DriveInfo(Directory.GetDirectoryRoot(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)));
Et si on regarde alors la méthode Path.GetFulPath on tombe surCitation:
Cette méthode obtient le nom du chemin d'accès qualifié complet de path, comme retourné par GetFullPath, et retourne les informations relatives au répertoire racine. Le chemin d'accès spécifié n'est pas requis pour exister.
ce qui explique le pourquoi du comment.Citation:
Le fichier ou répertoire spécifié par path n'est pas requis pour exister. Par exemple, si c:\temp\nouveaurépertoire est le répertoire actif, l'appel de GetFullPath sur un nom de fichier tel que test.txt retourne c:\temp\nouveaurépertoire\test.txt. Le fichier n'a pas besoin d'exister.
Pratique la documentation ;)
Je n'avais pas vu tout ça.Citation:
ce qui explique le pourquoi du comment.
Merci de ces explications détaillées. :)