Y'en a qui ont essayé, ils ont eu des problèmes...
Hello,
Je vois plusieurs problèmes dans ton appli.
Tout d'abord, sache que les chemins physiques en web, c'est le "mal" !!! C'est à proscrire absolument.
En effet si, sur une page web, on a une url de type "file://c:/mon_repertoire/mon_fichier.txt", cela fait référence à un fichier qui est sur TA machine, et non pas sur le serveur. Cela signifie que quelqu'un qui accède à cette page web depuis sa machine à lui n'aura de toute façon pas accès au fichier qui se trouve sur TON disque.
Sachant cela, pour accéder au fichier qui nous intéresse, on a besoin d'une url Web de type "http://www.ledomaine.com/mon_repertoire/mon_fichier.txt". Or, il n'est pas possible à ma connaissance de transformer un chemin physique en chemin virtuel web* : Server.MapPath(...) sert à faire l'inverse, Control.ResolveUrl(...) transforme une url relative en url absolue, donc rien à voir.
La solution : il faut stocker des urls (relatives, partielles ou absolues à toi de voir) en BDD, ce qui permet :
1. d'accéder si besoin au fichier sur le disque grâce à Server.MapPath(...) ;
2. de construire des liens qui marchent grâce éventuellement à ResolveUrl(...).
En résumé, le champ 'lienFichier' doit contenir des valeurs de type :
- '/mon_repertoire/mon_fichier.txt',
- ou 'mon_fichier.txt' (si tu as stocké par exemple dans ton web.config que tous tes fichiers à télécharger se trouvaient dans '/mon_repertoire/'),
- ou une combinaison des deux si tu utilises une arborescence un peu plus compliquée.
Bien sûr, si tu veux, en plus, sécuriser l'accès aux fichiers ("seules certaines personnes ont accès à certains fichiers"), cela se complique un peu, mais la logique du stockage des urls reste la même.
* à moins de faire sa propre bidouille, mais je déconseille.
