为 NuGet 分发配置类库

Question

我正在研究如何使用 NuGet 在我的组织内分发开发人员框架和工具。我有服务器设置并且能够生成包并将它们添加到使用项目中。我现在希望将其扩展到更真实的情况。

就我而言，我将有一个框架，我们将其分发给组织中的所有开发团队。该框架有一个“核心”类库，然后是一组特定于技术的库，例如 Acme.Web、Acme.Silverlight 等。这些库中的每一个都引用“核心”程序集。

我已将这些程序集中的每一个打包到它自己的 NuGet 包中，其中包括在其他包中设置为依赖项的“核心”。这是因为开发人员在创建类库时可能选择只引用“核心”，但在创建 Web 应用程序时也需要这些类型等。

另一个想法是我可以发布我的“核心”程序集的新版本，而无需更新所有其他包。或者我可以吗？

想象一下我有项目 A 的情况，添加依赖于 NuGet 包 C 的 NuGet 包 B，然后更新包 C。是否可以在不重新构建、重新打包和重新发布包 B 的情况下分发此更新？如果是这样，我需要采取什么步骤来确保没有版本控制问题？

Answer 1

鉴于以下依赖关系图，听起来您要问的问题是：

-> 表示依赖于

B 1.0 -> C 1.0

如果碰巧有对 C 的更新，比如说 C 1.1，您想知道是否可以将该更新发布到 C 并让消费者在不破坏 B 的情况下对其进行更新。

我假设您正在这里打包组件。如果是这种情况，那么您绝对可以这样做。 NuGet 做了一些事情来帮助对具有强名称的程序集进行这项工作（即，它添加了必要的绑定重定向）。您只需要确保使用正确的版本控制（我强烈建议您阅读 David Ebbo 的 posts 关于该主题的内容）。

让您对它的工作原理有一个基本的了解。假设您在一个由 3 人组成的团队中，您、开发人员 1 和 2。

1. 您将包 B 1.0 和 C 1.0 发布到您公司的供稿中
2. 开发者 1 安装 B 1.0 并获得 C 1.0
3. 您对 C 进行了一个小错误修复并将其命名为 C 1.0.1（因为它没有破坏）。您没有更新 B（这意味着它表示它依赖于 C 1.0 而不是 C 1.0.1）。
4. 开发者 1 将 C 更新到 1.0.1 并继续工作
5. Developer 2 安装 B 1.0 并获得 C 1.0.1（NuGet 的依赖解析行为）。

在上述场景中，您将版本从 C 1.0 更改为 C 1.0.1，并且不必重新发布 B。

现在，如果您进行了巨大的突破性更改并将版本提升到 C 2.0，那么也许您想考虑重新打包 B 并增加版本号并使该版本的 B 依赖于 C 2.0：

B 2.0 -> C 2.0