首页 > 解决方案 > 使用浮动版本分发 NuGet 包的正确方法

问题描述

我正在创建一个依赖于 Xamarin.Forms 的 NuGet 包。该软件包应该可以与任何最新版本的 Forms 一起正常工作,因此我将其设置为:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <PackageId>MyCompany.FormsExtras</PackageId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Xamarin.Forms" Version="4.*" />
  </ItemGroup>
</Project>

在本地构建和发布以测试...

$ dotnet pack -c Release -p:Version=0.9.0
$ nuget add bin/Release/MyCompany.FormsExtras.0.9.0.nupkg -source ~/Dropbox/Packages/

在我运行这些命令时,Xamarin.Forms 4.1.0.555618 是最新版本。

我现在正试图将此包拉入现有项目中,该项目直接依赖于不同的旧版本 Xamarin.Forms:

  <ItemGroup>
    <PackageReference Include="Xamarin.Forms" Version="4.0.0.425677" />
  </ItemGroup>

...但它无法添加带有此错误的包:

Detected package downgrade: Xamarin.Forms from 4.1.0.555618 to 4.0.0.425677. Reference the package directly from the project to select a different version. 
 MyCompany.ToDo.Forms -> MyCompany.FormsExtras 0.9.0 -> Xamarin.Forms (>= 4.1.0.555618) 
 MyCompany.ToDo.Forms -> Xamarin.Forms (>= 4.0.0.425677)

我的印象是我的包中指定的浮动版本PackageReference应该允许它工作?我错过了一步,还是我误解了浮动版本的工作原理?

我已经阅读了关于包依赖解析的 MS 文章。我还尝试搜索错误消息和“浮动版本”,但我只是在消费者方面找到解决方法;我想在我的包装上解决这个问题,这样消费者就不必费劲了。

任何帮助都非常感谢......</p>

标签: xamarin.formsnugetnuget-package

解决方案


TL;DR 版本:将您的 PackageReference 更改为 use Version=4.0.0,或与最低版本的项目使用的相同版本,而不是Version=4.*.

项目和包之间存在误解。一个项目可以用来创建一个包,但是它们有不同的特性。特别是,浮动版本只是 的一个特性PackageReference,这是项目定义其包依赖项的方式。文档说

使用 PackageReference 格式时,NuGet 还支持使用通配符表示法 *,表示主要、次要、补丁和数字的预发布后缀部分。packages.config 格式不支持通配符。

没有明确说明 nuspec 也不支持通配符(一个包包含一个 nuspec,而不是PackageReferences),但它不受支持,因此为什么您的包具有>= 4.1.0.555618. 然后正如马特在评论中指出的那样,由于最近的获胜规则,您会收到降级警告(并且 NuGet 将降级视为警告,但 .NET Core SDK 将其提升为错误。我不知道 Xamarin 是否是否也一样)。如果您希望您的包支持>= 4.0.0,那么您需要将MyCompany.FormsExtras项目的PackageReferencefor更改为Xamarin.Forms版本4.0.0(尽管您应该使用可用的最低版本的确切版本,否则每个使用您的包的项目在找不到时都会受到性能影响与您的包的依赖项完全匹配),而不是4.*.

我是在实现通配符之后很久才加入NuGet团队的,我没有努力去寻找设计规范,所以我完全是在猜测,但我相信打包一个使用的项目4.*不会导致包的原因支持>= 4.0.0是因为 NuGet 正在尽最大努力猜测支持哪些包版本,以最大程度地减少使用该包的开发人员的运行时故障。

为了理解,考虑最极端的情况,使用通配符*. 除非 NuGet 会以某种方式使用您的依赖项的每个版本来测试您的项目,以检查它实际上与哪些版本的包兼容(这样做完全不可行,即使这样做会使打包非常慢),最简单的两个选项要么使用>= 0.0.0在精神上等同于*,要么使用上次恢复项目时解决的依赖项的版本。

使用>= 0.0.0是一个问题,因为如果包的第一个版本与当前版本相比可能有重大更改,或者您的项目可能使用了早期版本中不可用的 API。因此,尽管您的项目使用*,但它实际上并不与该依赖项的所有版本兼容,因此>= 0.0.0可能无法正常工作。您的项目使用的包越旧或版本越多,该包的最旧版本与您的项目一起使用的可能性就越小。

同样,语义版本控制指定次要版本表示非破坏性更改,但确实包含新的 API。您的项目被打包到使用4.1.x您的依赖项的包中,并且 NuGet 无法知道 1) 包是否严格符合语义版本控制(我的猜测是非常非常少)和 2) 如果您的项目使用 API仅适用于4.1.x而不适用4.0.x。鉴于并非所有包都严格符合语义版本控制,即使更改4.1.*4.1.0.

希望我已经说服您,NuGet 在将项目打包到包中时如何处理通配符的行为是最好的方法。它旨在最大限度地提高“开箱即用”的软件包的百分比。如果不是,您现在应该了解它是如何工作的,即使您不同意它是最好的实现。


推荐阅读