Showing multiple nuget dependencies disregard of target framework in package.config file

[MoumitaManna]

Hi ORT Team,

We tried to run ORT on .cs projects for nuget dependencies and found that the analyzer-result.json getting generated shows all the dependencies irrespective of the target framework mentioned in the packages.config file for the .cs projects.
For example: PFA the packages.config file which shows only two dependencies and also the generated analyzer-result.json file
packages.config.txt
analyzer-result.json.txt

The target framework mentioned in the packages.config file is .netstandard2.0 so instead of picking the dependencies for .netstandard2.0 only, ORT is getting all the dependencies for all the frameworks and getting the unique dependencies out of it which are then shown in the ORT result i.e. analyzer-result.json.

I suppose this is a bug as ORT shall show only the nuget dependencies for the target framework mentioned in the packages.config file.

Can you please let us know whether it is working as expected or its a bug. And if its a bug then when will it be resolved.

Regards,
Moumita

[sschuberth]

I consider this to be a bug / limitation of the current implementation. I'm not a .NET guy, but I guess what needs to be done is to add

    @JacksonXmlProperty(isAttribute = true)
    val targetFramework: String? = null

to

ort/analyzer/src/main/kotlin/managers/NuGet.kt

Lines 78 to 84 in 6dd90e4

	@JsonIgnoreProperties(ignoreUnknown = true)
	private data class Package(
	@JacksonXmlProperty(isAttribute = true)
	val id: String,
	@JacksonXmlProperty(isAttribute = true)
	val version: String
	)

and then somehow take the targetFramework into account when building the dependency tree in

ort/analyzer/src/main/kotlin/managers/utils/NuGetSupport.kt

Lines 196 to 201 in 6dd90e4

	fun buildDependencyTree(
	references: Collection<Identifier>,
	dependencies: MutableCollection<PackageReference>,
	packages: MutableCollection<Package>,
	issues: MutableCollection<OrtIssue>
	) {

[mnonnenmacher]

@MoumitaManna I had a deeper look into the NuGet implementation and found several issues. If you want you could try out my test implementation in the "nuget-rewrite" branch which should address most issues, however to correctly fix the issue the NuGet implementation should be rewritten. I will close this issue in favor of #5038 where I have documented my findings.