更新相同版本号的Nuget包答案

【问题标题】：Updating Nuget Package of the Same Version Number更新相同版本号的Nuget包
【发布时间】：2019-12-21 19:07:18
【问题描述】：

我正在开发一个 .net 标准 C# 类库，它会在我构建它时自动输出一个 NuGet 包。我将这个 NuGet 包与 ASP.NET Core 应用程序一起使用。如果我每次构建类库时都更新它的版本号，我可以使用简单的 Update-Package 命令将更改拉入我的应用程序，但我不想每次都更改版本号，当我正在做很多小改动。

我尝试在 Visual Studio 选项菜单中清除 NuGet 缓存，然后尝试使用“dotnet restore”和卸载/重新安装，但不知何故，它似乎仍然不断地从某个地方拉入旧版本。

还有其他方法吗？它会从哪里提取旧版本？

【问题讨论】：

标签： .net asp.net-core nuget nuget-package .net-standard

【解决方案1】：

这根本不是 NuGet 的工作方式。版本号是幂等的，所以你不能“替换”一个版本；你只能增加它。这是 NuGet 遵循的SemVer（语义版本控制）规则。规则规定：

一旦发布了版本化包，就不得修改该版本的内容。任何修改都必须作为新版本发布。 (https://semver.org/#spec-item-3)

不过，有两件事可以帮助您。

NuGet 使用 SemVer，因此您也应该这样做。在开发中，您不会增加主要、次要或补丁号 ([major].[minor].[patch])。相反，您添加一个破折号，后跟一个预发布标识符，即1.0.0-alpha.1。然后，这允许您在不影响发布号的情况下增加标识符。例如，您的下一个更改可能是1.0.0-alpha.2，当您最终准备好发布时，您只能使用1.0.0。
在开发过程中，不应将 NuGet 与应用代码一起修改。如果它们在同一个解决方案中，则不需要包引用，因为项目引用更有意义，因此不需要版本增量。如果库与您的应用程序位于不同的解决方案中，您应该只通过包引用包含，然后，您应该独立开发这两者。如果这更有意义，您也可以稍后将项目分开。如果您的库的开发不足以支持您的应用程序而无需不断更改，那么请将其保留在相同的解决方案中。一旦它达到一个稳定的点，您就可以将它移到它自己的解决方案中（如果您愿意的话），并在此时更改您应用中的引用。

【讨论】：

感谢您的建议，非常有帮助。它在一个单独的解决方案中，因为有另一个开发人员将它用于不同的应用程序。我们都在对类库进行更改，并且都对 2 个消费应用程序进行更改。我想我们将不得不利用您对预发布标识符的建议。我不介意每次签入更改以供其他开发人员使用时都更改它，在我编写代码时这样做似乎很愚蠢。如果它们都在同一个解决方案中会容易得多，但其他开发人员将无法使用它/贡献。
这更多是团队组织的问题。两个开发人员不应该同时接触相同的代码。至少在特定 PBI 或用户故事的上下文中，有人需要拥有该库的所有权。
另外，如果它是一个外部化的依赖，那么必要的更改需要从与正在开发的应用程序相关的 PBI 中分离出来。换句话说，如果您正在使用您的应用程序，并且您注意到需要在库中进行更改。然后为该更改创建一个完全不同的 PBI。此时，负责该库的团队或开发人员可以拿起它并实施更改。在某些情况下，这可能是同一个开发人员，但这种类型的组织使变更队列保持独立和结构化。
您还可以将共享项目临时添加到您的解决方案中，将包引用更改为项目引用，然后在开发完成并准备好发布 nuget 包后撤消这些临时更改。

【解决方案2】：

您可以将此版本应用于您的预发布包，以获得每个构建的包：

<Version>1.0.0-$(Configuration)-$(Platform)-$([System.DateTime]::UtcNow.ToString(yyyyMMdd-HHmmss))</Version>

然后当你发布你的包时，你用 :

改变版本

<Version>1.0.0</Version>

你总是需要升级包，但它的版本没有增加

【讨论】：

【解决方案3】：

在 Nuget 世界中，没有直观的方法。

我通常采用的方式是将项目包含在解决方案中并进行处理。一旦我感到高兴，我就会构建 nuget 包。

【讨论】：