Hello,
Etant donné le peu d’enthousiasme généré par cette question sur le forum Winforms, je me permets de la poser également ici (via le lien donné précédemment dans la phrase).
Merci d'avance.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[VS2013 Pro]Inclure un fichier dans les fichiers générés en sortie par un projet
Hello,
Etant donné le peu d’enthousiasme généré par cette question sur le forum Winforms, je me permets de la poser également ici (via le lien donné précédemment dans la phrase).
Merci d'avance.
Kropernic
Hello
Si mes souvenirs sont bons, tu vas dans "My Project" / Publish / Application Files.
Et là tu peux dire ce qui est inclus ou pas à l'installation. (Si tu utilises le publish.
Si tu utilises un programmes d'installation ca devrait être encore plus simple.
L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)
Merci pour la réponse mais euh... Non ^^ (ou alors j'ai pas compris).Envoyé par mactwist69
En fait, j'ai crée une bibliothèque de classe qui a son fichier de configuration. Ce fichier, j'ai bien mis comme action "Toujours copier" dans ses propriétés. Et de fait, quand je compile ma bibliothèque de classes, je retrouve bien le fichier de configuration dans le répertoire bin/debug.
Maintenant, quand je veux utiliser cette bibliothèque de classe, j'ajoute donc un lien vers son fichier .dll dans les références d'un nouveau projet et j'aurai bien accès à tous ces objets.
Si je compile ce nouveau projet, je vais bien retrouver le fichier .dll de la bibliothèque dans le répertoire bin/debug du nouveau projet mais pas le fichier de config de la dll. Et du coup, bin ça marche beaucoup moins bien.
Faut-il également ajouter une référence vers ce fichier ? (ça me semble bizarre mais cette idée vient de me traverser l'esprit.)
Kropernic
Re,
En cherchant un peu, j'ai trouvé deux ou trois trucs que je me doutais.
D'instinct j'aurai dis qu'il vaut mieux compté sur un seul fichier de config, celui du projet et pas des bibliothèque de classe.
On pourrait apparemment faire les deux.
Voici deux solutions proposé (que je n'ai pas testé moi même), trouvé sur ce même forum:
http://www.developpez.net/forums/d12...n-introuvable/
http://www.developpez.net/forums/d72...er-app-config/
L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)
Le premier lien donne la solution que j'utilise actuellement. C'est-à-dire copier le fichier manuellement.
Le second lien propose de recopier le contenu du fichier de config de la bibliothèque dans le fichier de config du projet appelant. Je trouve ça un peu gros :-/
Exemple : Une application avec les couches suivantes : GUI, BLL, DAL et DTO. Chaque couche est un projet bien spécifique (i.e. : pas dans la même solution).
Lors du développement de la couche DAL, il faut bien spécifier le serveur de DB auquel se connecter. Et bien sûr, hors de question de le mettre directement dans le code. On passe donc un fichier de config. Tout va bien.
Mais donc si je suis le raisonnement, la couche BLL qui n'a pas besoin de fichier de config va quand même devoir en avoir un dans lequel on irait recopier le contenu de celui de la couche DAL (vu que BLL consomme DAL). Et tel un virus, ce fichier de config va devoir se propager jusqu'à la couche GUI...
Y a probablement quelque chose qui m'échappe mais tout ceci me semble quand même très bizarre...
Kropernic
Ah, voilà un peu plus d'explication !!
Bon, et bien je regarde mon projet actuel, n-tiers également....
Les couches sont tous des projets VS... mais qui appartiennent tous à une même solution.
Du coup chaque projet a son fichier, pas de souci, les uns référençant les autres.
Toi ce que tu veux peut être c'est que certains développeur utilises la DLL sans voir son code. (si j'ai bien compris)
Donc tu ajoutes la DLL en référence, ce qui va faire que la dll sera recopiée dans ton dossier de développement.
J'ai bien peur qu'il faille recopier le AppConfig à la main, au même endroit...
Mais une seule fois par machine de développement, ça ne me semble pas si terrible... Si ?
Je ne connais hélas pas d'autre solution.
A part bien sur de stocker la chaîne de connexion différemment.
L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)
Je ne sais pas si ma remarque est pertinente par rapport au problème, mais le fichier de config est à mettre au niveau du client qui va consommer les DLL.
Par exemple j'ai une appli console et une appli web, j'aurais besoin de 2 config (app.config pour la console et web.config pour le web). Les DLL en tiendront automatiquement compte.
Less Is More
Pensez à utiliser les boutons
,
et les balises code
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
Et cela ne te choque pas ??
Je ne comprends pas pourquoi la couche de présentation doit s'occupe de savoir vers où vont et viennent les données...
Kropernic
Ben en théorie, ta DAL ne doit pas avoir besoin du fichier de config. Il vaut mieux charger les infos de ton fichier de config au sein d'une classe (par exemple) dans ton client, puis les faire transiter vers la DAL par la BLL lorsque c'est nécessaire.
Less Is More
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
Avec un peu plus de recherche, je confirme.
Si la une dll a besoin de paramètres dans un fichier de config, il regarde d'abord si il en existe un avec le même nom, sinon il essai dans le fichier de configuration du projet en cours.
Donc on en revient:
- Soit tout tes projets sont dans une même solution, pas de souci.
- Soit tu recopies ton fichier de configuration (à la main), la où est stockée ta dll référencée dans tes autres projets.
- Soit tu inclus les paramètres de ta dll dans le fichier de configuration de tes autres projets
Il y a des contournements:
- Stockés ta chaîne autrement.
- passé ta chaîne de connexion dans ton UI (ou ton service web ou autre), et la la faire passé en paramètre à ta DAL par exemple.
Discussion intéressante ici:
http://www.developpez.net/forums/d13...pp-config-dll/
L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)
Donc si je te suis, c'est la GUI qui doit donner à la DAL (via la BLL) la connectionstring à utiliser ?
Kropernic
Tout à fait oui, la couche UI est le point d'entrée de ton application. Si on prend par exemple une application console, tu peux indiquer des paramètres au lancement, qui seront récupérés au niveau du Main.
Donc c'est à cet endroit qu'on saura s'il faut lancer l'application en mode A (avec une base A) ou en mode B (avec une base B) par exemple.
C'est donc le client qui doit charger la bonne configuration et la transmettre à la DAL, car en règle générale, c'est le client qui décide ce qu'il faut faire, et non la DAL.
Bien entendu, il n'est pas impossible de laisser la DAL piloter, mais ça implique que le développeur du client (qui ne connait pas forcément la DAL) doit connaître ce dont elle a besoin, et ne rien oublier...
Less Is More
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
C'est vrai que ça se tient... Au moment où je code la DAL, je n'ai par exemple aucune idée de savoir si elle va servir à persister sur le serveur test ou prod...
Maintenant, ça me gêne vraiment que la GUI sache de quel serveur il s'agit. Je veux dire, au dela de savoir si elle bosse avec le serveur test ou prod, elle va connaître le nom exact de ce serveur... C'est cela qui me dérange conceptuellement...
Mon problème se situe vraiment au niveau conceptuel. Niveau sécurité, on développe en interne pour un usage interne donc là n'est pas vraiment la question ^^. C'est juste que j'aime bien faire les choses comme il faut.
Kropernic
Si le problème c'est que le nom du serveur puisse apparaitre dans le fichier de config, tu peux créer une section custom et y stocker tes ConnectionStrings cryptées. Au moment du chargement du client, tu lis ces infos, les décrypte, charge ta classe de config et tu envoie l'info à la DAL.
Less Is More
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
Je ne pense pas que se soit son problème, car comme il le dit, c'est un logiciel interne.
Je pense qu'il tique sur le fait que la connexion string sera utilisée par la DAL mais lu par la GUI. Donc ça ne "serai pas à sa place".
La dessus, je ne pense pas que se soit un problème (en logique). Car on a beau découper nos logiciels en couches pour X raisons (surtout pour des raisons de développement d'ailleurs), mais à la fin, le produit fini est "un tout", un logiciel (point de vue utilisateur), qui a donc un et un seul fichier de config. Donc perso, ça ne me choque pas.
Vouloir absolument tout séparé, n'a pas forcement de sens une fois compilé, comme le fichier de config justement.
L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)
C'est exactement ça.
A mon avis, faut juste que je me fasse une raison
Kropernic
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager