Gestion de Debug / Release et référence de projet / d'assembly

Hello à tous,
un titre énigmatique pour un problème difficile à décrire de façon concise :)

Voila. Supposons que l'on developpe plusieurs applications (dont App1.exe), dans plusieurs solutions différentes. Il y a de fortes chances que ces applis aient des références en commun, sur une assembly que l'on a développé (disons Lib.dll). On a alors deux choix :

• Soit inclure le projet Lib dans la solution du projet App1, et rajouter une dependance inter projet
• Soit ajouter une référence vers Lib.dll

L'avantage de la seconde solution est entre autres d'accélérer la compilation.
Mais !
Contrairement a Visual C++, il n'est pas possible d'avoir des references differentes entre Debug et Release. Et pourtant, quand on debugue, on veut aussi bien debuguer l'exe et la dll en meme temps.
Ma question est donc la suivante : quel est le meilleur moyen de referencer une assembly dont on se sert dans de nombreux projets ? Est-ce que vous integrez leurs projets dans toutes vos solutions ? Ou bien avez-vous cette Lib dans une solution a part, et ne referencez ensuite que la version compilée ?


Un collègue, habitué a C++, a DEDOUBLE tous ses projets et solutions : avec un APP1_D.csproj, un APP1_R.csproj, APP1_D.sln, APP1_R.sln, et APP1_D.csproj qui va référencer l'assembly \Debug\Lib.dll et APP1_R.csproj qui va referencer l'assembly \Release\Lib.dll. Avec la solution ..._D a ne compiler qu'en debug, et ..._R qu'en release.

C'est un poil la *@\#$ a synchroniser, en plus d'être moche. Des idées ? des bonnes pratiques à suggérer ?

Note : je code en C#, mais la problématique est sûrement plus générale.

J'ai le meme genre de problématique, et j'utilise la même solution que ton collègue (fichiers csproj dupliqués qui utilisent les mêmes sources avec éventuellement des références différentes). C'est vrai que c'est un peu galère :?

Je me demande s'il n'y a pas moyen de gérer ça plus proprement avec MSBuild, mais je me suis pas encore penché sérieusement sur la question...

Citation:

---

Envoyé par tomlev

Je me demande s'il n'y a pas moyen de gérer ça plus proprement avec MSBuild, mais je me suis pas encore penché sérieusement sur la question...

---

Il est possible en effet de modifier le csproj à la mano, de dédoubler les références, et de leur mettre des conditions, ça ressemble en gros à ça :

Code:

---

1 2 3

<ItemGroup> <Dependency>..\..\Release\Lib.dll</Dependency> <ItemGroup>

---

devient

Code:

---

1 2 3 4 5 6

<ItemGroup Condition config=DEBUG> <Dependency>..\..\Debug\Lib.dll</Dependency> <ItemGroup> <ItemGroup Condition config=RELEASE> <Dependency>..\..\Release\Lib.dll</Dependency> <ItemGroup>

---

Un tel fichier csproj, filé en ligne de commande a MSBuild ou compilé directement depuis visual, aura bien le comportement attendu.
Mais du coup ca apparait moche dans l'explorateur de solutions, ca nécessite de refaire la modif a la mano dans le fichier csproj en cas de changement de la réf, et ca génère des bugs par ci par la. Dont un qui m'a fait perdre deux heures aujourd'hui : l'assistant permettant de rajouter une DataSource de type Objet n'aime pas cette manip, parce qu'il doit parcourt l'ensemble des assemblies dispos pour le projet courrant, et semble supporter très mal qu'une référence soit en double :aie:

Tout ca m'enquiquine depuis un certain temps... :evilred:

Bonjour,

Une proposition qui marche pour mes projets :

Code:

---

1 2 3

<ItemGroup> <Dependency>..\..\$(Configuration)\Lib.dll</Dependency> <ItemGroup>

---

Mais je ne sais pas ce que ça donne pour les sources de données :(

Citation:

---

Envoyé par cboun94

Mais je ne sais pas ce que ça donne pour les sources de données :(

---

Excellent ! Ca a l'air de plaire a l'explorateur de solutions, et dans les propriétés d'une telle référence, on voit bien que le path change entre Debug et Release !
Et le designer de datasources ne bronche plus ! Faut que je fasse des tests complémentaires, mais ça a l'air impec.

Merci !

[edit] Après de plus amples tests et quelques recherches complémentaires sur le net, il semble que ce soit la bonne façon de faire.

:resolu: