Adding NuGet package target frameworks to component detection data.

[marklio]

Per a conversation about adding target framework information to the component detection data, this is a PR that shows what that could look like.

Things get slightly tricky here since packages declare target frameworks through the dependency declarations in the nuspec, as well as the folder structure of the package. This hasn't been through much testing beyond the unit tests, but they've been augmented to test some potential patterns.

I mainly want to get some feedback on this before I spend much more time on testing. I can potentially test this against all NuGet.org packages pretty easily, which also gives us a test oracle since they calculate target frameworks as well.

Things that might need consideration:

• Addition of NuGet.Packaging as a dependency
• how the data is plumbed through the NuGetComponent (I followed the Authors example as an array of additional strings)
• Removal of async from ProcessFile (nothing in there was async when I finished)
• Shifting more responsibility to NuGetNuspecUtilities even through it's not strictly nuspec-related anymore.
• Using the nuspec reader rather than bespoke XML parsing

I'm open to any and all feedback here.

[JamieMagee]

Hi @marklio, Can I get a bit more context on who you spoke to about this work? And why it's being made i.e. is this a bug fix or a feature?

[marklio]

Yeah, no problem. @chsalgado is who I've been working with, and this is a feature to help the .NET team get a handle on target framework usage for packages across the scope of Component Detection.

[marklio]

Any special instructions for running the tests? I cannot repro these failures locally.

[cobya]

@marklio If you are using Visual Studio the C# tests (what's failing) should be automatically populated in the test explorer. Otherwise you can use dotnet test .\ComponentDetection.sln

[marklio]

@marklio If you are using Visual Studio the C# tests (what's failing) should be automatically populated in the test explorer. Otherwise you can use dotnet test .\ComponentDetection.sln

Yeah, I can't repro these failures in VS or the command-line (I also didn't get build failures initially when I was using new C# features. I do have some local failures, but they are all in the DockerServiceTests project, which I haven't touched.

[JamieMagee]

@marklio I've deconflicted this PR and rebased it on top of current master. See #365. We are keen to get this merged.