Discussion :

[alavoler]

Bonjour,

Dans mon entreprise nous avons plusieurs produits. Ces produits utilisent des librairies communes (essentiellement en .Net).
Il existe 2 types de librairies communes:
- interne (dont nous avons les sources)
- externe (librairie payante)

Aujourd'hui chaque produit/projet a son propre répertoire locale de librairies (donc un répertoire lib pour chaque projet dont on fait pointer la référence, ce répertoire est archivé sur svn comme le reste du projet).

Le problème vient du fait que chacun utilise sa propre version de lib commune, qu'il appartient au chef de projet de mettre à jour avec la version courante (ce qu'il ne fait pas forcement...).


1- Ma première idée simple à réaliser: c'est de faire pointer tous les projets sur un répertoire partagé "MyCommonLib\Current" qui sera mis à jour quand la version de la librairie commune sera considérée comme stable.
Comme ça à la compilation de chaque projet on est certain que tous nos produits utilisent la dernière version stable.
Le problème: au moment où l'on doit faire un hotfix (revenir sur une version antérieure au produit), l’état de la révision ne sera pas exactement le même qu'il y a un an (c'est la limite de pointer sur des répertoires partagés, c'était l'avantage de livrer un répertoire lib dans chaque projet...). Ca peut avoir quelque fâcheuse incidence (assez limité genre le projet ne compile pu car une librairie commune a changé)



2- Utiliser un gestionnaire de dépendance, j'avais testé sur java / eclipse, ce genre de bousin, et ça m'avait l'air très laborieux (maven). Et de mémoire ça ne résout pas mon problème de devoir utiliser la dernière lib stable...


3- faire une espèce de script avant build, qui va mettre le répertoire Lib à jour. Comme ça dans le gestionnaire de Source on a la lib commune réellement utilisée à l’époque !...



Si vous avez un feetback, je suis preneur !

[sisqo60]

Bonjour,

C'est toujours source de problèmes, mais pour faire des choix, il faut savoir comment vous travaillez, quelle est la taille de l'équipe etc...

[alavoler]

Salut !

Petit équipe (8 personnes), pour presque autant de produit

Sous VS2010, SVN tortoise/ankh.

On utilise des répertoires partagés pour publier les versions.

[theMonz31]

salut

si tu utilises SVN ou autre gestionnaire de version, tu peux "taguer" ta version pour savoir laquelle utiliser...

Au "pire", tu pourrais meme de faire un "NuPack" pour ne plus te poser de question...

[antoine.debyser]

Bonjour,

Je vois pas d'autre solution que celle que tu proposes.
1) Le probleme de cette solution, c'est bien la reproduction de bug. C'est une fausse bonne idée
2) Comme le dit theMonz31, NuGet répondra simplement a ce besoin
3) Ca reviens à 1)

Mettre à jour des librairie externe n'est pas anodin, de mon expérience dans les 2/3 des cas la nouvelle version est rétro-compatible, mais dans le 1/3 restant c'est pas le cas, et là c'est la galère.

Toujours de mon expérience la bonne solution c'est de laisser les projets ce mettre a jour.
Que ça soit totalement manuellement, ou de manière packagé via NuGet.

Les gestionnaires de dépendances ne mettent à jour les dépendance que sur demande, mais ils fournissent un ensemble cohérent.
Les gestionnaires de dépendances ne gèrent pas a ma connaissance les versions incompatible

Bref, laisse les projets ce mettre à jours.
Et comme le dit theMonz31, toutes version d'une (ou d'un groupe de) librairie doit avoir sont tag SVN. Le numéro de version des librairies doit permettre de retrouver le tag SVN.
Sans ce type d'information, la reproduction de bug peut devenir un cauchemar.

[alavoler]

OK merci les mecs d'avoir pris le temps de répondre sur cette question pas forcement lié au C# en elle même,

Conclusion, on fait rien de plus : Ne pas oublier d'envoyer un mail à chaque publication de lib commune, et charge au chef de projet de ne pas oublier de l’intégrer...
Ça me chiffonne quand même un peu... surtout pour les lib internes, mais bon je vais mis faire