You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The current implementation of checking for locking dependencies in .net only checks if the command that is used is of type "dotnet.exe restore --locked-mode" or "msbuild.exe -t:restore -p:RestoreLockedMode=true", but ignores cases in which the maintainer opts for using RestoreLockedMode MSBuild property in their project file as such:
Reproduction steps
Steps to reproduce the behavior:
when scanning for pinned dependency a repo which leverages RestoreLockedMode MSBuild property, the pinning should be detected.
example: go run main.go --repo elastic/elasticsearch-net --checks Pinned-Dependencies --format json --show-details | jq
Expected behavior
.net repositories can leverage either restore behavior with lock file that is documented and the pinned dependency score should be similar.
For the example given above (elastic/elasticsearch-net), the score for pinned nugetCommand dependencies should be 3 out of 3.
The text was updated successfully, but these errors were encountered:
Describe the bug
The current implementation of checking for locking dependencies in .net only checks if the command that is used is of type "dotnet.exe restore --locked-mode" or "msbuild.exe -t:restore -p:RestoreLockedMode=true", but ignores cases in which the maintainer opts for using RestoreLockedMode MSBuild property in their project file as such:
more info here
Reproduction steps
Steps to reproduce the behavior:
Expected behavior
.net repositories can leverage either restore behavior with lock file that is documented and the pinned dependency score should be similar.
For the example given above (elastic/elasticsearch-net), the score for pinned nugetCommand dependencies should be 3 out of 3.
The text was updated successfully, but these errors were encountered: