Home: Error NU5125: The 'licenseUrl' element will be deprecated since VS 15.9

[livarcocc]

_From @Tornhoof on November 14, 2018 12:18_

Steps to reproduce

Use in a SDK style project to specify the project's license.

1. Install VS 15.9 (SDK 2.1.500)
2. Clone https://github.com/Tornhoof/SpanJson.git
3. dotnet build -c Release

Expected behavior

Everything is builds and two nugets are created

Actual behavior

Everything is builds and two nugets are created
and I get:
NU5125 The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead. SpanJson C:\Program Files\dotnet\sdk\2.1.500\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets 202

What is the expected replacement here, I don't specify "licenseUrl" in my csproj, I use PackageLicenseUrl, which is apparently the "right" way according to https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget

Is https://github.com/aspnet/AspNetCore/issues/3751 by @natemcmaster the correct solution for now to get rid of that error?

Environment data

dotnet --info output:

.NET Core SDK (gemäß "global.json"):
Version: 2.1.500
Commit: b68b931422

Laufzeitumgebung:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.500\

Host (useful for support):
Version: 2.1.6
Commit: 3f4f8eebd8

.NET Core SDKs installed:
1.0.0 [C:\Program Files\dotnet\sdk]
1.0.3 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
2.0.0 [C:\Program Files\dotnet\sdk]
2.0.2 [C:\Program Files\dotnet\sdk]
2.0.3 [C:\Program Files\dotnet\sdk]
2.1.2 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.101 [C:\Program Files\dotnet\sdk]
2.1.102 [C:\Program Files\dotnet\sdk]
2.1.103 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.200 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.302 [C:\Program Files\dotnet\sdk]
2.1.400 [C:\Program Files\dotnet\sdk]
2.1.401 [C:\Program Files\dotnet\sdk]
2.1.402 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

_Copied from original issue: dotnet/cli#10333_

[rrelyea]

@nkolev92 - Do we need to tweak warnings/feedback...or docs...which covers the different ways that people may set these properties?
@karann-msft

[zvirja]

For those who struggles and looking for the documentation, refer to this spec: https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg.

[phatcher]

The question is what property do we set in the csproj file so that it generates a license property in the nuspec?

[nkolev92]

@phatcher

Those docs are currently in PR.
https://github.com/NuGet/docs.microsoft.com-nuget/pull/1173

If you want to use an expression, please use PackageLicenseExpression.

If you want to use a license file, please look at
https://github.com/nkolev92/docs.microsoft.com-nuget/blob/nkolev92-licenseDocs/docs/reference/msbuild-targets.md#packing-a-license-file

Some similar related docs are already live:
https://docs.microsoft.com/en-us/nuget/reference/nuspec#license

[zvirja]

Hi guys,

I've found that if you follow the described steps, the corrupted package is generated.

Project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <PropertyGroup>
    <PackageLicenseFile>LICENSE.txt</PackageLicenseFile>
  </PropertyGroup>

  <ItemGroup>
    <None Include="LICENSE.txt" Pack="true" PackagePath="$(PackageLicenseFile)"/>
  </ItemGroup>

</Project>

When I'm trying to open the package in the latest version of NuGet Package Explorer, I'm getting the following error:

The NuSpec file (obj\Debug\PackTest.1.0.0.nuspec):

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>PackTest</id>
    <version>1.0.0</version>
    <authors>PackTest</authors>
    <owners>PackTest</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="file">LICENSE.txt</license>
    <licenseUrl>https://aka.ms/deprecateLicenseUrl</licenseUrl>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETStandard2.0" />
    </dependencies>
  </metadata>
  <files>
    <file src="C:\Users\Alex\Documents\Visual Studio 2017\Projects\PackTest\PackTest\bin\Debug\netstandard2.0\PackTest.dll" target="lib\netstandard2.0\PackTest.dll" />
    <file src="C:\Users\Alex\Documents\Visual Studio 2017\Projects\PackTest\PackTest\LICENSE.txt" target="LICENSE.txt" />
  </files>
</package>

So indeed both license and licenseUrl are present.

Should I register that as a separate issue? Or should it be registered in some other project?

UPD: It seems to be NPE issue.

[aalmada]

I was able to add the license file to my package but then, when I try to upload it to NuGet.org, I get the error "License files are not yet supported."

[karann-msft]

@aalmada license file support is coming to nuget.org very soon. We'll announce it on the anouncements repo.

[phatcher]

@karann-msft I think a more general point would be that you shouldn't be generating deprecated warnings until the whole end-to-end experience is debugged and released.

We are in the situation now where if we fix the VS warnings, the nuget packages are non-compliant

[karann-msft]

@phatcher yes in an ideal world. But we had to ship client code with VS 2017 so that most users would be on a client that understands the new license metadata and in parallel we are working on the gallery support. At the same time, we can't just flip a switch one day and say move to license, which is why we warn and not error. licenseUrl has not been deprecated just yet. NuGet.org still very much accepts it.

[jherby2k]

You shouldn't have generated the warning until the feature was ready to be deprecated. This is just causing everyone's wheels to spin unnecessarily. Oh well.

[stakx]

What's missing in the <license> documentation for me is:

• What's the recommendation on how to set <metadata minClientVersion="?"> when using the new <license> field? Will older NuGet clients/tooling fail to parse a .nuspec file containing it?
• Is it possible to set both <license> (for newer NuGet clients) and <licenseUrl> (for older clients)?
• Can there be more than one <license> element, e.g. one for a file including the year, copyright holder, etc. in the copyright notice, and one for an expression summarizing the license file?

[nkolev92]

@stakx

What's the recommendation on how to set <metadata minClientVersion="?"> when using the new <license> field? Will older NuGet clients/tooling fail to parse a .nuspec file containing it?

This is not a "breaking change", there is no need for a min client version.
The old clients will interpret licenseurl, while the new ones will prefer the license element if present.

Is it possible to set both <license> (for newer NuGet clients) and <licenseUrl> (for older clients)?

https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl

The note says, use license instead. So the answer is no.
See https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg-(Technical-Spec) for more details about why we did what we did.

Can there be more than one <license> element, e.g. one for a file including the year, copyright holder, etc. in the copyright notice, and one for an expression summarizing the license file?

No, the spec linked above contains more details. Please refer to the issue linked in the spec for the related discussion.
Similar to all other elements in the metadata section,the license element cannot be duplicated.

Hope this allays your concerns.