1

我有一个在 TFS 中构建多个库解决方案的环境。在构建过程结束时，脚本将它们打包到 NuGet 包中，并将它们推送到我们的本地提要。

现在我们可以将这些每天变化不大的库包含在我们的上游项目中。

这些库以及我们的上游项目通常以相同的版本分支。基本上，主干是我们不断发展的最新版本。在分支主干之前说是 3.0.0.123，123 是正在运行的内部版本号。在某些时候，我们将当前主干标记为我们将要发布的内容并对其进行分支。分支时主干的版本号成为该分支的版本，我们将以任何适当的方式将主干的版本增加到我们认为可能会成为下一个版本的版本（比如 3.1.0.456） .

这让我们想如何使用 NuGet 有点奇怪。我们希望分支 3.0.0.456 使用分支中的最新库（可能是 3.0.0.457），而主干使用主干中的最新库（3.1.0.789）

所以这基本上归结为我们可以使用 NuGet 设置解决方案的版本，使其类似于 NuGet 在包中定义依赖项时使用的方式吗？

理想情况下，我想告诉分支的上游应用程序使用 [3.0.0.456, 3.1) 和主干使用最新的（无版本）。在这种情况下，它将拾取分支将拾取下一个分支构建 (3.0.0.457)，而主干将拾取发布到提要的最后一个 NuGet 包。

作为可能的解决方案，我提出的唯一想法是使用构建模板的参数，并在运行 NuGet 目标之前使用它来更新 package.config 文件。

如果这应该在超级用户或其他地方继续，我表示歉意......

4

1 回答 1

1

在进行了一些挖掘以让我的构建为我们的库项目自动创建包之后，我得出了一个（错误的）结论，即这是 NuGet 的一个限制。我解析了他们的任何 XSD 文档的源代码来描述他们的 XML，这样我就可以看到他们的 nuspec 是如何工作的。

虽然我有他们的源代码，但我开始研究如何修改 package.config 文件以接受他们的架构以限制版本。经过一番挖掘，我发现了一个可以添加到 package.config 中的包节点的属性：allowedVersions。这正是我想要添加的内容！

一旦我有了这条信息，我就能够更深入地挖掘它是如何实现的。事实证明，这个功能已经存在了一段时间，甚至记录在他们的文档网站上： http: //docs.nuget.org/docs/reference/versioning

它位于底部的依赖版本控制指南中。我一定完全忽略了它，或者从未读过那么远！

事实证明，这不是问题，唯一的问题是我的无知。只是对任何登陆此页面的 Google 员工的参考！

来源（位于页面底部）：NuGet 版本控制

于 2013-02-05T19:21:22.770 回答