New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat (dotnet support) complete dotnet support with fallbacks. #450
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Codecov Report
@@ Coverage Diff @@
## master #450 +/- ##
========================================
+ Coverage 49.71% 51.71% +2%
========================================
Files 83 91 +8
Lines 4385 4654 +269
========================================
+ Hits 2180 2407 +227
- Misses 1990 2014 +24
- Partials 215 233 +18
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a very thorough job, a good example of what a fossa-cli solution for a language ecosystem could look like. :)
I know you didn't implement NuGet support initially, but with these improvements I think the docs in docs/integrations/nuget.md
should be updated too. In particular, we currently say:
NuGet support in FOSSA CLI depends on the following tools existing in your environment:
- [.NET Core CLI](https://docs.microsoft.com/en-us/dotnet/core/tools/) (defaults to `dotnet`, configure with `$DOTNET_BINARY`)
- [NuGet](https://www.nuget.org/downloads) (defaults to `nuget`, configure with `$NUGET_BINARY`)
Yet the CLI apparently doesn't use the nuget
binary or the NUGET_BINARY
environment variable anywhere.
Similarly, if we're going to let users manually specify a resolution strategy (https://github.com/fossas/fossa-cli/pull/450/files#diff-9b9e9c38147534ae1a6273a90dd4e969R22), we should document this somehow, e.g.:
You can specify which dependency resolution tool the CLI should use by
adding a `strategy: strategy_name` property under `options` in your `.fossa.yml`.
For example:
analyze:
modules:
- name: dn1.csproj
type: nuget
target: dn1.csproj
path: .
options:
strategy: paket
I'm not even sure if that's correct.
Perhaps the nuget.md
doc should be renamed to dotnet.md
and list nuget
as just one of the deps manager. Again, I don't know this ecosystem well enough, so maybe I'm not making sense.
@dchenk your comments are spot on about cli documentation, previously we checked for the existence of the dotnet binary but I removed part of that functionality because we weren't actually using it to determine dependencies. You are correct about how to specify options as well, thanks for the feedback! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great overhaul of support for .NET and improvement of the docs. :)
Add complete support for .NET.
This closes #173, closes #172, closes #378, closes #408.
Significant changes:
Analyze()
function, but discovery is very difficult to do inline with analysis for package reference files.Todo
I also need to determine if the type switch in
project_json.go
is the correct way to do things.