New NU1701 errors appearing after May 10th release of SDK (6.0.300)

[jasonleenaylor]

Describe the bug

Our github actions started failing today with the following error:
error NU1701: Package 'RelaxNG 3.2.3' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project.

There were no changes to any code or project files to explain the sudden failure.
I think this behavior used to be a warning?

If this was an intentional change I would expect to find it in the release notes but I didn't see anything mentioning NU1701 or any update to the restore behavior,

To Reproduce

The workflow log for the first failure can be viewed here:
https://github.com/sillsdev/TheCombine/runs/6376161726?check_suite_focus=true
The PR that triggered it is here:
https://github.com/sillsdev/TheCombine/pull/1659/files

Further technical details

Our log had one sdk sha on the build that worked:
[builder 1/6] FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:fde93347d1cc74a03f1804f113ce85add00c6f0af15881181165ef04bc76bd00
and an updated one when it began to fail:
[builder 1/6] FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:27372653b52f0e0215574be2d1e74db2e9e6b3f09ad74c5618f0f5788cd848dd

[kenans]

Also encountered the same issue while restoring Nuget packages with 6.0.300. Note the previous SDK version (6.0.203) doesn't report error NU1703. Wonder if it's something new introduced by this release?

Another similar issue from the dotnet-docker repo: dotnet/dotnet-docker#3765

[kenans]

Checking out the commit history, seems Nuget.Client dependency was upgraded recently, which might be related to the issue.

NU1701 used to be a warning and is still being documented so. Now it seems to be reported as an error.

[zivkan]

.NET SDK 6.0.300 brings in NuGet 6.2, which fixed a long-standing bug with asset target fallback not bringing in dependencies, which causes runtime failures for affected customers. This only happens when package authors mismatch the package dependencies vs package assets (usually lib/ folder). NuGet has been warning package authors about this for 2-3 years, but page authors who use old versions of NuGet or ignore the warning might still be generating potentially problematic packages, plus older packages, the authors might not have been aware. There's a good chance that's the cause of the error you're seeing. We have a sample which explains it better, with some links to issues if that help: https://github.com/NuGet/Samples/tree/main/AssetTargetFallbackTransitiveDependencies

Note, as @kenans points out, NuGet treats it as a warning. If your project uses <TreatWarningsAsErrors>true, or similar, then your project is asking to be broken by warnings. As documented in a few places, you can NoWarn those NuGet codes and they'll neither warning nor error your build.

cc @nkolev92

[kenans]

@zivkan Thanks for your reply! I confirmed we no longer have NU1701 after removing the incompatible transitive dependencies.

[jasonleenaylor]

@zivkan So from your comment I gather the following:
There was a change in NuGet 6.2 that pulls in transitive dependencies in new situations which can cause this warning to appear when it did not before.
It is a warning from NuGet, so it should not cause an error in our build unless we are treating warnings as errors.
The workaround is to add NoWarn (in as narrow scope as possible)

[zivkan]

Another option, if your app doesn't need asset target fallback, is to disable the feature:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets

Lines 173 to 175 in 997376c

	<PropertyGroup Condition="'$(DisableImplicitAssetTargetFallback)' != 'true' and '$(_IsNETCoreOrNETStandard)' == 'true' and '$(_TargetFrameworkVersionWithoutV)' >= '2.0'">
	<AssetTargetFallback>$(AssetTargetFallback);net461;net462;net47;net471;net472;net48</AssetTargetFallback>
	</PropertyGroup>

[baronfel]

@jasonleenaylor did @zivkan's answers resolve the issue for you?

[baronfel]

I'm going to close this out - we've been discussing future strategies for rolling out new warnings and errors across the SDK and we hope to have a smoother rollout process for future SDK releases. We don't want to stop teams from developing new safety features, but we also don't want users to be wary of updating the SDK.