NuGet 恢复失败 - .NET 7.0 与 .NET 标准 2.0 的兼容性

Question

I have a solution with a .NET 7.0 ASP.NET project which has a project reference on a .NET Standard 2.0 library in the same solution. All builds and executes fine on my machine.

I have a Pipeline in Azure DevOps that builds the projects and aims to deploy the ASP.NET project to a server. Before building, it runs the task NuGetCommand@2 to execute a NuGet Restore against **/*.sln . This is being run on the windows-2022 Azure VM Image.

The restore bombs because of errors like these:

Package Microsoft.OpenApi 1.4.3 is not compatible with net70 (.NETFramework,Version=v7.0). Package Microsoft.OpenApi 1.4.3 supports: netstandard2.0 (.NETStandard,Version=v2.0)

Errors in D:\a\1\s\MyApp.csproj
    Project MyLibrary is not compatible with net70 (.NETFramework,Version=v7.0). Project MyLibrary supports: netstandard2.0 (.NETStandard,Version=v2.0)

This reads to me like it's saying you can't consume .NET Standard 2.0 libraries in a .NET 7.0 project, but the compatibility docs seem to claim otherwise. What's going on here?

Answer 1

update on 12/3

During the investigations and referencing on this issue, I found this ticketGithub_Nuget_Tool_Cache_issue#16800 , more developers are confused with this by-design behavior.

So far, the only workaround seems to be the extra installation of 6.4.x .

You could also raise a feature request ticket to raise more concern for future update on this behavior.

================================================================

Original post on 12/1

I installed the latest nuget version of 6.4.0.123 with nuget tool installer task to ensure the compatibility for Microsoft.OpenApi 1.4.3 with.net7.0.

======================================================

updated on 12/2

From the source page of Microsoft.OpenAPI.1.4.3 , this version is designed to be compatible with DotNet 7.0.

During the investigations, I look into the debug logs, I found that the nuget restore task is using the cache version with 4.x in window-2022. And I suppose that this version is surely not compatible with do.net 70.

After installing the later nuget version to 6.4.x , everything is compatible.

So I suppose the nuget version could be the key to result in the different behavior. (even maybe by design that the Nuget 4.1 could not recognize the compatibility between Microsoft.OpenAPI1.4.3 and Do.net 7.0 )

Reference

NuGet 4.9 Release Notes

NuGet 5.11 Release Notes

NuGet 6.4 Release Notes

Answer 2

Based on @Ceeno's answer, but including for those running YAML pipelines.

https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/nuget-tool-installer-v1?view=azure-pipelines

I just opted to get the latest version.

- task: NuGetToolInstaller@1
  displayName: 'Update NuGet'
  inputs:
    checkLatest: true