Support for `.slnx` Solution Format Not Yet Implemented

[samtrion]

Hello CodeQL team,

I would like to raise awareness that the newer .slnx solution format introduced by Microsoft is currently not supported by the C# extractor in CodeQL.

The following line in the source suggests that only traditional .sln files are recognized:

codeql/csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/FileProvider.cs

Line 40 in d83cbde

solutions = new Lazy<string[]>(() => SelectTextFileNamesByExtension("solution", ".sln"));

As outlined in the official announcement by Microsoft:
https://devblogs.microsoft.com/dotnet/introducing-slnx-support-dotnet-cli/

.slnx files are designed to work seamlessly with the .NET CLI and represent a modern evolution of solution management in .NET ecosystems. As adoption increases, support in CodeQL would ensure compatibility with a broader range of real-world .NET projects.

Is there any plan or roadmap item to add support for .slnx?

[hvitved]

Hi

Thanks for bringing this to our attention; it's not on our roadmap right now, but I'll make sure to add it to our backlog.

[samtrion]

@hvitved
If possible please add .slnf also (https://learn.microsoft.com/en-us/visualstudio/msbuild/solution-filters?view=vs-2022)

[michaelnebel]

@hvitved If possible please add .slnf also (https://learn.microsoft.com/en-us/visualstudio/msbuild/solution-filters?view=vs-2022)

It looks like solution filters are primarily used to only load/build a subset of a solution (e.g. for easy of development). However, I think that even in the presence of a solution filter, the autobuilder should attempt to build the entire solution (and not just the subset mentioned in the filter).
For build-mode: none solution files are primarily used for "bulk" restoring projects (as this is typically faster than restoring the projects individually). In this case, I think we should also use the solution files instead of the filters to restore as much as possible.

Support for .slnx will be introduced here.