Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
livarcocc opened this Issue Nov 14, 2018 · 12 comments

Comments

Projects
None yet
9 participants
@livarcocc
Copy link

livarcocc commented Nov 14, 2018

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 aspnet/AspNetCore#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

This comment has been minimized.

Copy link
Contributor

rrelyea commented Nov 14, 2018

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

@nkolev92 nkolev92 added the Type:Docs label Nov 14, 2018

@zvirja

This comment has been minimized.

Copy link

zvirja commented Nov 22, 2018

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

This comment has been minimized.

Copy link

phatcher commented Nov 24, 2018

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

@nkolev92

This comment has been minimized.

Copy link
Member

nkolev92 commented Nov 25, 2018

@phatcher

Those docs are currently in PR.
NuGet/docs.microsoft.com-nuget#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

This comment has been minimized.

Copy link

zvirja commented Nov 26, 2018

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:
image

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

This comment has been minimized.

Copy link

aalmada commented Dec 9, 2018

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

This comment has been minimized.

Copy link
Contributor

karann-msft commented Dec 11, 2018

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

@phatcher

This comment has been minimized.

Copy link

phatcher commented Dec 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

karann-msft commented Dec 11, 2018

@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

This comment has been minimized.

Copy link

jherby2k commented Dec 13, 2018

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.

chadly pushed a commit to civicsource/data that referenced this issue Dec 26, 2018

Chad Lee

chadly pushed a commit to civicsource/data that referenced this issue Dec 26, 2018

Chad Lee

StephenCleary added a commit to StephenCleary/AsyncEx that referenced this issue Dec 28, 2018

@stakx

This comment has been minimized.

Copy link

stakx commented Dec 30, 2018

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

This comment has been minimized.

Copy link
Member

nkolev92 commented Jan 2, 2019

@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.

0xced added a commit to 0xced/azure-service-bus-dotnet that referenced this issue Mar 16, 2019

Fix "The 'licenseUrl' element will be deprecated" error
When generating the package, the NuGet task emits this warning:

> The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead.

Since `TreatWarningsAsErrors` is set to true in Directory.Build.props it becomes an error.

So we simply ignore this warning since we can't use 'license' instead of 'licenseUrl' yet.

See also NuGet/Home#7509 and NuGet/Announcements#32

0xced added a commit to 0xced/azure-service-bus-dotnet that referenced this issue Mar 16, 2019

Fix "The 'licenseUrl' element will be deprecated" error
When generating the package, the NuGet task emits this warning:

> The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead.

Since `TreatWarningsAsErrors` is set to true in Directory.Build.props it becomes an error.

So we simply ignore this warning since we can't use 'license' instead of 'licenseUrl' yet.

See also NuGet/Home#7509 and NuGet/Announcements#32

SeanFeldman added a commit to Azure/azure-service-bus-dotnet that referenced this issue Mar 18, 2019

Fix "The 'licenseUrl' element will be deprecated" error (#666)
When generating the package, the NuGet task emits this warning:

> The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead.

Since `TreatWarningsAsErrors` is set to true in Directory.Build.props it becomes an error.

So we simply ignore this warning since we can't use 'license' instead of 'licenseUrl' yet.

See also NuGet/Home#7509 and NuGet/Announcements#32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.