maintenance des assemblys de bibliothèque de classes utilisés par plusieurs projets

Question

Bon, alors voici le scénario.

Le projet A a développé une bibliothèque de classes (appelons-la MyLib). Je lance le projet A (projet interne) avec la version 1 de MyLib.

Je commence le développement sur le projet B, mais étend MyLib à la version 2, y compris quelques optimisations aux types existants. Si je lance Mylib 2 sur le projet A et sur le projet B, je vais devoir recompiler le projet A pour prendre en charge les changements de type, est-ce que quelqu'un a des solutions à ce problème?

Answer 1

Mon conseil: Intégration continue.En utilisant un outil comme CruiseControl.NET, vous pouvez faire une reconstruction de chaque projet/solution qui existe, même avoir la sortie de l'un (le fichier .dll) téléchargé dans Source COntrol pour être utilisé par d'autres projets, faire exécuter des tests unitaires à chaque fois, vous pouvez vérifier si les ajouts/modifications dans un projet utilisé dans la solution A ne brisent pas la solution B utilisant également ce projet. Vous pouvez définir la génération sur Automatique chaque nuit ou en déclencher une manuellement à partir de l'application systray CruiseControl.NET.

Answer 2

Vous pouvez essayer assembly redirection et charger le projet A dans la nouvelle version de votre bibliothèque. Cela nécessiterait que vous ajoutiez les informations de redirection à la configuration de toutes les machines sur lesquelles l'application est exécutée mais que vous n'auriez pas à recompiler. Vous pouvez le faire dans le fichier de configuration de l'application ou au niveau de la machine.

Un exemple de cet article de ce que le fichier ressemblerait à ceci:

<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
     <assemblyIdentity name="myAssembly" 
      publicKeyToken="32ab4ba45e0a69a1" 
      culture="en-us" /> 
     <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
</configuration> 

Bien sûr, si vous avez cassé la compatibilité avec votre bibliothèque d'origine dans la nouvelle version cela ne va pas travailler.

Answer 3

Si vous n'aimez pas la redirection de la direction d'assemblage de @ Steven et si vous NE voulez PAS recompiler le projet A, vous pouvez simplement déployer différentes versions de MyLib dans chaque projet.
Le projet A continuerait alors simplement à utiliser la version 1, et le projet B utiliserait la version 2. Cela semble être ce que vous voulez entendre - et c'est trivial à faire. Placez la DLL MyLib dans le dossier (ou sous-dossier) de chaque projet et chaque projet récupérera automatiquement la version locale respective, ou vous pouvez les nommer fortement dans le GAC, et chaque projet récupérera la version spécifique que vous avez compilée.
C'est en fait le comportement par défaut, et vous n'avez rien à faire de complexe pour y parvenir.

Answer 4

Donner à MyLib strong name et install it to the GAC. Le GAC peut avoir plusieurs versions du même assembly. Il faudrait donner un nom fort à la version 1 de MyLib (pas seulement la version 2).

Le projet A veut la version 1 de MyLib et la trouve dans le GAC. Le projet B veut la version 2 de MyLib et la trouve dans le GAC. Tout le monde est content, et vous n'avez pas besoin de garder 30 copies des différentes versions de MyLib dans les mêmes répertoires des assemblées qui les utilisent, recréant DLL-enfer.

Je sais que AviD a également mentionné le GAC, mais comme une alternative aux copies privées pour les exécutables. Je pense que cela devrait être évité.

Answer 5

Voici une autre option, bien que vous deviez sérieusement considérer les autres options en premier.

ProjectA références MYLIB.DLL, qui se trouve être la version 1.

Régler le nom de sortie du projet MyLib pour produire "MyLib.2.dll". (Vous pouvez également créer un nouveau projet, mais cela ressemble à une surcharge.)

Reconstruire MyLib et ProjectB. ProjectB référencera maintenant MyLib.2.dll, laissant ProjectA et MyLib.dll complètement non affecté.

Answer 6

Votre question est assez générale. Que veux-tu faire? Le projet A devrait-il utiliser la version 2 de votre lib ou l'ancienne version?

Si A doit utiliser la version 1, une dénomination forte ou un déploiement privé devrait résoudre votre problème. Mais je pense que vous n'auriez pas posé la question.

Si A doit utiliser la version 2, la solution dépend de vos modifications. Si l'interface de l'assemblage n'a pas changé (mais seulement les algorithmes internes) alors A devrait fonctionner avec V2 sans recompilation. Si l'interface a changé, vous devrez ajuster le projet A de toute façon et il ne peut y avoir de solution générale.

Pour garder les changements requis, un petit managable est une question de bonne conception d'objet/interface. Mais comment faire cela ne peut pas être répondu sans détails sur vos objets et les changements requis.

Answer 7

Je voudrais mettre tout mon code dans un contrôle de version comme Subversion (utilisation de branches et de balises) et automatiser le processus de construction. J'utilise FinalBuilder.

Parce que vous avez le contrôle sur la bibliothèque, je recommanderais release branches pattern.