Question

我们需要找到一种合理的方法来管理我们的内部.NET库，这些库可能会被多个项目重用。谷歌搜索和思考这个问题几个小时导致我得出结论，我想继续：

对于我们拥有的每个库的每个版本，我们的构建服务器（Jenkins）上都会有一个单独的作业。在成功构建库之后，构建输出（通常是.dll文件）将被复制到公共网络存储库。此存储库的结构可能与此类似：

-libraryA
    -1.0
        -libraryA_1.0.dll
    -1.1
        -libraryA_1.1.dll
-libraryB
    -1.0
        -libraryB_1.0.dll

每个想要使用库的项目都会附带一个简单的.bat文件，该文件将必要的库从此存储库复制到专门用于存储项目依赖项的文件夹。然后，将从此文件夹引用依赖项。示例项目可能如下所示：

-project
    -src
    -dependencies
        -libraryB
            -1.0
                -libraryB_1.0.dll
    -getDependencies.bat

getDependencies.bat将始终删除dependencies文件夹的内容，并从存储库中获取新的库副本。它将在Jenkins的每个项目构建之前执行。 dependencies文件夹永远不会被提交给SVN。

我也考虑过一些替代方案：

使用自定义NuGet提要而不是简单存储库。我已经放弃了这个，因为我已经发现，使用Visual Studio 2008中仍在我们公司使用的NuGet是quite a pain。否则，这将是我的首选解决方案。
使用svn：externals来解决依赖关系。我不喜欢这个有两个原因：
- svn：externals强制我处理源代码，而不是只处理二进制文件（如上面概述的解决方案）。我不想让每个使用该库及其源代码的项目混乱。
- 不知何故，使用SVN管理依赖（我认为至少应该用来管理版本控制）感觉对。我还认为svn：externals很难跟踪特定项目的依赖关系，并使项目过于依赖SVN。

如果有人能指出我首选解决方案的任何潜在问题或者您认为错误的任何问题，我真的很感激。此外，如果我试图重新发明轮子，并且已经有一些标准化的解决方案，每个人都在使用（除了我提到的替代品），请不要犹豫，赐教我:)

非常感谢！

Answer 1

您只需要各个版本的库来进行更改。添加新功能和修复错误并不能保证新的版本。此外，使用库的项目应保留他们在其源存储库中使用的二进制文件的副本。

这使您能够在准备好之前更改和修改共享库，而无需强制更改各个项目。项目可以按照他们准备好的速度接受它们，通过获取准备好的最新版本，并在对变更感到满意后将这些新二进制文件检入其源代码控制中。