aboutcode-org / nuget-inspector

Inspect and resolve .NET and NuGet package dependencies like dotnet and nuget do. Fetch manifests data. Runs on Linux, Windows and macOS as a standalone application.
https://github.com/nexB/nuget-inspector
4 stars 4 forks source link

Support for target framework is not working #11

Closed nnobelis closed 1 year ago

nnobelis commented 1 year ago

Follow up for issues/4.

I tested nuget-inspector 0.7.2.

There is now a CLI parameter to select the target framework for which to output the dependency tree. I use this parameter with the following file https://github.com/oss-review-toolkit/ort/blob/main/analyzer/src/funTest/assets/projects/synthetic/nuget/packages.config.

This file has two frameworks netcoreapp3.1 and net45 are present. I ran

nuget-inspector –verbose --project-file oss-review-toolkit-internal/analyzer/src/funTest/assets/projects/synthetic/nuget/packages.config --nuget-config oss-review-toolkit-internal/analyzer/src/funTest/assets/projects/synthetic/nuget/nuget.config --target-framework=netcoreapp3.1 --json /home/nino/nuget-inspector-result2_netcoreapp3.1.json

and

nuget-inspector/nuget-inspector –verbose --project-file oss-review-toolkit-internal/analyzer/src/funTest/assets/projects/synthetic/nuget/packages.config --nuget-config oss-review-toolkit-internal/analyzer/src/funTest/assets/projects/synthetic/nuget/nuget.config --target-framework=net45 --json /home/nino/nuget-inspector-result2_net45.json

however both files are identical (with the exception of headers.options).

Am I doing something wrong?

Additionally, I would like to confirm something: with the current design of selecting the target framework through a CLI parameter, it means the ORT package manager will have to first identify all the target frameworks (e.g. by parsing the packages.config file), then call nuget-inspector one time for each target framework and collate the results?

pombredanne commented 1 year ago

Thank you for this other report.

pombredanne commented 1 year ago

Am I doing something wrong?

This is a bug alright, we are collecting the frameworks from the deps, but we are not applying it to the resolution in this case like we do with project files.

Additionally, I would like to confirm something: with the current design of selecting the target framework through a CLI parameter, it means the ORT package manager will have to first identify all the target frameworks (e.g. by parsing the packages.config file), then call nuget-inspector one time for each target framework and collate the results?

A packages.config file would never exist alone in practice, so the test file you use may be incomplete as there would be a .csproj or similar side-by-side. This file would typically define what the default or supported target framework like this is done here: https://github.com/nexB/nuget-inspector/blob/a141bd664cb7814547c1226231b3d3da96001589/tests/data/complex/end-to-end1/Sample-ASP.NET-project/Sample.Web/Sample.Web.csproj#L18

The design is to use either:

This is IMHO the best approach.

I could imagine an option to resolve for every mentioned framework but that does not seem realistic. Another option could be to have a way to dump only the reference framework anywhere (either as top level in project file, or in sub files like packages.config)

pombredanne commented 1 year ago

https://github.com/nexB/nuget-inspector/releases/tag/v0.8.0 now supports correctly a provided target framework for the "legacy" packages.config. The logic is to use the command line option if provided and first one if provided in the project file. The project and package framework are compared for compatibility (these are fairly complex rules that only dotnet can really process)

Here are the outputs for the three runs without a target framework and with net45 and netcoreapp3.1:

And I want to reconfirm that in the standard case, the project framework IS in the proj file (like a .csproj file) and should not be required as an input. If not provided and not present in the proj file, we default to "any" framework.

Closing this as solved!