* Include non-implementation packages on .NETCore 2.x
Microsoft.NETCore.App contains only reference assemblies, but it was listed in CVEs, so should be excluded. The same is true for System.Private.Uri.
I did not include these previously because they weren't part of package overrides list, nor were they found through package comparisons - since conflict resolution doesn't need to do anything with non-implementation packages. They are important for CG though since they've been used in CVE reports.
* Include framework packages for .NET 4.6.1
.NET 4.6.1 supports .NET Standard and has built in support for it that will win over nuget packages.
In .NET 4.6.1 - .NET 4.7.1 this comes from the Microsoft.NET.Build.Extensions component, after that it's built into the framework itself.
* Detect nuget framework packages for additional frameworks
This adds support for additional framework references -
Microsoft.AspNetCore.App and Microsoft.WindowsDesktop.App
* Add experimental NuGet detector for framework and dev dependencies
This PR does 3 things.
1. Adds `TargetFramework` to NuGet package references. This can be useful when querying component data to understand if components are used in a place where a vulnerability applies.
2. Adds _framework package_ handling. The .NET SDK will do [conflict resolution](https://github.com/dotnet/sdk/tree/main/src/Tasks/Common/ConflictResolution) and drop assets from packages that overlap with the framework. NuGet is planning to do the same https://github.com/NuGet/Home/issues/7344 but until then, it's beneficial to have component detection duplicate some of this logic. When a package is identified as overlapping with the framework we'll treat it as a Development Dependency so that it might be auto-dismissed.
- .NETFramework projects do not get this - .NETFramework does not participate in conflict resolution by default. Even when enabled framework assemblies can be bypassed using bindingRedirects, or avoiding references to them. Due this fragility it's not safe to apply framework package rules to .NETFramework.
- packages.config usage is also excluded since it precludes SDK conflict resolution (and is also only used on .NETFramework projects).
3. Recognizes `ExcludeAssets="Runtime"` usage as a Development Dependencies, also any packages which don't contribute to "runtime" will be developement dependencies.
I reused _Development Dependency_ rather than plumbing a new concept.
I only mapped data for the `Microsoft.NETCore.App` - the default shared framework. We could consider doing the same for `Microsoft.ASPNETCore.App` and `Microsoft.WindowsDesktop.App` but we'd need to plumb the reference information out of the assets file - currently that's not read and I'm not aware of a supported NuGet API for reading it (though it is present under `project/frameworks/<framework>/frameworkReferences/<name>`
.NET Core 1.x has no data since it was packages itself. I have a fallback for future frameworks to read the data from the targeting packs.
* Address feedback
Previous limitations was written before new nuget detector was rolled out. This clarifies some of the points and removes the indication that the new detector hasn't rolled out yet.
* add feature that removes some python files that are created during pip install report dry run
* move to more central file detector
* add tests and fix bugs
* remove extra dir
* fix dotnet 8 styling
* semaphore to only run a single cleanup process at a time for a given detector
* add test
* add test
* refactor to abstract file and directory operations out to allow for unit tests with a mocked file system
* break out the cleanup changes to its own abstract class
* pr feedback
* rename vars and fix tests
* torevert: quick console log for test
* revert log and add file to source control
* os agnostic test file paths
* update snapshot verify, and bump report version
* add python to verification pipeline
* adding back setup file
* Use MSTest meta package
This enables running MSTest Analyzers on test code to help avoid common test problems.
* Fix code coverage
* Fixes
Upgrade to latest and fix unnecessary type param
* Fix tests
* PR feedback
* Fix CC
* fix bug where pipreport used index urls in requirements.txt
* update tests
* docs
* add --no-input to pip install, so we do not hang waiting for user input
* pr feedback: performance and cleanup
* bump version
* add support for python -m pip
* update pip command service to accept python exe
* swap so we use pip as default
* fixing remote build
* fix tests
* add unit tests
* ignore pregenerated pipreports that don't cover the correct set of dependencies
* add validation to the pre-generated pipreport to prevent underdetection for overridden reports
* dispose of telemetry object
* move re-used code to a common utility method
Paul Dorsch
Eric StJohn
Greg Villicana
Fernando Rojo
renovate[bot]
dependabot[bot]
Amitla Vannikumar
Coby Allred
cobya
stan-sz