Nous essayons de trier certaines conventions pour la gestion des dépendances avec le code vérifié dans svn. la méthode précédente était fondamentalement libre pour tous, ce qui signifiait que les projets ne pouvaient pas être vérifiés et construits sans manipuler les références (la plupart des projets sont en C#).Auto-versioning DLL dans Visual Studio 2008
Nous corrigeons cette étape étape par étape et nous archivons maintenant les fichiers binaires dans un référentiel svn distinct. les builds sont distingués par le numéro de révision svn auquel ils correspondent, donc vous pourriez avoir un chemin comme svnrelease/libraryA/r1000/libraryA.dll. une chose est apparue comme un scénario: la bibliothèque A dépend de la bibliothèque B, le projet P dépend de la bibliothèque A, mais aussi directement la bibliothèque B. et si la bibliothèque A fait référence à la révision 1000 de B, mais la référence directe du projet P révision 2000?
J'ai suggéré d'inclure le numéro de révision dans les noms de fichiers DLL quand ils sont vérifiés dans les versions svn repo, donc plusieurs versions peuvent coexister. un collègue a suggéré que VS2k8 pourrait être capable de gérer automatiquement cela. donc si dans la bibliothèque Un projet, vous le définissez à la version 1.8, VS nomme la sortie "libraryA_1_8.dll", et dans le projet P vous pouvez avoir une référence à "$ (release) \ libraryA \ $ (version)" qui ça peut résoudre. Je n'ai trouvé aucune information sur la façon de le faire. Est-ce possible? et si non, ma méthode d'inclusion du nom de version dans le fichier binaire DLL est-elle raisonnable?
(Je sais que le scénario suggère qu'un code de refactoring peut être nécessaire, mais je cherche une solution à court terme pour résoudre le problème.) L'utilisation du GAC est également possible, mais pour l'instant nous voulons DLL avec chaque application.)