创建新的 .NET 项目并使用依赖项

评估包

安装库之前，可能需要检查它依赖的依赖项。 这些依赖项可能会鼓励你使用包，也可能会阻止你。 下面是在为项目选择依赖项时需要考虑的一些因素：

  • 大小。 依赖项的数量可能会造成很大的占用量。 如果带宽有限或有其他硬件限制，则可能需要考虑这一因素。
  • 许可。 你需要确保为库授予的许可涵盖了你的预期用途，无论是商业、个人还是学术用途。
  • 主动维护。 如果你的包依赖于已弃用或长时间未更新的依赖项，这可能是个问题。

可在安装前转到 https://www.nuget.org/packages/<package name>，详细了解包。 通过此 URL 可转到该包的详情页。 选择“依赖项”下拉列表，查看这些包依赖哪些包来运行。
列出的依赖项的数量可能并不能说明全部事实。 如果下载一个包，你可能会得到一个包含数十个包的程序包依赖关系。 为什么会这样？ 每个包都有一系列依赖项。 为了确保可以使用包，运行 dotnet add package <package name>命令时将抓取和下载所有依赖项。

安装包

可通过多种方法来安装包。 Visual Studio 和 Visual Studio for Mac 中有一个内置的包管理器命令行和图形用户界面。 可手动向项目文件添加包引用。 也可通过命令行接口 (CLI) 工具（如 Paket 或 .NET Core CLI）进行安装。
对于此模块，我们将使用内置的 .NET Core CLI 安装包。 可通过在终端中调用命令，将包添加到 .NET 项目。 典型的安装命令如下所示：dotnet add package <name of package>。 在运行 add package 命令时，命令行工具连接到全局注册表并提取包，将其存储在所有项目皆可使用的缓存的文件夹位置。
安装和生成项目后，引用将添加到调试或发布文件夹中。 你的项目目录将如下所示：
-| bin/
—-| Debug/
———| net3.1
————|

查找包

个别开发人员可以使用 NuGet.org 中的全局注册表查找并下载其应用所需的包。 公司可能已实施了一个策略，指明哪些包可以使用，以及在哪里可以找到它们。

使用语义化版本控制

有一种称为“语义化版本控制”的行业标准。 语义化版本控制是指如何表达你或其他开发人员向库引入的更改类型。 语义化版本控制的工作原理是确保包具有版本号，并且该版本号划分为以下部分：

  • 主版本。 最左边的数字。 例如 1.0.0 中的 1。 此数字发生更改意味着代码可能出现中断性变更。 可能需要重写部分代码。
  • 次要版本。 中间的数字。 例如 1.2.0 中的 2。 此数字发生更改意味着添加了新功能。 你的代码仍可正常工作。 接受更新通常是安全的。

  • 修补程序版本。 最右边的数字。 例如 1.2.3 中的 3。 此数字发生更改意味着应用了一个更改，修复了代码中应正常工作的内容。 接受更新应是安全的。

    更新方法

    作为 .NET 开发人员，你可以向 .NET 传达所需的更新行为。 从风险角度考虑更新。 以下是一些方法：

  • 主版本。 我很乐意在最新主版本发布后立即更新到最新主版本。我接受可能需要更改我的代码这一事实。

  • 次要版本。 我可以接受添加新功能。 我不能接受代码中断。
  • 修补程序版本。 我唯一能接受的更新是 bug 修复。

下面是可为主要版本、次要版本或修补程序版本配置的一些示例：

  1. <!-- Accepts any version 6.1 and later. -->
  2. <PackageReference Include="ExamplePackage" Version="6.1" />
  4. <!-- Accepts any 6.x.y version. -->
  5. <PackageReference Include="ExamplePackage" Version="6.*" />
  6. <PackageReference Include="ExamplePackage" Version="[6,7)" />
  8. <!-- Accepts any later version, but not including 4.1.3. Could be
  9.      used to guarantee a dependency with a specific bug fix. -->
  10. <PackageReference Include="ExamplePackage" Version="(4.1.3,)" />
  12. <!-- Accepts any version earlier than 5.x, which might be used to prevent pulling in a later
  13.      version of a dependency that changed its interface. However, we don't recommend this form because determining the earliest version can be difficult. -->
  14. <PackageReference Include="ExamplePackage" Version="(,5.0)" />
  16. <!-- Accepts any 1.x or 2.x version, but not 0.x or 3.x and later. -->
  17. <PackageReference Include="ExamplePackage" Version="[1,3)" />
  19. <!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and later. -->
  20. <PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />

查找和更新过时的包

dotnet list package --outdated 命令列出了已过时的包。 此命令可帮助你了解何时有更新版本的包可用。 以下是命令的典型输出：
输出

  1. Top-level Package      Requested   Resolved   Latest
  2. > Humanizer            2.7.*       2.7.9      2.8.26

以下是输出中列名称的含义：

  • Requested. 已指定的版本或版本范围。
  • Resolved. 已为项目下载的、与指定版本匹配的实际版本。
  • Latest. 可从 NuGet 更新的最新版本。

建议的工作流是按以下顺序运行这些命令：

  1. 运行 dotnet list package --outdated。 此命令可列出所有已过时的包。 它通过 Requested、Resolved 和 Latest 列提供信息。
  2. 运行 dotnet add package <package name>。 如果运行此命令，它将尝试更新到最新版本。 你可选择传入 —version=。