mars
2013
Un article de benji_dv
Les projets informatiques de taille conséquentes sont notre quotidien (refonte de SI, utilisation de nombreuses interfaçages extérieur au projet initial, etc).
Si on ajoute le respect des bonnes pratiques (ex : couplage faible entre couches > l’utilisation de mécaniques d’injections de dépendances – en d’autres termes, Article sur les IOC),
On obtient des fichiers solutions Visual Studio dont le nombre de projet excède largement la douzaine projets…
ce billet propose juste une piste de travail pour ce genre de problématiques…
Or, d’après les cahiers blancs MS (Un bon guide de mise en place des pratiques TFS), des fichiers SLN de plus d’une douzaine de projet ont des conséquences fâcheuses sur le projet :
– Absence d’optimisation des assemblies à la compilation, (je confirme)
– Temps de compilations excessifs sur les machines des développeurs (je confirme)
– Temps de compilations excessifs sur les agents de builds (intégration continue), (je confirme)
– Piètre performance au chargement de la solution (je confirme)
– …
La solution consiste à considérer les stratégies décrites dans le cahier blanc, pour éventuellement aboutir sur un Multi SLN.
Exemple :
– SLN1 : Projets totalement indépendants des projets de la solution (drivers, API client de partenaires extérieurs, API commune à l’entreprise)
– SLN2 : Projets de la couche de services, la DAL, etc.
– SLN3 : Projets propres à la couche de présentation
L’exemple ci-dessus est une stratégie, d’autres stratégies existent.
La règle, en termes de références entre projets, est la suivante : tous les projets situés au sein du même SLN peuvent se référencer entre eux, les liens entre projets de solutions différentes doivent se réaliser par DLL.
Dès lors, les outputs des projets des solutions (excepté celle de présentation) doivent être archivées (par solution) afin de ne pas forcer les développeur à devoir régénérer toutes les SLN lorsqu’un autre membre de l’équipe modifie une couche intermédiaire.
En d’autres termes :
– les outputs des projets de la SLN1 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN1) puis archivés.
– les outputs des projets de la SLN2 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN2) puis archivés.
La commande xcopy à placer dans le postBuild Event du projet est la suivante :
xcopy /E /Y /D /R « $(TargetDir)*.* » « $(SolutionDir)_Build-SLN-1-[SlnName] »
/E : Copie les répertoires et sous-répertoires, y compris les répertoires vides
/Y : Supprime la demande de confirmation de remplacement de fichiers de destination existants
/D : Copie les fichiers modifiés à partir de la date spécifiée. Si aucune date n’est donnée, copie uniquement les fichiers dont l’heure source est plus récente que l’heure de destination
/R : Remplace les fichiers en lecture seule
La dernière option est très importante, car les dll’s de destination sont en Read Only (puisque archivées sur TFS)… Sans le /R, on peut avoir des erreurs comme :
Error 3 The command « xcopy /E /Y /D « E:\DEV\…\MonProjet\bin\Debug\*.* » « E:\DEV\_Build-SLN-1-SlnName » … exited with code 4.
Astuce : Pour vérifier le message d’erreur réel : copier la commande remontée par Visual Studio lors des erreurs de build liées à xcopy dans une invite de commande et l’exécuter !
Un dernier point : Si vous êtes confronté à ces problèmes de solutions complexes, je vous invite à
– lire le document cité ci dessus afin d’élaborer une stratégie de multi SLN (non trivial),
– échanger avec les membres de l’équipe, car en définitive ce sont eux qui exploiteront les SLNs !
Enjoy !