.net-core - 在.net核心中添加引用的正确方法是什么——程序集还是nuget？

Question

问题：我在 .net core 2.1 库中引用 IConfiguration 接口，该库将在 linux docker 容器中运行

Visual Studio 2019 自动提供为我添加程序集引用。如果我接受，它会引用我的程序文件目录中的 Microsoft.Extensions.Configuration.Abstractions.dll。

但是，我看到这个 dll 在线也有一个 nuget 打包程序。

说“只信任 Visual Studio”很容易，但我之前遇到过 .net 框架的问题，当 VS（或 resharper）想要引用的程序集确实是包的一部分时，VS（或 resharper）会尝试添加程序集引用需要添加。

我是 .net 的老手，刚刚开始使用 .net 核心。在这种情况下，正确的约定是什么？

标签： .net-core

Answer 1

.NET Core 设计时使用包引用作为引用依赖项的标准方式。这种设计选择有几个原因，然而，主要原因是允许在多个操作系统和架构目标上运行代码。因此，推荐的创建依赖项的方法是使用包引用。它将允许获取与给定操作系统和 CPU 组合相关的包。

例如，您可以针对构建 Windows、Linux 和 macOS 以及针对 Linux 和 Windows x64 和 arm64 架构，而针对 macOS x64 架构。项目引用包将为给定的操作系统和处理器架构组合选择合适的包，即在 SQLite 的情况下，它将是 win-x64、win-arm64、linux-x64、linux-arm64、macOS-x64 包版本。.NET Core 包和运行时也是如此，它们将根据目标平台和目标体系结构的组合进行选择。处理所有这些组合的一般概念由 Target Framework Moniker 抽象出来，除了处理操作系统和架构信息之外，它还允许处理版本依赖信息。

以上所有内容是理解 .NET Core 中的版本控制和操作系统/架构依赖处理的基本概念，它也在其项目系统中实现。在您的情况下，您应该始终选择 nuget 包而不是程序集引用，尽管 Visual Studio 提出的建议通常并不总是正常工作。要验证这一点，可以检查 Visual Studio 使用的 .NET Core 项目系统所在的 github 上的 dottent/project-system 存储库中已关闭或仍处于打开状态的问题的数量。

最后，尽管引用纯 IL 程序集会起作用，但它不是未来的证明，因为任何使其平台或架构特定的依赖项变化（即使用 .NET Core HW 内在的架构特定优化）都会破坏您的项目。