In my DevOps build pipeline NuGetCommand fails with an error
The nuget command failed with exit code(1) and error NU1202 package MyPackage is not compatible with net70-windows (.NETFramework,Version=v7.0,Profile=windows).
I don't get errors building and publishing MyPackage with
<TargetFramework>net7.0-windows</TargetFramework>
Why do I get this error when I try to use it?
I also tried updating the TargetOSVersion. Now the message is
##[error]The nuget command failed with exit code(1) and error(NU1202: Package MyPackage is not compatible with net70-windows10.0.17763.0 (.NETFramework,Version=v7.0,Profile=windows10.0.17763.0). Package MyPackage supports: net70-windows10.0.17763 (.NETFramework,Version=v7.0,Profile=windows10.0.17763)
TL;DR: stop using - task: NuGetCommand and use - script: dotnet restore my.sln
As Guru Stron wrote in the comments, the fact that NuGet is reporting .NETFramework, rather than .NETCoreApp is a sign that something has gone very wrong. In this case, it's because when you don't use the NuGetInstaller task, it defaults to some old version, and this old version of NuGet was created before .NET 5 was released, so it doesn't know about all the newer changes to the .NET ecosystem.
However, I very strongly discourage you from using NuGetCommand. As the docs say:
This task also uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
However, I also recommend against using the DotNetCoreCli task. The way it handles authentication to private Azure Artifacts feeds is by copying your nuget.config file, modifying it, including changing source names, and then running retore with --configfile path\to\generated\nuget.config. A NuGet feature released in September 2021, called Package Source Mapping, requires the source name to match between two sections of the nuget.config file, so Azure Pipeline's NuGetCommand and DotNetCliCommand tasks breaks when using Package Source Mapping. While someone on the Azure Pipelines team said back in Novermber of 2021 that they're "in the process of deprecating the heavyweight NuGet command task and its equivalent in other protocols including dotnet", I don't see evidence of it happening yet. In any case, I still suggest not using it. Another reason is that when something goes wrong, it's opaque what commands it's actually running, so it's just about impossible to test locally. However, if your pipeline is running script tasks, you can try running the same commands locally to debug issues.
So, in conclusion, I suggest a pipeline similar to the following:
steps:
# set up access to private Azure Artifacts feeds
- task: NuGetAuthenticate@1
- script: dotnet restore my.sln
displayName: NuGet restore
- script: dotnet build my.sln --no-restore
displayName: dotnet build
# whatever other stuff your build does