Creating NuGet package: NU5128 exception - not clear on how to fix

Question

I have a DLL addressing the .NET 4.7.1 library.

Probably irrelevant, but it's written in C# and consumes NuGet packages using the "packages.config" pattern, rather than the newer PackageReference configuration.

I publish this as a NuGet package (have been doing this for several years). But now when I execute the following:

nuget pack -Properties Configuration=Release

I get the following warning:

Error NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below: - Add a dependency group for .NETFramework4.7.1 to the nuspec

I don't have anything in the dependencies group of the nuspec:

<?xml version="1.0"?> 
<package >   
    <metadata>
        <id>*******</id>
        <version>*******</version>
        <title>*******</title>
        <authors>*******</authors>
        <owners>*******</owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>*******</description>
        <releaseNotes>*******</releaseNotes>
        <copyright>*******</copyright>
        <tags>*******</tags>
   </metadata> 
</package>

This consumes the following NuGet packages:

• Microsoft.AspNet.WebApi.Client v5.2.7
• Microsoft.AspNet.WebApi.Core v5.2.7
• Microsoft.CodeAnalysis.FxCopAnalyzers v2.9.8
• Microsoft.CodeAnalysis.VersionCheckAnalyzer v2.9.8
• Microsoft.CodeQuality.Analyzers v2.9.8
• Microsoft.NetCore.Analyzers v2.9.8
• Microsoft.NetFramework.Analyzers v2.9.8
• Newtonsoft.Json v12.0.3
• StyleCop.Analyzers v1.1.118

When I look under the References, I see the following (used ~ to shorten the path):

• Microsoft.CSharp ~.NETFramework\v4.7.1\Microsoft.CSharp.dll
• Newtonsoft.Json ~\packages\Newtonsoft.Json.12.0.3\lib\net45\Newtonsoft.Json.dll
• System ~\NETFramework\v4.7.1\System.dll
• System.Configuration ~.NETFramework\v4.7.1\System.Configuration.dll
• System.Core ~.NETFramework\v4.7.1\System.Core.dll
• System.Data ~.NETFramework\v4.7.1\System.Data.dll
• System.Data.DataSetExtensions ~.NETFramework\v4.7.1\System.Data.DataSetExtensions.dll
• System.Net.Http ~.NETFramework\v4.7.1\System.Net.Http.dll
• System.Net.Http.Formatting ~\packages\Microsoft.AspNet.WebApi.Client.5.2.7\lib\net45\System.Net.Http.Formatting.dll
• System.Web.Http ~\packages\Microsoft.AspNet.WebApi.Core.5.2.7\lib\net45\System.Web.Http.dll
• System.Xml ~.NETFramework\v4.7.1\System.Xml.dll
• System.Xml.Linq ~.NETFramework\v4.7.1\System.Xml.Linq.dll

So to my mind, everything looks like it's .NET 4.7.1 compatible, so why this warning?

Following the details given in NuGet Warning NU5128, I therefore added a dependency group:

<?xml version="1.0"?> 
<package >   
    <metadata>
        <id>*******</id>
        <version>*******</version>
        <title>*******</title>
        <authors>*******</authors>
        <owners>*******</owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>*******</description>
        <releaseNotes>*******</releaseNotes>
        <copyright>*******</copyright>
        <tags>*******</tags>
        <dependencies>
          <group targetFramework=".NETFramework4.7.1" />
        </dependencies>
   </metadata> 
</package>

But this has no effect, I still get the error.

Answer 1

As per NU5128 doc, This warning was added during NuGet 5.3's development, and first was available in .NET Core SDK 3.0 Preview 9. NuGet/Home#8583 tracks an issue where the warning was being raised in too many scenarios. You can use the NoWarn MSBuild property (add $(NoWarn);NU5128 to any PropertyGroup in your project file). If you have multiple projects affected, you can use Directory.Build.targets to automatically add NoWarn to all projects

Answer 2

As of Nuget 5.7 this is now reported as an error from Nuget CLI (https://github.com/NuGet/Home/issues/7404) - So our pipeline started to fail even though we had this error before.

We ended up with the Nowarn approach in relevant csproj files as described above - But I wanted to add that this may suddenly cause issues in already running pipelines.