Changer le chemin de sortie des dll référencés

Bonjour,

Etant entretien d'utiliser un ensemble de bibliothèques dans mon projet sous Visual Studio 2013 en c#.

Après le "Build" je retrouve ces descendances (EntityFramework dlls, Sql CE dll....) dans le même répertoire que le fichier EXE résultant.


J'aimerai mettre ces fichiers DLL dans un répertoire "LIB" est les classer aussi.

ex: LIB\Database\ on retrouve EntityFramework dlls et SQL Ce DL .....

LIB\Controls\ on retrouve MyControle.dll ,.....



Je vous remercie pour votre attention.

Pour créer cette arborescence tu peux utiliser un "Post-build event".

Mais sache que ça n'a à priori aucun intérêt et que ça va aussi compliquer le chargement des assemblies qu'il te faudra donc personnaliser en renseignant des "private path" dans ton app.config.

Pourquoi veux-tu faire ça ?

Citation:

---

Envoyé par Pragmateek

Pour créer cette arborescence tu peux utiliser un "Post-build event".

---

SVP

Pouvez-vous me dire comment ?

Citation:

---

Envoyé par Pragmateek

Mais sache que ça n'a à priori aucun intérêt et que ça va aussi compliquer le chargement des assemblies qu'il te faudra donc personnaliser en renseignant des "private path" dans ton app.config.

Pourquoi veux-tu faire ça ?

---

.....car j'aime pas trop le désordre..

Exemple:

SQLite me crée de dossiers appelés 'x86', 'x64' et aprés dans chaque un le dll pour l'architecture du système. Donc moi jeux les avoir dans Lib/SQLite/x86 | Lib/SQLite/x64 par exemple.

Citation:

---

Envoyé par nadjibnet

Pouvez-vous me dire comment ?

---

Dans les propriétés du projet tu as un onglet "Build Events" (ou équivalent en français).
Dans le champ "Post-build event command line" tu peux mettre un script :

Code:

---

1 2 3

mkdir Lib\SQLite move x86 Lib\SQLite move x64 Lib\SQLite

---

Tu peux aussi créer un bat et l'exécuter si jamais tu en as besoin dans plusieurs projets.

Par contre fais attention aux effets de bord et ne t'étonne pas d'avoir des FileNotFoundException ou FileLoadException et autre joyeusetés...
Assure toi de bien scanner tous les chemins d'exécution utilisant les assemblies que tu déplaces, parce que le fait que l'application se lance ne veut pas dire que tout est OK, en effet le chargement des assemblies par le CLR se fait à la volée.

Citation:

---

Envoyé par nadjibnet

.....car j'aime pas trop le désordre..

---

Le désordre est embêtant pour les humains, là ton dossier "bin" ne sera manipulé que par des machines donc ce n'est pas un souci. :)

Merci infiniment je vais tester

Citation:

---

Envoyé par Pragmateek

Le désordre est embêtant pour les humains, là ton dossier "bin" ne sera manipulé que par des machines donc ce n'est pas un souci. :)

---

Hhhhhh :ccool: