2009-09-13 9 views
1

Utilisation de subversion et de Nant pour la construction. J'ai un projet principal qui dépend de plusieurs sous-projets. Les sous-projets existent en tant que projets séparés à l'intérieur de subversion.Nant: création de projets à l'aide de svn-externals

Ma question est: Est-ce que le script de construction nant dans le projet principal doit construire tous les sous-projets référencés et lui-même? Ou est-ce que les sous-projets savent comment se construire et j'appelle d'une manière ou d'une autre les fichiers de construction du sous-projet à partir du fichier de construction principal et assembler en quelque sorte tous les résultats dans la sortie de construction des projets principaux?

J'ai actuellement le fichier de construction de mainproject construire tous les sous-projets. C'est-à-dire que j'ai des cibles nant pour chaque sous-projet dans le fichier de construction. Cependant, cela semble créer un couplage étroit entre le fichier de construction principal et les sous-projets. Ce serait bien si je pouvais juste dire «les sous-projets savent comment se construire» et leur demander de se construire à partir du projet principal et d'assembler les résultats.

Pour référence, mon dépôt ressemble à:

/Repo 
    /MainProject 
    /trunk 
     /doc <-- documentation 
     /lib <-- binary-only DLLs (usually 3rd party) 
     /src <-- source code for MainProject 
     /svn-externals <-- hold references to other projects in repository 
... 
    /ClassLib1 
    /trunk 
     /doc 
     /lib 
     /src 
     /svn-externals 
... 
    /ClassLib2 
    /trunk 
     /doc 
     /lib 
     /src 
     /svn-externals 
... 
    /ClassLibCommon 
    /trunk 
     /doc 
     /lib 
     /src 
     /svn-externals 

Je tire dans les sous-projets en utilisant la subversion propriété svn-externals. Donc, ma copie de travail est comme ceci:

/MainProject 
    /build 
    /doc 
    /lib 
    /src 
    /MainProject 
    /svn-externals 
    /ClassLib1 <-- svn external to svn://xyz/repo/ClassLib1/trunk 
     /doc 
     /lib 
     /src 
     /svn-externals 
     /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk 
      ... 
    /ClassLib2 <-- svn external to svn://xyz/repo/ClassLib2/trunk 
     /doc 
     /lib 
     /src 
     /svn-externals 
     /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk 
      ... 

Répondre

0

La réponse à votre question est bien sûr "ça dépend".

Ce que vous ne dites pas, c'est comment vous faites référence aux "sous-projets" dans votre solution ou s'ils sont utilisés par d'autres solutions (projets principaux)? Sont-ils des références de projet? Si oui, nant appelle MSBuild pour construire la solution. Cela va construire tous les sous-projets basés sur ces dépendances. Je ne peux que supposer que c'est ainsi que vous l'avez mis en place. Personnellement, si j'avais une configuration qui ressemblait à votre, je n'utiliserais pas de références de projet et je n'aurais pas d'éléments externes pour tout le code de chaque projet. Je traiterais ces sous-projets de la même manière que vous traitez vos DLL tierces.

Si vous l'avez fait, vous utiliserez des références DLL. Cela découpe les sous-projets de votre projet principal. C'est ainsi que j'irais, surtout si ces sous-projets sont référencés par d'autres projets. Oui, vous devez maintenant prendre d'autres décisions ... par exemple, comment stocker celles qui sont dans le contrôle de source. Vous pouvez avoir des externes dans votre dossier lib ... ou vous pouvez simplement mettre une copie de la DLL dans votre dossier lib. Cela dépend également de la façon dont vous voulez contrôler le versionnage. En outre, vous ne mentionnez pas si vous utilisez un type de CI tel que CC.Net. Si vous l'avez fait, vous pouvez le faire déclencher une reconstruction du projet principal si l'un des sous-projets est modifié.

+0

Les projets de bibliothèque sont utilisés par d'autres projets "principaux". Ce sont des références de projet. Deux choses: 1. Les bibliothèques changent fréquemment. 2. Je pensais que la sagesse conventionnelle est de ne pas stocker les binaires pour les choses dont vous avez le code source. – User

+0

Cela dépend. Pour moi, ne pas référencer un projet dans plus d'une solution sur les manèges que. Je considère que les bibliothèques partagées ne font pas partie du projet principal. Donc, tout comme je mets mes DLL de rapport Crystal dans svn, j'y mets aussi mes DLL Framework internes. De plus, les références DLL vous donnent plus de contrôle sur la version de la bibliothèque que vous utilisez avec chaque projet. Bien sûr, vous pouvez faire ce qui précède et ne pas mettre les binaires dans svn. Mettez-les sur un partage réseau. – PilotBob

+0

"Pour moi, ne pas référencer un projet dans plus d'une solution remplace cela" Je ne suis pas sûr de comprendre cela.Juste pour clarifier, quand j'utilise le terme «projet», je veux dire dans le sens général, pas dans le sens du studio visuel. Donc à mon avis, par définition, un «projet» de bibliothèque de classes (en fait, c'est sa propre solution) est destiné à être utilisé dans plus d'une solution. – User

Questions connexes