2

我们需要找到一种合理的方法来管理我们内部的 .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非常痛苦。否则，这将是我的首选解决方案。
  • 使用 svn:externals 解决依赖关系。我不喜欢这个有两个原因：
    • svn:externals 强迫我处理源代码，而不是只处理二进制文件（如上面概述的解决方案）。我不想将使用该库及其源代码的每个项目都搞得一团糟。
    • 不知何故，使用 SVN 管理依赖项（至少在我看来，应该用于管理版本控制）感觉不对。我还认为 svn:externals 使跟踪特定项目的依赖关系变得困难，并使项目过于依赖 SVN。

如果有人能指出我首选解决方案的任何潜在问题，或者您认为它有任何问题，我将不胜感激。另外，如果我试图重新发明轮子并且已经有一些标准化的解决方案来解决这个问题（除了我提到的替代方案），请不要犹豫，启发我:)

非常感谢！

4

1 回答 1

2

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

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

于 2012-03-19T15:43:47.470 回答