Comment référencer des assemblys partagés en cours de développement (.NET)

Question

Je suis responsable du développement et de la maintenance d'un ensemble d'assemblys-cadres communs utilisés pour créer nos applications de produits. Ces assemblages sont relativement nouveaux et en pleine mutation, de nouvelles fonctionnalités étant implémentées, etc. En conséquence, il n’est pas rare qu’ils soient reconstruits et redistribués assez fréquemment. Je m'attendrais à ce que cela diminue à mesure que les assemblées sont stabilisées, mais c'est ce qu'elle est aujourd'hui.

À l'heure actuelle, les assemblys sont placés dans un dossier commun dans lequel les projets de développement peuvent référencer les mêmes assemblys. Appliquer des mises à jour est aussi simple que de remplacer les fichiers et les projets de développement enregistrent automatiquement les modifications lors de leur prochain chargement et création.

Le problème que j'ai est que nous pouvons avoir plusieurs "couches". d’assemblées reposant sur la structure; par exemple, nous disposons d’une bibliothèque Core partagée par toutes les applications et d’une bibliothèque Server référençant Core et partagée par toutes les applications Server. Toutes les dépendances doivent également être reconstruites chaque fois que les assemblys de la structure sont mis à jour, ce qui en fait une tâche très lourde. Je ne pense pas pouvoir utiliser le GAC car cela impliquerait que tous les développeurs mettent à jour leur système chaque fois qu'une nouvelle version est publiée.

J'ai étudié les règles relatives aux éditeurs, mais je doute que cela résoudra mon problème pour plusieurs raisons:

• Tout d'abord, je ne souhaite pas recréer le fichier chaque fois que je reconstruis mes assemblages d'infrastructure: y a-t-il un moyen d'automatiser ce processus?

• Il m'est difficile de savoir s'il faut que les assemblées entrent dans le GAC. Comme je l'ai dit, je ne veux pas forcer mes développeurs à réinstaller, mettre à jour, etc. chaque fois que nous publions une nouvelle version des assemblys.

• Je n’ai aucun contrôle sur la configuration et la configuration du réseau, il est donc nécessaire d’éviter l’ensemble des "confiance". problème en plaçant les fichiers dans un partage réseau. De plus, nombre de nos développeurs travaillent parfois de manière connectée et nous souhaitons que les fichiers soient mis à leur disposition lorsqu'ils sont déconnectés.

L'objectif serait de rendre la mise à jour de ces assemblys transparente pour nos développeurs d'applications qui les utilisent. Nous allons sans aucun doute installer ces assemblages dans le GAC sur la machine cible lors de l'installation de l'application, mais nous ne souhaitons pas le faire à des fins de développement. Il n’est pas non plus raisonnable d’inclure les projets dans la solution de chaque application, car ils sont développés par différentes équipes.

Je ne peux pas imaginer que je suis seul face à ces exigences et espérer que quelqu'un pourra partager son expérience et sa sagesse afin de me guider vers une solution. Merci!

Answer 1

NuGet a résolu ce problème. En distribuant les assemblys partagés, les infrastructures, etc. sous la forme de packages NuGet à partir d'un référentiel privé de notre réseau, nous pouvons facilement publier des mises à jour et les appliquer au code client, le cas échéant.

Answer 2

Vous n'avez pas nécessairement besoin d'installer les assemblages dans le GAC - rien dans votre configuration ne l'exige.

Le principal problème ici est de s’assurer qu’un assemblage oblige toutes ses dépendances à être reconstruit et que tous ces éléments sont placés dans un emplacement partagé.

L'option la plus simple serait probablement de disposer d'un serveur de génération qui reconstruit tout à chaque fois qu'un des assemblys partagés est mis à jour. Cela présente également l’avantage d’exécuter potentiellement d’autres "scripts". sur la construction, telle que la métrique de code, l'analyse de code statique, etc., chaque fois qu'une construction est archivée.

Vous pouvez ensuite demander au serveur de construction de tout copier dans un emplacement partagé. Si les projets font référence à partir de l'emplacement partagé et disent explicitement de ne pas restreindre l'application à une version spécifique, tout devrait fonctionner correctement.