如何在应用程序之间管理共享库？

Question

我们开发企业软件，我们希望在我们的开发人员之间促进更多的代码重用（为了保持这个问题的简单，让我们假设所有的.NET）。我们即将迁移到一个新的VCS系统（很可能是多变的），我想制定一个策略来共享库。

管理满足以下用例的共享库的最佳流程是什么：

1. 黑匣子 - 只知道图书馆的公共API，并且没有假设消费开发人员能够“进入”或将断点设置到库中。图书馆是一个黑匣子。通常开发人员不关心细节，只需给我一直“工作”的lib版本。
2. 调试 - 开发人员应该能够在开发期间至少“进入”库。设置断点也是一种奖励。
3. 并行开发 - 虽然很可能是少数，但有一些看似有效的用例，用于与消费应用程序并行开发库。通常，库和组件的作者是同一个开发人员。无论好坏，应用程序和库通常可以紧密耦合。能够对两者进行更改和调试对我们来说是一种非常有效的方式。

应该注意解决3，可以隐含地解决2。

解决方案可能涉及其他工具（如NuGet等）。

Answer 1

通过共享库，您必须区分：

• 源依赖项（您正在共享源，暗示项目中的重新编译）
• 二进制依赖项（您共享交付，从常见来源编译）并从您的项目链接到它。

对于两者，NuGet（2.0）最终引入了“构建期间的包恢复”，以便不提交源代码控制Lib或ExternalDependencies中构建的内容文件夹中。

NuGet（特别是它的new hierarchical config，NuGet 2.1）非常适合C＃项目中的模块管理，并且将与git和Mercurial接口。

将它与Mercurial subrepos结合使用，您应该能够在自己的仓库中隔离要重用的公共代码库。

Answer 2

我有两个可能的解决方案来解决这个问题，这两个问题看起来都不理想（因此我发布了这个问题）。

1. 使用VCS管理依赖项。具体来说，使用mercurial subrepos并始终按来源共享。
   • 优点：
     1. 解决了所有3个用例。
     2. 源控制和依赖关系管理只需要一个工具
   • 缺点：
     1. 子目录功能被Mercurial开发人员和实验视为feature of last resort，reading存在以下问题：
        • 标签不能轻易或原子地应用于多个回购。
        • Root / Shell repos本质上是脆弱的（如果子场的路径发生变化，可能会被破坏）。 Mercurial开发人员建议通过在shell repo中不包含任何内容来缓解此问题，并仅使用它来定义子流程的（并跟踪修订版本）。因此，即使子路径路径被破坏，也允许开发人员手动重建一个时刻。
        • 分支不能跨越回购边界（很可能不是一个大问题，因为有人可能会认为分支只应出现在给定的子代数中）。
2. 使用Ivy或NuGet来管理依赖项。这有两种方法可行。
   1. 依赖关系/包可以只包含官方二进制文件。构建服务器可以配置为在开发人员提交新版本的构建时将新的依赖项/包发布到公司存储库中。这解决了案例1.Nuget似乎支持symbol packages 可以解决案例2.案例3没有解决，让开发人员在这种情况下干涸并提出自己的解决方案（那里基本上没办法将应用程序提交到包含源的依赖项的VCS。这似乎是使用依赖关系管理工具的传统方式。
   2. 依赖关系/包可以包含从mercurial获取源的脚本。安装依赖项/包时，可以自动执行该脚本。为了让.NET解决方案包含项目引用（而不是浏览文件系统），需要执行一些魔术，但理论上这可能发生在NuGet install script and reversed in the uninstall script中。
      • 在“源”和“二进制”依赖关系之间切换似乎是一个手动步骤。我认为开发人员应该转换为版本的二进制依赖项，也许这可以在创建发布时在构建服务器上强制执行。由于需要修改VS解决方案以引用项目与二进制文件这一事实使这更加复杂。
      • 存在多少源包？每个二进制包是否包含用于获取其构建的源的脚本？或者我们是否创建了使用安装脚本魔法来获取源的独立源包？这导致问题是mercurial中的每个标签都有一个源包吗？每一个变化集？或者只是一个源代码包，只是克隆和更新提示，并让开发人员更新到以前的版本（但这会产生知道要更新的修订版本的问题）。
      • 如果dev然后使用mercurial来更改源的修订版，那么如何在消费应用程序中反映出来？用于获取源的依赖项/包没有更改，但源本身具有...