dotnet 恢复不等同于 VS 2022（解决方案上下文菜单中的恢复选项）

Question

我有一个包含许多子项目 (104) 的解决方案，我们使用两个 nuget 包源，一个位于 Azure Devops Artifacts 中，另一个位于 nuget.org 中。 我们在第一个中包含旧版本 Orchard Core 的软件包，但开发人员目前上传的这些软件包的版本号为 2.0.0（2019 年）。然后就出现了Orchard Core团队最近添加的问题，制作了2.0.0版本，但与我们的版本不一样。

问题是我们的版本适用于.NetCore 2.2，而 Orchard Core 团队的版本适用于.Net8。

在任何情况下，这都不一定是问题，因为我们在 Nuget.config 中使用 2 个包源以及专门用于 Orchard Core 包的 packagesourcemapping 选项，以确保使用的版本来自我们的源。

使用 Visual studio 2022 恢复 nuget 包工作正常，但问题是我们还使用包含命令行 Dotnet Restore 的 Devops Pipeline。

在我的计算机上，我安装了 SDK 2.2 和 SDK 8。在 powershell 控制台中，命令 dotnet Restore ：

dotnet restore .\Tyndareus\Tyndareus.sln --configfile .\Tyndareus\NuGet.config --force-evaluate

似乎无法处理错误：

error NU1202: Package OrchardCore.ContentManagement 2.0.0 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package OrchardCore.ContentManagement 2.0.0 supports: net80

dotnet Restore 命令不尊重 nuget.config 提到的 packagesourcemapping，因为它从 nuget.org 获取了错误的版本（仅与 .Net8 兼容）：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <clear />
        <add key="nuget" value="https://api.nuget.org/v3/index.json" />
        <add key="extern" value="https://lagardere-tr-fr.pkgs.visualstudio.com/_packaging/extern/nuget/v3/index.json" />
    </packageSources>
  <packageSourceMapping>
    <packageSource key="extern">
      <package pattern="OrchardCore*" />
      <package pattern="TheAdmin*" />
      <package pattern="TheTheme*" />
      <package pattern="TheAgencyTheme*" />
      <package pattern="TheBlogTheme*" />
      <package pattern="TheComingSoonTheme*" />
      <package pattern="SafeMode" />
    </packageSource>
    <packageSource key="nuget">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>  
</configuration>

从 nuget.org 获取软件包，而不是从我们的 DevOps 获取。

它应该在 VS 恢复和 dotnet 恢复之间工作相同。

为什么不尊重包源映射？ .net 2.2 支持 packagesourcemapping 吗？

Answer 1

首先，您需要将构建工具（.NET SDK）与运行时（.NET）分开。我知道命名很混乱，但我没有权力改变它。就是这样。

您可以使用小于或等于您正在使用的 SDK 主要版本的目标框架来构建项目，正如您从本地计算机开发中了解到的那样。因此，.NET 8 SDK 可以构建针对 net8.0、net 7.0、net 6.0 等的项目。因此，仅仅因为您正在构建针对 netcoreapp2.2 的项目并不意味着您需要安装 .NET Core 2.2 SDK。您可以只安装 .NET 8 SDK，但需要安装 .NET Core 2.2 运行时才能运行它（运行时可以与 SDK 分开安装，强烈推荐用于服务器）

接下来，如果您查看NuGet 关于包源映射的文档，它明确指出它从 .NET 6.0.100 SDK 开始可用。所以不，.NET Core 2.2 SDK 不支持它（尽管您编写了 .NET 2.2，并且没有 SDK 部分就意味着运行时，并且 NuGet 不在运行时中提供，仅在 SDK 中提供）。

虽然 Package Source Mapping 是一个可以帮助你的工具，但这也很好地说明了，在 fork 软件时，负责人也应该更改名称，以避免像这样的风险（真正的软件发布相同版本）影响你。 最后，.NET Core 2.2 运行时在 2019 年不再支持。 Microsoft 不会报告不再支持的软件上的 CVE，因此不要让旧版本缺少 CVE 给您带来错误的安全感。谁知道有多少 .NET Core 3.0 或更高版本的 CVE 也适用于 2.2，但没有报道。有很多公司因为没有及时更新软件而遭到黑客攻击的例子。最著名的例子可能是 2017 年的 Equifax。如果您的服务面向互联网，我强烈鼓励您与您的管理链讨论资助更新到受支持的 .NET 版本的工作。事实上，即使您的服务不面向互联网，您仍然应该这样做，因为如果攻击者找到另一种方式进入您公司的网络，那么您的 .NET Core 2.2 服务可能会成为攻击者访问更多内容的枢纽点。网络。