nuget-license icon indicating copy to clipboard operation
nuget-license copied to clipboard

Published 20 hours ago • verified publisher icon tomchavakis

Use NuGet implementation for operations

Open sensslen opened this issue 4 years ago • 7 comments

I lately came across a shortcoming of this utility when I encountered a Package that specified a range of allowed dependencies (see https://github.com/tomchavakis/nuget-license/pull/50 for my intermediate solution).

This rose the question why not use something like https://www.nuget.org/packages/NuGet.Commands/5.8.1 to do all dependency resolve work and stuff and just concentrate on the proper license handling.

sensslen avatar Feb 11 '21 09:02 sensslen

We also just came across an issue like this. The tool tried to resolve a version-range like [4.0.11, ) and it failed with https://www.nuget.org/api/v2/package/Serilog/[2.0.0 failed due to BadRequest!

It seems like it fails to parse the Version-String corretly, leaving a [ which breaks the URI.

wgnf avatar Feb 24 '21 12:02 wgnf

This is exactly the reason for this PR. Unfortunately this PR does not resolve the issue that a license might change between two versions and thus it would be nice to know exactly which version gests resolved by NuGet.

sensslen avatar Feb 24 '21 16:02 sensslen

Thats an issue right, but first it would be nice, when this tool isn't failing for those mentioned use-cases.

Thanks for that PR then, hope this'll be merged soon 👍🏼

wgnf avatar Feb 24 '21 16:02 wgnf

Hi guys,

Thank's again for this contribution and the related PR. Is there any example of the remaining issue in order to find out a possible solution?

tomchavakis avatar Mar 25 '21 09:03 tomchavakis

Well, I am currently not aware of a real world example of the Problem.

nevertheless the following (theoretical) problems exist:

  • If a packet dependency is specified as a range and the dependant package changed it's License in this range, we check for two licenses. This can lead to false positive issues, as a license is checked that is not acually used
  • If a packet dependency is specified as a range and the dependant package changed it's License twice in this range, we do not check the middle license. This can lead to false negatives, as the middle license is not checked and might be used
  • If a packet specifies a dependency range and explicitely excludes one or both specified versions (using the dependency syntax) the versions checked are for sure not the version used.

To shorten this comment I'm not going into more details, but there are more scenarios, in which the licenses checked don't actually match the license of the packet actually used. This could all be fixed by querying the actual nuget algorythm to resolve all used dependencies and then use this list to check it's licenses.

sensslen avatar Mar 25 '21 10:03 sensslen

I agree with you, there are 2 different ways of resolving this issue

  • Analyse all nuget dependencies and find out the version that actually used based on the version ranges.
  • Use the nuget commands library for that purpose which is the safest approach for this tool.

tomchavakis avatar Mar 25 '21 10:03 tomchavakis

I just updated the docs for 3.0.0-alpha. My company is using this version for some time now without issues. It might be ready for a release.

sensslen avatar Apr 23 '22 19:04 sensslen

Closing this issue because this the referenced reqrite was published as alpha version to the nuget library.

sensslen avatar Sep 03 '22 19:09 sensslen

Thank you @sensslen for your work:

The published version is here: https://www.nuget.org/packages/dotnet-project-licenses/3.0.0-alpha.1

tomchavakis avatar Sep 03 '22 19:09 tomchavakis