Discussion :

[sebbod]

Bonjour,

je viens d'intégrer une sociétés qui utilise MVS 2010 et TFS (depuis moins d'un an donc ils sont débutant avec les outils de DEV microsoft) or j'avais l'habitude de travailler sur MVS 2005 et VSF mais l'environnement n'est pas le problème en soit.

Le problème (pour moi) c'est qu'il y autant de solution que de base de donnée et dans ses solutions il y a entre 20 projet pour la plus petite solution et 200 projets pour la plus grosse.
Déjà 200 projets dans une solution ça me choque, pas vous ? (ça veut dire environ 200 DLL moins les exe mais bon y'a qu'une vingtaine de jobs et un exe principale).

Le plus pénible pour les développeurs comme moi c'est que dans une solution S1 qui contient le projet P1 par exemple si on veut utiliser des fonctions pour interroger une base de donnée, il faut intégrer les 20 DLL de la solution S2 qui a été prévu pour gérer cette base de donnée. C'est un peu lourd, surtout qu'en plus on peut être amener à changer 4 à 5 projets de S2 car la fonction que l'on veut n'existe pas encore dedans et donc on doit remettre à jour les 4 à 5 DLL référencé dans P1 de S1 (et cela parfois plusieurs fois par jour).

Mais dans la réalité le projet P1 de S1 fait référence à 4 bases de données donc 4 x 20 DLL dans 4 solutions différente.

Personnellement je trouve cela ingérable, j'aimerais avoir d'autre avis sur la question si vous en avez.

Merci


REM: perso ma solution serait de tout mettre dans une seul solution et d'avoir 1 projet par base de donnée et 1 par application avec des dossiers dedans pour remplacer les projets actuelles (sachant que les dossiers génères des namespaces, le code resterait bien rangé)
Au lieu d'avoir 300 fichiers dans 20 projets on les aurait dans 1 seul.

Y'a-t-il un nombre de fichier maximun pour un projet ?
Y'a-t-il un nombre de projet maximun dans une solution ?
Existe-t-il des graphiques de performance :
- temps de BUILD d'une solution par rapport au nombre de projet ou par rapport au nombre de fichier qu'elle contient.
- temps de BUILD d'un projet en fonction du nombre de fichier qu'il contient.
- temps de BUILD d'un projet en fonction du nombre de ligne de code qu'il contient.

Si quelqu'un à fait de telles études et les à publiées ça m'intéresserait

Merci encore.

[sebbod]

j'ai trouvé un article en anglais qui traite du sujet :

http://codebetter.com/patricksmacchi...et-assemblies/

il y a dedans d'autre lien intéressant parlant notamment de NDepend

[saad.hessane]

Pour moi la meilleur solution quand c'est comme ça, c'est de séparer les projets dans le dépôt et de créer des dépendances externes pour chaque projet qui l'utilise.
Je n'utilise pas TFS mais SVN. Je pense que cela doit être pareil.
En gros un projet A qui est utilisé dans les solutions S1 et S2 n'est pas directement enregistré dans SVN dans S1 et S2. Donc pas de doublons. Ce qui est enregistré dans chaqu'un d'eux c'est une réference externe. Donc quand quelqu'un qui travaille sur la solution S1 modifie le projet A, celui qui travaille sur la solution S2 n'a qu'à mettre à jours ses sources pour avoir la dernière version. On peut aussi fixer pour chaque solution le numéro de révision à utiliser.
Je ne sais pas si c'est de cela dont il s'agit, mais j'espère avoir répondu à ta question.

[sebbod]

Pour moi la meilleur solution quand c'est comme ça, c'est de séparer les projets dans le dépôt et de créer des dépendances externes pour chaque projet qui l'utilise.
Je n'utilise pas TFS mais SVN. Je pense que cela doit être pareil.
En gros un projet A qui est utilisé dans les solutions S1 et S2 n'est pas directement enregistré dans SVN dans S1 et S2. Donc pas de doublons. Ce qui est enregistré dans chaqu'un d'eux c'est une réference externe. Donc quand quelqu'un qui travaille sur la solution S1 modifie le projet A, celui qui travaille sur la solution S2 n'a qu'à mettre à jours ses sources pour avoir la dernière version. On peut aussi fixer pour chaque solution le numéro de révision à utiliser.
Je ne sais pas si c'est de cela dont il s'agit, mais j'espère avoir répondu à ta question.

Merci à toi de me répondre je commençais à me sentir un peu seul avec ce problème ;-)

J'ai effectivement pensé à l'idée que tu proposes car elle résoudrait le problème de la génération des DLL dans d'autre solutions et nous ferait gagner pas mal de temps, mais personne ne sait si c'est réalisable.
On doit recevoir un expert TFS prochainement, on lui demandera si c'est possible de partager un même projet en control de code source dans différente solution MVS et si oui comment il faut faire.

Encore merci pour ton aide

Edit
Nous réalisons les tests avec MOLES et on m'a dit que s'il y avait autant de projet dans les solutions c'était pour pouvoir faire un découpage à la DLL de la couverture de test et ainsi inclure ou exclure des DLL de cette couverture.