P'tite question newbie :
 
Je suis occupé à développer une petite appli pour la gestion de blindtests (sur le topic idoine de HFR).
Dans cette appli, j'accède à des fichiers, dont un fichier texte que je modifie via l'appli. Donc, dans mon code, j'ai un chemin qui mène vers ce fichier : D:\Mes documents\Visual Studio 2017\Projects\BT_Jeu\BT_Jeu\
 
A présent, je souhaite publier le projet pour pouvoir le partager avec les autres joueurs (avec Visual Studio). Le problème, c'est qu'une fois sur les autres PCs, le chemin d'origine ne sera plus le même (forcément ).
Quelle est la bonne façon de traiter cela ? Que dois-je mettre dans mon code pour continuer à accéder à ce(s) fichier(s) après publication ? (d'autant que les fichiers en question ont après publication une extension ".deploy" ).
 
Merci pour votre aide !  

Mais pourquoi foutre ça dans un dossier en dur qui en plus se rapporte à là où VS créer les projets par défaut ?
 
Soit tu mets ça à côté de l'EXE (et c'est packagé avec), soit tu utilises les dossiers de l'utilisateur :
var myDocuments = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);

Pour la propal 2, oui, je pourrais passer par ça (je l'ai déjà fait dans une autre appli), mais rien ne dit que l'utilisateur va stocker l'appli dans ce dossier précis !  
 
Pour la 1, euh... qu'entends-tu par "à côté" de l'exe ? Dans le dossier "bin\debug" ?

bin\Debug c'est dans ton IDE, pas chez l'utilisateur.
Mais oui, si le but n'est pas de faire du multi utilisateur sur une même machine, c'est pas plus bête de le mettre là qu'ailleurs, il ne sera pas supprimé par inadvertance.

J'ai cité SpecialFolder.MyDocuments mais tu peux aussi utiliser SpecialFolder.ApplicationData si tu ne veux pas que l'utilisateur le voit parmi ses fichiers perso.

J'ai toujours pas compris pourquoi l'endroit où se trouve l'EXE devrait avoir un rapport avec celui où se trouve le fichier ?

Ah mais je n'ai pas dit qu'il devait y avoir un rapport
 
Non, ma question, c'est comment faire pour qu'une fois publiée, l'appli continue de trouver les fichiers nécessaires, quel que soit le dossier que l'utilisateur aura choisi.

Et il choisit ça comment le Mr
Et pourquoi c'est à lui de choisir où TON appli doit stocker ses fichiers alors qu'il y a des conventions comme mes exemples

Alors, petite explication :  
 
Le topic Blindtest a été créé vers mai-juin 2005. Un des Hfriens et participant à ce topic (Nicky78) a décidé de son côté de créer un programme (en Java) qui permettrait de faciliter la gestion des blindtests en live. Il a vraiment bien géré cela et ça a été une réussite.
Mais depuis la version 5.18 de la JRE (ça date...), un bug est apparu, un bug plutôt embêtant. Du coup, son programme devenait pénible à utiliser.
J'ai donc décidé de le recréer en C# (en corrigeant quelques bugs au passage).
 
Avec son programme, l'utilisateur obtenait une archive zip (contenant dossiers et fichiers); il pouvait mettre le dossier principal où il voulait sur son PC, ça fonctionnait toujours. C'est pourquoi je tente de faire pareil !    
Malheureusement, Nicky78 a disparu de la circulation depuis et... je galère un peu pour comprendre comment il a fait.
 
Voilà  

Ben il "suffit" d'avoir dans le programme un truc qui stocke l'info d'où est le fichier, tu peux faire ça avec un truc maison (fichier Json ou xml ou ce que tu veux), soit en utilisant un truc natif (genre les fichiers Settings.settings, "Fichier de paramètre" dans les types de fichier à ajouter proposés par VS), etc.
Ca te permettra de manière générale d'enregistrer les préférences utilisateurs et de les recharger à sa prochaine utilisation, c'est parfois utile

Ok, merci !    
 
Seconde petite question : quand je publie mon appli, j'obtiens donc un dossier publish, dans lequel mon fichier se voit rajouter une extension *.deploy. Est-ce normal ?

Okay, j'ai trouvé ma réponse ici : https://stackoverflow.com/questions [...] o/16871762  

Pour générer des "setup" en client lourd (winform et cie), la fonction Publish de VS c'est un peu tout pourri. Il faut passer par des extensions ou des outils externes.