Discussion :

[nadtn]

Bonjour,

Dans mon application que je développe, j'ai recours à des fichiers externes! (image fichier texte etc..). Mais j'ai un problème avec le PATH de ces fichiers. Qui sera forcement pas le même quand une autre personne utilisera l'application d'un autre PC.
Alors comment dans mon code et par la suite faire en sorte que la personne ait le bon PATH?
Je veux par exemple ne plus avoir dans mon code "C:/......." mais par quoi le remplacer? Faut-il mettre les fichiers dans un endroit spécifique sinon comment faire le récupérer d'une clé USB par exemple.

Merci d'avance.

[Bousk]

Salut,

les paths devraient tous être relatif à l'exécutable, et tu t'arranges pour que l'appli soit déployée correctement à l'installation (installer, zip correct, ...)

[nadtn]

Bonjour,

Merci pour ta réponse. Pourrais-tu être plus précis sur ce que tu viens de proposer?
Comment on fait pour qu'il soit relatif à l'exécutable? Sachant que j'aurais une BD qui sera au même endroit là ou je teste et où je vais l'installer. (path de la BD qui sera à définir comment dans mon code?)
Déployée correctement cad? Le path de la BD et du fichier de configuration ne seront pas avec l'application.. Faudra donc les définir à l'application mais comment? C'est justement ma question.

[bacelar]

Comment on fait pour qu'il soit relatif à l'exécutable?

C'est pas vraiment le plus simple.
Une astuce, c'est de faire en sorte que le répertoire de travail soit celui où est l'exécutable.
Ainsi, tous les chemins relatifs auront cette "propriété".
Pour le changement de répertoire de travail, un simple bat de 2 lignes fera l'affaire.

Comme je l'ai déjà indiqué dans votre précédent sujet, je ne suis pas sûr que mettre la configuration du programme dans une base de données soit très pertinent.

Déployée correctement cad?

Déploiement via un MSI qui fait toutes les actions nécessaire pour que l'installation fonctionne sans accrocs.

Le path de la BD et du fichier de configuration ne seront pas avec l'application.. Faudra donc les définir à l'application mais comment?

On revient à mes remarques sur le fait que l'utilisation d'une base de données pour cela n'est pas forcement judicieuse.

[nadtn]

C'est pas vraiment le plus simple.
Une astuce, c'est de faire en sorte que le répertoire de travail soit celui où est l'exécutable.
Ainsi, tous les chemins relatifs auront cette "propriété".
Pour le changement de répertoire de travail, un simple bat de 2 lignes fera l'affaire.

Pour faire en sorte que le répertoire de travail soit celui où est l'exécutable, j'installe le logiciel puis je rajoute les fichiers dans le répertoire?
Dans le code je mets "/maphoto.png" ou "/textez.txt"?

Comme je l'ai déjà indiqué dans votre précédent sujet, je ne suis pas sûr que mettre la configuration du programme dans une base de données soit très pertinent.


Déploiement via un MSI qui fait toutes les actions nécessaire pour que l'installation fonctionne sans accrocs.


On revient à mes remarques sur le fait que l'utilisation d'une base de données pour cela n'est pas forcement judicieuse.

J'ai vu que tu m'as dit qu'il ne fallait pas mettre la configuration de la BD dans la BD, mais en fait j'ai une configuration d'une caméra, je vais y mettre la configuration dans la BD. C'est le seul moyen que j'ai trouvé de protéger (ne pas permettre de le modifier) notre fichier de configuration.

Sinon j'ai vite fait vu sur Google que le MSI permettait d'installer un logiciel dans un ordianteur distant (si je dis pas de bêtises) en quoi ça va permettre que l'installation fonctionne sans accro? Je fais justement un outil qui devrait permettre de configurer la caméra, la BD, les Paths, l'heure, etc. Si il y a outil qui le fait déjà ça serait super.

[bacelar]

Pour faire en sorte que le répertoire de travail soit celui où est l'exécutable, j'installe le logiciel puis je rajoute les fichiers dans le répertoire?

Je pense que vous vous posez de faux problème car vous manquez de connaissance sur la manière "standard" d'installer une application.
On installe une application avec un MSI, qui se chargera de copier et de modifier les fichiers en accord avec les choix d'installation faits par l'utilisateur ou l'administrateur.
Il est courant que les raccourcis sur le bureau et autres items de menu "démarrer" soit directement créé par le MSI.
Il est donc assez facile de faire en sorte que ces raccourcis lancent un "launcher" qui ne fera que changer le working directory à une valeur qui qui soit adapter à votre exécutable.
L'utilisation de la command batch "cd ~dp0" suffit dans la plupart des cas.
https://stackoverflow.com/questions/...w-does-it-work

Mais, généralement, le code ne devrait pas être dépendant du working directory mais plutôt utiliser des répertoires bien définis pour l'usage qui est en est fait des fichiers qu'ils contiennent :
https://msdn.microsoft.com/fr-fr/lib...(v=vs.85).aspx

Dans le code je mets "/maphoto.png" ou "/textez.txt"?

Ici, c'est des chemins absolus, pas super pratique.
L'endroit où est un fichier devrait être fonction de son rôle (fichier de paramétrage générale, paramétrage par utilisateur, zone "sécurisée" ou pas, etc...), donc pour répondre à votre question, c'est fonction de son rôle, au fichier.

C'est le seul moyen que j'ai trouvé de protéger (ne pas permettre de le modifier) notre fichier de configuration.

C'est toujours la pire des justifications, l’ignorance.
Quand c'est de la configuration qui est fonction de la machine hôte et qui n'a pas à être modifié par l'utilisateur, sous Windows, la registry (base de registre) est l'endroit le plus "naturel".

Ne jouez pas à cache-cache, sur une machine "cliente finale", l'utilisateur à toujours tous les pouvoirs. S'il cherche, il trouve, point barre.

Sinon j'ai vite fait vu sur Google que le MSI permettait d'installer un logiciel dans un ordianteur distant

Distant ou local, c'est pareil.

en quoi ça va permettre que l'installation fonctionne sans accro?

Parce que tout ce qui est copié est à l'endroit prévu (à la racine d'installation près qui est à la discrétion de l'utilisateur).
Parce que toutes les tâches de configurations automatisées d'adaptation à la machine cible sont éditable dans un MSI,
etc...

Je fais justement un outil qui devrait permettre de configurer la caméra, la BD, les Paths, l'heure, etc. Si il y a outil qui le fait déjà ça serait super.

Qu'avez-vous contre la base de registre ou même un simple fichier texte ???

[koala01]

Salut,

Des fichiers, on peut en créer pour une quantité incroyable de raison, et ils peuvent être utilisés de manière bien différentes.

La première chose à faire, quand on envisage d'utiliser un fichier, c'est donc de se poser quelques questions sur l'utilisation qui en sera faite. Par exemple:

1- Est ce que le fichier sera modifié ou non

Certains fichiers -- comme les fichiers de configuration -- devront être modifiables, ne serait-ce que pour permettre de changer la couleur verte d'un truc en rouge.

D'autres fichier -- comme les images qui servent pour les textures ou les fichiers qui décrivent un niveau de jeu -- vont contenir des données qui n'auront ( a priori du moins) absolument aucune raison d'être modifiée.

Si fichier est susceptible d'être modifié, il faut se poser une deuxième question :
2- Est-ce que les informations que contient ce fichier sont relatives à "l'application" ou spécifique à "l'utilisateur"

En gros, il s'agit de se demander si, quand bob fait une modification dans le fichier, cette modification est "partagée" par tous les utilisateurs de l'application, ou s'il n'y a que bob qui puisse en profiter.

Si bob rajoute un article à l'inventaire, albert doit pouvoir voir ce nouvel article dans l'inventaire, ce sera donc une "donnée partagée".

Mais si bob décide de choisir une police plus grande, parce qu'il a des problème de vue, cela ne changera pas la police de caractères utilisée par albert. La taille de police est donc une donnée spécifique à l'utilisateur.

La réponse à cette question te permettra de distinguer le "rôle" joué par le fichier, et partant, le nombre de fois que le fichier risque d’apparaître sur un ordinateur donné, et donc l'endroit le mieux adapté pour aller le placer.

Ainsi, un fichier (qui pourrait être en XML) contenant un inventaire ne devrait apparaître qu'une seule et unique fois sur l'ordinateur (voire mieux encore, n'être accessible que depuis un serveur externe), pour que tout le monde dispose de la même version du fichier au même moment, sans courir le risque de se retrouver avec une version du fichier qui ne serait pas "synchronisée" avec le reste.

A l'inverse, le fichier qui contient la taille de la police de caractères devra sans doute apparaître en autant d'exemplaires qu'il y a d'utilisateurs de l'application, pour permettre à bob, à albert, mais aussi à jean et à jaques d'avoir la taille qui leur convient.

Une fois que l'on a une idée générale de l'utilisation qui sera faite des différents fichiers, on peut commencer à réfléchir à l'endroit où il "seront le mieux placés".

Les fichiers qui n'ont -- a priori -- aucune raison d'être modifiés devraient se trouver dans un sous-répertoire du dossier d'installation, que l'on va appeler, pour la facilité, le "dossier racine". Cela pourrait prendre une forme proche de

Code :

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

1
2
3
4
5
dossier racine
    |-> bin // contient les exécutables et les dll
    |-> sounds // contient les sons
    |-> textures // contient les textures
    |-> datas  // contient les données propres à l'application

Pour être honnête, je ne sais plus dans quel dossier devrait se trouver un fichier pour que tout le monde puisse y avoir accès et le modifier. C'est pour cela que je dis que l'idéal serait de faire en sorte que ce fichier soit sur un serveur distant . Si tu veux garder un fichier de ce type en local, il faudra que tu fasse des recherches quant au meilleur endroit pour le placer

Enfin, les fichiers qui concernent la configuration spécifique à un utilisateur devraient se trouver -- sous windows -- dans C:\Users\<nom d'utilisateur>\AppData\<Local|Roaming| LocalLow (*)>\<nom de l'application>

(*) il faut choisir l'un des trois, tu trouveras des indications sur le dossier AppData en anglais ==>ici<==

Note (si ca t'intéresse) que, sous linux, l'organisation est quelque peu différente :

• l'exécutable se trouvera généralement dans le dossier /usr/bin (voire /usr/locale/bin)
• les bibliothèques dynamiques seront sans doute dans le dossier /usr/lib (voire /usr/locale/bin)
• les données partagées seront sans doute dans le dossier /usr/share/<nom de l'application>
• les données spécifiques à un utilisateur iront le plus souvent dans le dossier /home/<nom d'utilisateur>/.<nom de l'application(*)>

(*) le point qui précède le nom de l'application indique un fichier caché

Et, bien sur, l'idéal est toujours -- comme l'a si bien fait remarquer bacelar, d'utiliser un outil qui te permettra de créer un installateur, qui placera les fichiers aux endroits qui conviennent

[nadtn]

Merci beaucoup pour réponses, les choses commencent à m'être un peu plus claire.

Carme comme tu les dis bacelar, "vous manquez de connaissance sur la manière "standard" d'installer une application".

On installe une application avec un MSI, qui se chargera de copier et de modifier les fichiers en accord avec les choix d'installation faits par l'utilisateur ou l'administrateur.

Tu me conseille lequel? Je vais expliquer plus bas ce qu'on fait peut-être qu'il y a moyen que tu me proposes le MSI le plus adapté.

Il est donc assez facile de faire en sorte que ces raccourcis lancent un "launcher" qui ne fera que changer le working directory à une valeur qui qui soit adapter à votre exécutable.

C'est le MSI qui crée ce "launcher"? Et comment il fera pour changer le working directory? Et le changera t-il aussi dans mon code? Sauf si je fais comme koala01 a dit et tout sera dans n dossier d'installation avec des sous-répertoires.

Mais, généralement, le code ne devrait pas être dépendant du working directory mais plutôt utiliser des répertoires bien définis pour l'usage qui est en est fait des fichiers qu'ils contiennent

Déjà ma réponse. Ok!

Ici, c'est des chemins absolus, pas super pratique.
L'endroit où est un fichier devrait être fonction de son rôle (fichier de paramétrage générale, paramétrage par utilisateur, zone "sécurisée" ou pas, etc...), donc pour répondre à votre question, c'est fonction de son rôle, au fichier.

Ils seront absolus si j'ai bien compris? Genre: datas/configuration.txt. où datas est un répertoire que j'aurais créé avec le MSI c'est ça?

Ici, c'est des chemins absolus, pas super pratique.
L'endroit où est un fichier devrait être fonction de son rôle (fichier de paramétrage générale, paramétrage par utilisateur, zone "sécurisée" ou pas, etc...), donc pour répondre à votre question, c'est fonction de son rôle, au fichier.

Tu as raison. Je vais finalement mettre mon fichier que je cherchais à "cacher" dans un des répertoires. Puis si il veut le modifier, il assume. (PS: je vais quand même tester l'écriture et lecture de fichiers dans ma BD de l'autre sujet)

Distant ou local, c'est pareil.

Très bien. Ce qu'il me faut.

Parce que tout ce qui est copié est à l'endroit prévu (à la racine d'installation près qui est à la discrétion de l'utilisateur).
Parce que toutes les tâches de configurations automatisées d'adaptation à la machine cible sont éditable dans un MSI,
etc...

Oui je vais ça du coup, mettre chaque fichier dans son répertoire qui lui sera spécifique. Du coup, comment les mettre à la racine d'installation? Le MSI le fait? Comment l'éditer avec un MSI? Liens pour voir?

Qu'avez-vous contre la base de registre ou même un simple fichier texte ???

Maintenant plus rien. Tu m'as convaincu. J'avais peur d'une modification de l'utilisateur mais si je le met dans son répertoire à la racine d'installation et q'il le modifie c'est son problème.

[nadtn]

Salut koala01 et merci,
Super introduction et explication du problème.
J'ai presque pas de questions, tu as pris en considérations tout les cas et tout est clair.

Dans notre projet, nous avons un fichier de configuration qu'on mettra comme tu as dit dans un répertoire qui sera créé à l'installation. Notre application le lira et si on veut changer la configuration, on change le fichier. (conf d'une caméra)
Puis on a d'autres données qu'utilise l'application comme les utilisateurs, des objets enregistrées dans une base de données.
On a aussi des images (volumineux) qu'on doit analyser. Je sais pas vraiment se qui sera mieux? Dans la base de données (serveur distant comme tu dis)? Ou dans un répertoires image du projet?
Sinon pour le reste comme tu as dit:

Et, bien sur, l'idéal est toujours -- comme l'a si bien fait remarquer bacelar, d'utiliser un outil qui te permettra de créer un installateur, qui placera les fichiers aux endroits qui conviennent

Et je pense faire ça. Reste trouver quel outil et comment le faire.

Merci encore.

[bacelar]

Tu me conseille lequel?

MSI, c'est un format de fichier, des outils pour en générer, il y en a des trouzaines.
Choisis celui qui s'intègre le mieux à ta manière de travailler et à tes outils.
Vu d'ici, tu n'as que des besoins basiques, tous ces outils devraient facilement te permettre de créer un MSI qui fait ce que tu as besoin.

C'est le MSI qui crée ce "launcher"?

Oui, comme tous les fichiers créés lors de l'installation du programme.
Ce lancher, ça peut être juste un fichier bat de 2 lignes.

Et comment il fera pour changer le working directory?

L'utilisation de la command batch "cd ~dp0" suffit dans la plupart des cas.(BIS)
https://stackoverflow.com/questions/...w-does-it-work

Et le changera t-il aussi dans mon code?

Pas besoin de changer le code. C'est ton code qui fait l'assertion que le working directory est le répertoire d'installation est le working directory.
Avec un peu plus de travail, votre code n'a pas besoin de cette assertion et donc le launcher deviendra inutile.

Sauf si je fais comme koala01 a dit et tout sera dans n dossier d'installation avec des sous-répertoires.

Oui, avec une arborescence, que le MSI créera et remplira pour vous, vous n'aurez pas besoin d'un launcher mais vous devez n'utiliser que des chemins absolus (pas relatifs) que vous devriez construire à partir du résultat de l'appel à l'API "GetModuleFileName".
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
De plus, les fichiers qui doivent être modifiables, même par le programme, comme la configuration d'un utilisateur (en opposition à une configuration pour tous les utilisateurs) ne doivent pas être mis dans cette arborescence.

Il est une règle tacite que l'application sera installée dans un répertoire où les utilisateurs n'auront aucuns droits autre que d'exécuter le programme et de lire les fichiers, pour éviter pas mal de problème de sécurité.
Après, si c'est le client final qui fait l'installation comme un sagouin et pas un administrateur informatique consciencieux, cela ne devrait pas être votre problème de développeur.
Donc, ne faites pas l'assertion que votre programme a le droit de modifier les fichiers.

Pour les informations/configurations qui ont besoin d'être modifiées, on revient sur le fait d'utiliser les répertoires qu'offre Windows pour chacun des besoins et qu'il faut utiliser les API Win32 pour les déterminer et pas les mettre en dur dans le code.

Ils seront absolus si j'ai bien compris?

Les exemples que vous donnez sont des chemins absolus (Dans le code je mets "/maphoto.png" ou "/textez.txt"? ).
Un chemin qui n'est pas absolu, et relatif au working directory.
Si vous voulez que votre application fonctionne sans avoir à fixer le working directory, vous ne devez utiliser que des chemins absolus. Mais cela ne veut pas dire des chemins en dur, mais des chemins "calculés" en fonctions des résultats des API Win32 qui donnent le chemin vers les répertoires "remarquables" du système.

Genre: datas/configuration.txt.

Bin non, ici, c'est un chemin relatif, vu qu'il ne commence pas par "/" ou pas un "nom" de lecteur "x:/".
L'utiliser c'est avoir "$$LeWorkingDirectory$$/datas/configuration.txt", mais vous c'est "$$LInstallDirectory$$/datas/configuration.txt" que vous voulez => utilisez l'API GetModuleFileName pour avoir $$LInstallDirectory$$ (si vous mettez l'exécutable à la racine du répertoire d'installation dans l'outil de génération de MSI).

Puis si il veut le modifier, il assume.

Vous allez assumer la hotline ?
Voyez avec vos administrateurs informatiques pour que le répertoire d'installation soit dans une zone "sûre".

mettre chaque fichier dans son répertoire qui lui sera spécifique.

Pourquoi ??? faites simple. Un fichier par rôle, dans le répertoire qui lui correspond. Et c'est souvent dans le répertoire d'installation.

Du coup, comment les mettre à la racine d'installation? Le MSI le fait?

Oui

Comment l'éditer avec un MSI? Liens pour voir?

Les outils de création de MSI ne sont généralement pas là pour faire de l'édition de fichier. C'est pas leur rôle. Ils prennent les fichiers qu'on leur a donnés en paramètre et ils les colles dans le fichier MSI avec les informations pour indiquer au service d'installation msiexec.exe où les mettre par rapport au répertoire d'installation.

J'avais peur d'une modification de l'utilisateur

C'est aux administrateurs réseaux de faire correctement leur boulot, toi, tu dois leur simplifier la tâche => MSI est ton ami.

mais si je le met dans son répertoire à la racine d'installation

Attention aussi à la sécurité de l'OS qui fait son travail.

et q'il le modifie c'est son problème.

Si pour ça, il a contourné la sécurité mise en place par les administrateurs informatiques.