.NET 附带许多核心库,可处理从文件管理到 HTTP 再到压缩文件各种任务。 此外还有一个巨大的第三方库生态系统。 可以使用 NuGet(.NET 包管理器)安装这些库并在应用程序中使用它们。
.NET 及其生态系统经常使用“依赖项”一词。 包依赖项是第三方库。 它是一段用于完成某些操作的可重用代码,可以添加到你的应用程序。 应用程序依赖第三方库才能正常运行,因此称之为“依赖项”。
可将第三方库视为包,并将其存储在存储库中。 包由一个或多个库组成,可将这些库添加到应用程序中,以便利用其功能。
我们将重点介绍包依赖项。 .NET 项目可具有其他类型的依赖项,包括框架、分析器、项目引用以及包依赖项随附的共享项目依赖项。
确定是否需要包
如何知道你的项目是否需要包? 这是一个复杂的问题,涉及几个因素:
- 获取更好的代码。 问自己是否正在处理安全性等任务,以及是否正在尝试实现身份验证和授权。 保护你的数据和客户数据是一个需要立即执行的任务。 业内有标准模式和许多开发人员使用的库。 这些库实现了你可能始终需要的功能,而问题会在出现时进行修补。 应使用此类库,而不是创建自己的库。 你自己编写的代码可能无法达到这么好的效果,因为有太多极端情况需要考虑。
- 节省时间。 你可能可以自行生成大多数内容(如实用工具或 UI 组件库)。 但需要花费一些时间。 即使结果与已提供的包相当,但如非必要,重复编写代码其实是在浪费时间。
- 维护。 所有库和应用迟早都需要维护。 维护包括添加新功能和更正 bug。 维护库是在很好地利用你或你的团队的时间吗? 还是让开源软件团队来处理它更好?
评估包
安装库之前,可能需要检查它依赖的依赖项。 这些依赖项可能会鼓励你使用包,也可能会阻止你。 下面是在为项目选择依赖项时需要考虑的一些因素:
- 大小。 依赖项的数量可能会造成很大的占用量。 如果带宽有限或有其他硬件限制,则可能需要考虑这一因素。
- 许可。 你需要确保为库授予的许可涵盖了你的预期用途,无论是商业、个人还是学术用途。
- 主动维护。 如果你的包依赖于已弃用或长时间未更新的依赖项,这可能是个问题。
可在安装前转到 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
--------| <files included in the dependency>
查找包
个别开发人员可以使用 NuGet.org 中的全局注册表查找并下载其应用所需的包。 公司可能已实施了一个策略,指明哪些包可以使用,以及在哪里可以找到它们。
包可能位于多个不同的位置。 其中有些源可能已公开发布,而有些可能受到限制,仅供特定公司的员工使用。 以下是包可能存在的位置:
- 注册表。 例如,可能是一个类似 NuGet.org 注册表的全局注册表。 可托管自己的专用或公共注册表。 GitHub 和 Azure DevOps 等服务使专用注册表可用。
- 文件。 可从本地文件夹安装包。 如果要尝试开发自己的 .NET 库,并想要在本地测试包,或者出于某种原因不想使用注册表,则从包进行安装很常见。
NuGet 注册表和 dotnet 工具
运行 dotnet add package <name of dependency>
时,.NET 会转到称为 NuGet.org 注册表的全局注册表,并查找要下载的代码。 它位于 https://nuget.org
。 如果使用浏览器访问此页面,也可以在此页面中浏览包。 每个包都有可以访问的专用网站。
在这些站点上,你可以详细了解源代码所在的位置。 还可以查看下载的相关信息(如指标)以及维护的相关信息。
.NET 命令
到目前为止,你已了解如何使用 .NET Core CLI 安装依赖项。 但它还可以执行更多操作。
.NET Core CLI 包含很多命令。 这些命令可帮助你完成安装包、创作包和初始化 .NET 项目等任务。 无需详细了解所有命令。 从 .NET 开始时,可能只会使用一部分命令。 当你扩展 .NET 的使用范围时,可能会使用各种类别中越来越多的命令。
为了帮助你记住命令的作用,可以将它们视为属于以下类别:
- 管理依赖项。 此类别中的命令涵盖安装、删除、安装包后进行清理以及包更新。
- 运行程序。 .NET Core 工具可帮助你管理应用程序开发中的流。 应用程序流的示例包括运行测试、生成代码以及运行迁移命令来升级项目。
- 创建和发布包。 有多个命令可以帮助你完成创建压缩包和将包推送到注册表等任务。
如果需要所有命令的详细列表,请在终端中输入 dotnet --help
。
如何安装包
使用 dotnet add package <dependency name>
命令,可安装要作为应用程序的一部分使用的常规依赖项。
备注
可以以全局方式安装某些包。 这些包不会导入到项目中。 因此,许多全局包都是 CLI 工具或模板。 还可从包存储库安装这些全局工具。 使用
dotnet tool install <name of package>
命令安装工具。 使用dotnet new -i <name of package>
命令安装模板。
安装后
安装的包在 .csproj 文件的 dependencies
部分中列出。 如果需要查看文件夹中的包,可以输入 dotnet list package
。
Project 'DotNetDependencies' has the following package references
[net5.0]:
Top-level Package Requested Resolved
> Humanizer 2.7.9 2.7.9
该命令只列出顶层包,而不列出那些包的依赖项(我们称之为可传递包)。 这样有利于快速查看。 如果需要更详细的视图,可以列出所有可传递包。 执行此操作时,list
命令如下所示:
dotnet list package --include-transitive
包含可传递项时,你将可以看到依赖项以及已安装的所有包。 如果运行 dotnet list package --include-transitive
,可能会看到以下输出:
Project 'DotNetDependencies' has the following package references
[net5.0]:
Top-level Package Requested Resolved
> Humanizer 2.7.9 2.7.9
Transitive Package Resolved
> Humanizer.Core 2.7.9
> Humanizer.Core.af 2.7.9
> Humanizer.Core.ar 2.7.9
> Humanizer.Core.bg 2.7.9
> Humanizer.Core.bn-BD 2.7.9
> Humanizer.Core.cs 2.7.9
...
还原依赖项
当你创建或克隆项目时,在生成项目之前,不会下载或安装包含的依赖项。 可运行 dotnet restore
命令,手动还原依赖项以及项目文件中指定的特定于项目的工具。 多数情况下,不需要显式使用此命令。 如果需要,在运行 new
、build
和 run
之类的命令时,将隐式运行 NuGet 还原。
清理依赖项
你很可能迟早会意识到不再需要某个包。 或者,你可能意识到安装的包不是你需要的。 也许你已经找到了一个可更好地完成任务的包。 无论出于什么原因,都应删除不使用的依赖项。 这样可保持整洁。 此外,依赖项还会占用空间。
若要删除项目中的某个包,请使用如下所示的 remove
命令:dotnet remove package <name of dependency>
。 此命令将从项目的 .csproj 文件中删除该包。