16

I just updated a project from .NET 5 to .NET 6. It compiles and runs perfectly locally. When I push this to azure, running my CI pipeline, an error is reporting that:

NU1202: Package MyStandardPackaged 1.0 is not compatible with net60 (.NETFramework,Version=v6.0). Package MyStandardPackaged 1.0 supports: netstandard2.1 (.NETStandard,Version=v2.1)

Is there a workaround this, or I have to update this package declaring .NET 6?

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
Leonardo
  • 10,737
  • 10
  • 62
  • 155
  • [netstandard2.1 platform support](https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.1.md#platform-support) states that .NET 5+ should support it. – Guru Stron Dec 06 '21 at 19:09
  • 1
    I would be genuinely surprised by this, and I'm skeptical - wondering if this is more likely to be a problem with the build tools on your CI server. However! It should be perfectly *possible* (and arguably: desirable) to add a net 6 TFM. Again, I'm not saying that it is (or isn't) necessary, but; it seems incredibly unlikely. – Marc Gravell Dec 06 '21 at 19:15
  • 1
    I got this error when I accidentally launched my project with an older version of Visual Studio. When I closed and re-opened it in VS 2022, these errors went away. (Not the same scenario as the OP, but could help someone else.) – Vaccano Sep 09 '22 at 17:25

1 Answers1

26

If you look very carefully at the error message you posted:

NU1202: Package MyStandardPackaged 1.0 is not compatible with net60 (.NETFramework,Version=v6.0). Package MyStandardPackaged 1.0 supports: netstandard2.1 (.NETStandard,Version=v2.1)

Notice that it says that net6.0 is .NETFramework,Version=v6.0. However, .NET 6 is actually .NETCoreApp,Version=v6.0.

Therefore, I conclude you are using some old version of NuGet, that doesn't even know about .NET 5, to restore your project/solution.

My recommendation is to avoid the NuGetCommand task in Azure DevOps. Off the top of my head I can't think of any reason to use it, all the important features needed for a CI script exists in the dotnet CLI and MSBuild.exe.

Therefore, if all the projects in your solution/repo are SDK style (contain Sdk="whatever" in the project file), then use dotnet restore. If you have even a single non-SDK style project (every .cs in the directory is listed in the XML) then use msbuild -t:restore. This way, you'll never have a problem of mismatched NuGet versions again.

zivkan
  • 12,793
  • 2
  • 34
  • 51
  • I actually am using the `NuGetCommand` and after I republished my project adding .Net 6 explicitly it all worked... – Leonardo Dec 06 '21 at 22:27
  • 3
    That will be because the old version of NuGet will incorrectly think both the package and project are using .NET Framework version 6.0, which doesn't actually exist. It also means you don't have performance improvements or bug fixes, or features like package source mapping available to you. I still strongly recommend you stop using `NuGetCommand` and instead directly invoke `dotnet restore` or `msbuild -t:restore` from a command line task instead. – zivkan Dec 07 '21 at 01:08
  • In fact, that's also the suggestion from the Azure DevOps team themselves: https://github.com/NuGet/Home/issues/11406#issuecomment-982099267 https://github.com/microsoft/azure-pipelines-tasks/issues/15542#issuecomment-982091805 – zivkan Dec 07 '21 at 01:10
  • 1
    I noticed that the message talks about net60 without the period, while the correct TFM is net6.0. Maybe there was an issue with that... – Palec Dec 14 '22 at 12:54