2010-06-21 3 views
0

J'ai une bibliothèque que j'ai écrit avec une structure comme celle-ci:Utilisation correcte des sous-modules dans les solutions .NET

SolutionA\ 
--Source\ 
    --Core\ 
    --Tests\ 
--Tools\ 
    --TestFramework\ 
    --MockTool\ 
SolutionA.sln 

Je veux inclure cela comme un sous-module pour SolutionB. Si j'utilise toute cette structure comme un sous-module, j'obtiendrai un tas de choses dont SolutionB ne se soucie pas; il ne se soucie pas de SolutionA.sln; il ne se soucie pas de Tests\; il ne se soucie pas de Tools\. Vraiment, SolutionB se soucie seulement de Core\.

Il semble que j'ai besoin d'un référentiel séparé pour Core\. Alors est-ce une pratique habituelle d'avoir deux référentiels pour les solutions .NET dont la source est utilisée par d'autres solutions? Un pour seulement le code (non-test) lui-même (plus les bibliothèques nécessaires), et un pour les outils de test et le fichier de solution?

+1

Partagez-vous vraiment la source entre les solutions? Ou avez-vous vraiment besoin de compiler "Solution A", puis de partager sa DLL de bibliothèque de classes avec d'autres solutions? – David

+0

C'est en fait ce que j'ai fait, mais comme de plus en plus de solutions se réfèrent à SolutionA, il devient très difficile de copier sur une nouvelle DLL à chacun quand je fais une mise à jour. –

Répondre

1

Les solutions sont simplement des conteneurs pour un ou plusieurs projets; qui peut tomber sous le même dossier "solution" ou quelque part à l'extérieur.

Si vous avez un projet, dans ce cas "Core", vous pouvez référencer cette source de projet directement depuis une ou plusieurs solutions. Dans ce cas, SolutionA et SolutionB.

Les éléments externes tels que Tests \, TestFramework \, MockTool \, etc., sauf si requis par Core, n'ont pas à être inclus dans votre autre solution.

Avez-vous du sens?

+0

Je vois ce que vous dites, mais j'ai besoin de mon serveur de build pour pouvoir tirer ce dont il a besoin pour construire SolutionB tout seul. Je pourrais mettre en place manuellement la structure .sln sur le serveur de construction, et avoir des dépôts dans ce dossier, mais je préfère avoir une stratégie clone-n-go ici. (Build serveur -> git clone uri/vers/SolutionB.git -> go). –

+0

(Avec peut-être un sous-module init + update, quel plugin git de TeamCity peut être configuré pour faire) –

+0

A la réflexion, je vais probablement finir par utiliser cette solution (avec quelques modifications). Il y a simplement trop de ressources partagées parmi les dépôts à copier dans chacun d'eux, et j'écris tellement d'applications sur mesure qu'il y aura beaucoup plus de dépôts. –

0

Vous POUVEZ le résoudre avec git-submodules (votre balise m'indique que vous utilisez git). Je ne sais pas ce que la "pratique habituelle" pour ce genre de choses est.

En réponse à ma question sur la façon de traiter les sous-modules, dirk a proposé d'utiliser NuGet (le gestionnaire de package pour le .NET Framework. Voir http://nuget.org) pour résoudre un problème lié. Semble être un bon choix pour vous, car vous obtiendrez des mises à jour contrôlées pour la DLL, gestion de la dépendance si vous en avez besoin et (au moins du côté du client) un bon support d'outils.

Scott Hanselmann a un bon article comment intégrer nuget dans l'intégration continue.

Questions connexes