从基于日期的版本控制切换到语义版本控制后，如何防止 NuGet 升级包？

Posted 2023-03-07

【中文标题】从基于日期的版本控制切换到语义版本控制后，如何防止 NuGet 升级包？

【英文标题】：How do I prevent NuGet from upgrading a package after switching to semantic versioning from date-based versioning?

【发布时间】：2013-09-02 06:37:01

【问题描述】：

我们最近开始使用我们自己的内部 NuGet 服务器来存放我们许多内部项目常用的包。最初，我们处理的每个项目都使用以下格式的构建日期进行版本控制：

[Year].[Month].[Day].[DailyBuildCount]

但是，在我们升级到 .NET 4 的过程中，我们决定从 v4.x 开始使用 SemVer 对我们的包进行版本控制。问题是 NuGet 将 v4.x 版本视为比使用日期格式版本的版本更旧。此外，引用 v4.x 版本的项目认为他们需要升级到日期格式的版本，这甚至不是针对相同的框架版本。

是否有某种方法可以配置 NuGet，使包升级不能跨越这些版本控制线？

对于包间依赖，我们为它们配置了特定的版本依赖，这样依赖本身就可以正常工作。主要项目参考是旧版本可能意外发生“升级”的问题。

【参考方案1】：

我有一系列三篇博文可以帮助您：

Performing a safe update using NuGet and Powershell Performing a safe update using NuGet and Powershell with pre-release packages Coercing the jQuery NuGet package version and downgrading jQuery

最后一个链接显示了一个示例（在本例中为 jQuery，但可以应用于任何包），说明如何将版本强制为特定范围。这将确保当您发出 Update-Package 命令时，仅使用版本介于次要值和主要值之间的引用更新项目。

但是，在您的情况下，最好的解决方案可能是像 Eric Lloyd 之前建议的那样，完全打破您的依赖链，以保持干净的依赖结构。

【参考方案2】：

顺便说一句，我认为最好的办法是稍微重命名软件包。这将导致它们被视为完全独立的包并完全破坏版本链。

【讨论】：

我之前有这个想法，现在不知道我为什么不理会它。鉴于 Microsoft 的命名空间 naming rules (<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>])，您对在包名称中添加什么以区分它有什么建议吗？

根据 NuGet 的 Package Conventions Page，包名称是一个可选约定，因此您可以随意装饰它，只要您针对 .nuspec 文件打包即可。假设它是公司内部的软件包，您可以删除 <Company>. 部分并完成它。

这确实是唯一的选择。 -safe 参数有助于 Update-Package 命令避免自动升级太远，但要真正避免任何问题，最好选择一个新的包 ID。