Error NU5125: The 'licenseUrl' element will be deprecated since VS 15.9 #7509
Comments
|
@nkolev92 - Do we need to tweak warnings/feedback...or docs...which covers the different ways that people may set these properties? |
|
For those who struggles and looking for the documentation, refer to this spec: https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg. |
|
The question is what property do we set in the csproj file so that it generates a license property in the nuspec? |
|
Those docs are currently in PR. If you want to use an expression, please use If you want to use a license file, please look at Some similar related docs are already live: |
|
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 ( <?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 Should I register that as a separate issue? Or should it be registered in some other project? UPD: It seems to be NPE issue. |
|
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." |
|
@aalmada license file support is coming to nuget.org very soon. We'll announce it on the anouncements repo. |
|
@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 |
|
@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. |
|
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. |
|
What's missing in the
|
This is not a "breaking change", there is no need for a min client version.
https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl The note says, use license instead. So the answer is no.
No, the spec linked above contains more details. Please refer to the issue linked in the spec for the related discussion. Hope this allays your concerns. |
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
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
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
Doing what the warning says and replacing `licenseUrl` with `license` will result in a broken NuGet package as not all tools are ready yet for the new `license` element. Let's wait a little and suppress this warning in the meantime. References: * NuGet/Home#7509 * NuGet/Home#7547
Doing what the warning says and replacing `licenseUrl` with `license` will result in a broken NuGet package as not all tools are ready yet for the new `license` element. Let's wait a little and suppress this warning in the meantime. References: * NuGet/Home#7509 * NuGet/Home#7547
|
STILL broken dotnet\sdk\5.0.300-preview.21258.4\Sdks\NuGet.Build.Tasks.Pack\build NuGet.Build.Tasks.Pack.targets is the source of this bug, not our code. This issue should not be closed. NOTE: If the Repo you've cloned won't build due to this and has "treat warnings as errors" enabled, add NU5125,NU5048 to the list of warning to suppress |
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, preferring instead the new [`<license/>`][3] element. Replace `<licenseUrl/>` with `<license/>`, and provide a `//license/@type` value of `expression`. The value of the `<license/>` element is `MIT`, which is an [SPDX identifier][4], which is a "clearly defined" value, and thus satisfies ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [4]: https://spdx.org/licenses/
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, preferring instead the new [`<license/>`][3] element. Replace `<licenseUrl/>` with `<license/>`, and provide a `//license/@type` value of `expression`. The value of the `<license/>` element is `MIT`, which is an [SPDX identifier][4], which is a "clearly defined" value, and thus satisfies ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [4]: https://spdx.org/licenses/
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, preferring instead the new [`<license/>`][3] element. Replace `<licenseUrl/>` with `<license/>`, and provide a `//license/@type` value of `expression`. The value of the `<license/>` element is `MIT`, which is an [SPDX identifier][4], which is a "clearly defined" value, and thus satisfies ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [4]: https://spdx.org/licenses/
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, preferring instead the new [`<license/>`][3] element. Replace `<licenseUrl/>` with `<license/>`, and provide a `//license/@type` value of `expression`. The value of the `<license/>` element is `MIT`, which is an [SPDX identifier][4], which is a "clearly defined" value, and thus satisfies ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [4]: https://spdx.org/licenses/ Co-authored-by: Min Huang <huangmin@microsoft.com>
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, preferring instead the new [`<license/>`][3] element. Replace `<licenseUrl/>` with `<license/>`, and provide a `//license/@type` value of `expression`. The value of the `<license/>` element is `MIT`, which is an [SPDX identifier][4], which is a "clearly defined" value, and thus satisfies ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [4]: https://spdx.org/licenses/ Co-authored-by: Min Huang <huangmin@microsoft.com> Co-authored-by: Jonathan Pryor <jonpryor@vt.edu>
|
Why do you give a warning regarding a file that is in the latest .net sdk C:\Program Files\dotnet\sdk\6.0.200\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting The file should have been fixed by the writers of this sdk, it's been 4 years since it was reported here and it still wasn't resolved? |
|
The warning is coming from that file, not for that file. |
|
I understand but wasn't Microsoft notified about it and should have fixed it by now? |
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, and MSBuild deprecated the [`$(PackageLicenseUrl)`][3] MSBuild property. The NuGet [`<license/>`][4] element or [`$(PackageLicenseExpression)` MSBuild property][5] should be used. Replace `$(PackageLicenseUrl)` with `$(PackageLicenseExpression)`, with a value of `MIT AND BSD-3-Clause`. The value needs to be an [SPDX identifier][6], and as OpenTK contains both MIT and 3-clause BSD license text within `Documentation/Licennse.txt`, using the `AND` expression feels appropriate. This change should satisfy ClearlyDefined. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target [4]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [5]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file [6]: https://spdx.org/licenses/
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, and MSBuild deprecated the [`$(PackageLicenseUrl)`][3] MSBuild property. The NuGet [`<license/>`][4] element or [`$(PackageLicenseExpression)` MSBuild property][5] should be used. Replace `$(PackageLicenseUrl)` with `$(PackageLicenseExpression)`, with a value of `MIT AND BSD-3-Clause`. The value needs to be an [SPDX identifier][6], and as OpenTK contains both MIT and 3-clause BSD license text within `Documentation/Licennse.txt`, using the `AND` expression feels appropriate. This change should satisfy ClearlyDefined. Update `$(_OpenTKNugetVersion)` to 1.0.2. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target [4]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [5]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file [6]: https://spdx.org/licenses/
Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl Context: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license Context: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata Context: https://docs.clearlydefined.io/curation-guidelines Certain internal Microsoft tools check NuGet license information by using [ClearlyDefined curated data][0] to determine verified license information for packages which don't "clearly define" their license. Unfortunately, a license URL is *not* considered "clearly defined", likely because it isn't *really* machine readable. (Just because the URL contains "MIT" doesn't mean it's *actually* MIT.) As part of this effort, [NuGet deprecated][1] the [`<licenseUrl/>`][2] element, and MSBuild deprecated the [`$(PackageLicenseUrl)`][3] MSBuild property. The NuGet [`<license/>`][4] element or [`$(PackageLicenseExpression)` MSBuild property][5] should be used. Replace `$(PackageLicenseUrl)` with `$(PackageLicenseExpression)`, with a value of `MIT AND BSD-3-Clause`. The value needs to be an [SPDX identifier][6], and as OpenTK contains both MIT and 3-clause BSD license text within `Documentation/Licennse.txt`, using the `AND` expression feels appropriate. This change should satisfy ClearlyDefined. Update `$(_OpenTKNugetVersion)` to 1.0.2. [0]: https://github.com/clearlydefined/curated-data/ [1]: NuGet/Home#7509 [2]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl [3]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target [4]: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license [5]: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file [6]: https://spdx.org/licenses/
|
I've just run into this in February 2023 ... |
From @Tornhoof on November 14, 2018 12:18
Steps to reproduce
Use in a SDK style project to specify the project's license.
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 dotnet/aspnetcore#3751 by @natemcmaster the correct solution for now to get rid of that error?
Environment data
dotnet --infooutput:.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
The text was updated successfully, but these errors were encountered: