-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
C#: Exclude Semmle.* dlls when using the executing runtime. #15993
C#: Exclude Semmle.* dlls when using the executing runtime. #15993
Conversation
8fa54a0
to
8fb924f
Compare
csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/AssemblyPath.cs
Fixed
Show fixed
Hide fixed
afdb6eb
to
5a70f70
Compare
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.
I've added some minor comments.
Additionally, we could consider extending the logic in AssemblyPath
, which currently covers two cases:
- file path
- all files from a directory (recursively)
A third case would be
- all files from a directory (only top level)
We're already using this latter case in AddFrameworkDlls
.
} | ||
else | ||
{ | ||
logger.LogInfo("AssemblyCache: Path not found: " + p); |
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.
Copy-paste issue: AssemblyCache
vs AssemblyPath
@@ -71,7 +71,7 @@ public DependencyManager(string srcDir, ILogger logger) | |||
this.generatedSources = new(); | |||
var allProjects = allNonBinaryFiles.SelectFileNamesByExtension(".csproj").ToList(); | |||
var allSolutions = allNonBinaryFiles.SelectFileNamesByExtension(".sln").ToList(); | |||
var dllPaths = allFiles.SelectFileNamesByExtension(".dll").ToHashSet(); | |||
var dllPaths = allFiles.SelectFileNamesByExtension(".dll").Select<string, AssemblyPath>(x => x).ToHashSet(); |
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.
Just an opinion: I find .Select<string, AssemblyPath>(x => x)
difficult to read, I think .Select(x => new AssemblyPath(x))
is easier to understand.
{ | ||
logger.LogInfo("AssemblyCache: Path not found: " + path); | ||
} | ||
path.Process(dllsToIndex, logger); |
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.
This Process
call could be changed to simply return a list of DLL paths, and then the return value could be used: dllsToIndex.AddRange(path.GetFilePaths(logger))
. This way the AssemblyPath
is more self contained as we're not pushing "state" into it.
/// Used to represent a path to an assembly or a directory containing assemblies | ||
/// and a selector function to determine which files to include, when indexing the assemblies. | ||
/// </summary> | ||
internal sealed class AssemblyPath(string p, Func<string, bool> includeFileName) |
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.
Maybe AssemblyLookupLocation
is a somewhat better name for this, as it's not necessarily an assembly path that we're storing here.
I will extend the scope a bit more on this PR. |
…stead of strings.
…on and log if no dlls are found in a directory.
5a70f70
to
ff498f6
Compare
csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/DependencyManager.cs
Show resolved
Hide resolved
csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/AssemblyLookupLocation.cs
Fixed
Show fixed
Hide fixed
@tamasvajk : I Discovered a difference in the file enumeration (which can be contributed to your tireless effort of making proper integration test coverage - otherwise it would definitely have been missed): It turns out that when using enumeration options to enumerate files with the |
With this change we might be able to collapse |
Hmm, interesting finding. For the time being, I wouldn't change this. My fear is that it might have significant impact on the file operations that we do. For example, reading all the files in the |
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 good. I've added some minor comments.
/// Used to represent a path to an assembly or a directory containing assemblies | ||
/// and a selector function to determine which files to include, when indexing the assemblies. | ||
/// </summary> | ||
internal sealed class AssemblyLookupLocation(string p, Func<string, bool> includeFileName, bool indexSubdirectories = true) |
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.
Nit: Maybe use path
instead of p
.
/// and adds them to the a list of assembly names to index. | ||
/// Indexing is performed at a later stage. This only collects the names. | ||
/// </summary> | ||
/// <param name="dir">The directory to index.</param> |
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.
The parameters have diverged from the comment.
@@ -0,0 +1,5 @@ | |||
{ |
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.
This file is probably not needed for this test.
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.
LGTM
In this PR we
AssemblyPath
for paths to assemblies (or folders containing assemblies) and make it possible to add a filter function for relevant filenames on the path.Semmle.*
dlls from being included in the dependencies.