如何处理 .NET 中已发布的公共库？答案

【问题标题】：How to deal with released common libs in .NET?如何处理 .NET 中已发布的公共库？
【发布时间】：2012-02-28 10:44:05
【问题描述】：

这是SVN结构：

/trunk
    + ProjectA
    + ProjectB
    + Common
        + ProjectCore
        + References

ProjectA 和ProjectB 将交付最终产品，并且每个产品都可以有自己的发布生命周期。这两个项目都使用来自ProjectCore 的相同公共库。 ProjectCore 也将有自己的发布生命周期。在ProjectA 和ProjectB 中，我们要引用ProjectCore 的库。 ProjectCore-libs 在ProjectCore 的成功发布生命周期后被添加到SVN。 ProjectCore-libs 被添加到 References 文件夹中。

通过这样做，我们发布（冻结）我们的 ProjectCore 构建，作为经过全面测试的组件。所以我们有多个 Core-lib 版本：

RLS_Core_1.00
RLS_Core_1.01
RLS_Core_2.00
RLS_Core_3.00

由于我们将发布的库（dll）添加到 SVN，ProjectA 和 ProjectB 可以引用它们。最好的方法是什么？

方法 1

在References 下名为RLS_Core_X_XX 的新文件夹中将ProjectCore-libs 添加到SVN。

在ProjectA和ProjectB的解决方案中，我们添加了对这个唯一文件夹的引用：./trunk/Common/References/RLS_Core_X_XX。

方法 2

将ProjectCore-libs 添加到同一个文件夹References/Core 下的SVN。如果其中有一个“旧”版本，它将是一个提交。

在ProjectA和ProjectB的解决方案中，我们添加了对：./trunk/Common/References/Core的引用。我们使用 SVN 外部属性来定义必须为 ProjectA 和 ProjectB 使用核心库的哪个版本。

在这两种方法中，开发人员明确需要决定他想在他的项目解决方案中使用哪个 Core-libs 版本。规则是保持相同的核心库，除非您因为缺少功能而必须升级。 方法一：在项目解决方案中编辑。 方法 2：在外部属性中进行编辑。

首选哪种方法？

【问题讨论】：

所有项目都存在于同一个解决方案中？还是分开？
这看起来确实像是 DVCS 可能有用的情况。
所有单独的解决方案。

标签： c# .net reference svn-externals

【解决方案1】：

似乎很自然的第一件事是为每个项目单独使用推荐的文件夹结构（branches、tags、trunk）文件夹。这也适用于通用项目，特别是如果您将拥有这两个最终产品引用的版本。由于这些项目将单独开发，您应该能够创建单独的标签和分支。

完成此操作后（并且由于您需要将所有引用作为构建的程序集包含在内），最好将已发布的程序集分别复制到每个项目 Reference 子文件夹中。

这样，无论何时创建分支，您都可以获得所需版本的准确快照，并且独立于常见的东西开发。

换句话说：

/RepoRoot
    + ProjectA
        + branches
        + tags
            + v1.0
            + v1.1
        + trunk
            + references (includes 3rd-party and ProjectCore)
    + ProjectB
        + branches
        + tags
            + v0.8
            + v1.2
        + trunk
            + references
    + ProjectCore
        + branches
        + tags
            + v2.0
            + v2.1
        + trunk
            + references

【讨论】：

我喜欢每个项目都有一个主干/标签/分支的想法。有人可以总结一下这个的利弊吗？这将有助于我说服我的团队成员。我已经找到了这个article
@NickV：我稍后会更新我的答案，我现在不在我的电脑附近。
第二个article实际上是在回答我的问题。
将发布的程序集分别复制到每个项目子文件夹中。 SVN 从技术上讲，我希望为每个项目添加一个。 SVN 服务器是否将这些程序集仅存储在硬盘驱动器上一次或每次添加。
@Nick：如果您执行 SVN 复制命令，那么它与分支相同。服务器知道它是同一个文件 rev。并且只存储一个参考。如果您执行纯文件复制 + svn add，那么您将获得完整副本。例如，使用 tortoise svn，您可以右键拖动文件并在上下文菜单中选择“SVN 复制此处”。

【解决方案2】：

我喜欢方法 1，因为它应该更快更容易在不同版本之间切换

【讨论】：

【解决方案3】：

两种解决方案几乎相同，因此您现在需要考虑部署。假设您在 .NET 程序集上启用了版本控制，则必须在部署应用程序时发布正确的库。

所以，我会明确说明 - 解决方案 1 - 引用其中包含 lib 版本名称的目录，并且不要尝试“重用”相同的引用目录。然后你就会知道要传递哪组dll，你就不会弄错了。（如果您在没有“使用外部”选项的情况下更新项目，则可以这样做，有些人会这样做。在 .NET 中，如果您不小心使用“错误”的 dll 进行了重建，您最终会陷入参考地狱的世界）。

缺点是更新时需要更新项目引用，但如果在项目文件中搜索+替换，这不是什么大问题。

【讨论】：

【解决方案4】：

正如其他人已经说过的那样，这一切都是一样的，只需要很好地记录下来。但我建议不要将 ProjectCore 的版本作为主干文件夹的子文件夹版本。相反，我会为每个版本创建分支，以便您在 ProjectCore 下获得这样的结构：

/RepoRoot
   + ProjectCore
   + trunk
       + ProjectCore
   + branches
       + RLS_Core_1_00
       + RLS_Core_1_01
       + RLS_Core_2_00
   + ProjectA
       + trunk
           + ProjectA
       + branches
           + ProjectA_3_57
           + ProjectA_3_78

如果您在 ProjectA 中使用 ProjectA 下方的外部文件夹链接到 ProjectCore，该文件夹链接到 ProjectCore 的特定分支，或者如果您将 .csproj 文件中的引用路径更改为 ProjectA 文件夹的outside链接的结构（上一层）只是个人喜好问题。

我会根据开发人员对 subversion 外部属性的特性的舒适程度来决定这个答案。如果他们中的大多数人不知道这一点或它是如何工作的，那会使他们感到困惑并导致错误。在这种情况下，通过将路径放入 .csproj 文件来采取直接方法。如果每个开发人员都知道并使用外部组件，请接受这个。

【讨论】：

只是为了清楚；要求是链接核心二进制而不是核心源（ProjectCore）。这不是我的要求——我个人更喜欢源引用。
@NickV：在这种情况下，只需在您的分支/RLS_Core_XXX/ 下方添加 bin/release 文件夹，这样您就有了源代码和二进制文件。在我看来，访问源代码总是很重要的，以防提供修补程序。