咨询dotnet CLI所用NuGet版本及NuGet特性纳入时机（含预发布浮版本）

我来帮你梳理下这两个问题的答案，结合NuGet和.NET SDK的绑定逻辑来解释：

具体问题：dotnet restore何时支持*-*格式包引用？ #

首先要明确：dotnet restore并不直接使用独立的nuget.exe版本，它依赖的是当前.NET SDK内置的NuGet工具链。

当NuGet 5.6正式发布后，你并不能立刻通过dotnet restore使用*-*特性——得等对应的.NET SDK版本更新，把NuGet 5.6整合进去才行。因为.NET SDK和NuGet版本是强绑定的，比如之前NuGet 5.x对应Visual Studio 16.x的规律，同样适用于.NET SDK：每个SDK版本都固定搭载某个NuGet版本。

举个例子，如果是.NET Core 3.1的后续小版本更新，或者.NET 5的某个预览/正式版本，会把NuGet 5.6内置进去，这时运行dotnet restore就能支持*-*格式，拉取最新的正式版或预发布包了。你可以通过dotnet nuget --version命令查看当前SDK对应的NuGet版本，确认是否已经升级到5.6。

另外你提到dotnet restore是dotnet msbuild /t:Restore的封装，这点没错，而MSBuild的Restore任务同样依赖SDK内置的NuGet工具链，所以本质上还是看SDK的NuGet版本是否达标。

宽泛问题：dotnet CLI与NuGet版本的关系及特性纳入流程 #

这里分三点给你解释清楚：

• dotnet CLI的NuGet版本绑定：dotnet CLI本身没有独立的NuGet版本，它的NuGet功能完全依赖.NET SDK内置的工具链。每个.NET SDK版本都对应固定的NuGet版本，比如.NET 6 SDK v6.0.100内置NuGet 6.0，.NET 7 SDK v7.0.100内置NuGet 7.0。你随时可以用dotnet nuget --version命令查询当前环境的NuGet版本。
• 特性纳入的节奏：NuGet的新特性会先在独立nuget.exe中发布验证，之后会被整合到.NET SDK的内置工具链里。这个过程没有固定的时间点，通常和.NET SDK的更新周期同步（比如月度补丁更新或者大版本发布）。官方会在.NET SDK的发布说明里明确标注内置NuGet版本的升级，以及新增的特性支持情况。
• 功能完整性：一般来说，.NET SDK内置的NuGet工具链会包含独立nuget.exe的全部核心特性，不会做功能裁剪，只是更新节奏会比独立CLI稍慢一些——毕竟SDK的更新需要兼顾整个.NET生态的稳定性。

内容的提问来源于stack exchange，提问作者dzebdf