Omnisharp-vscode: Project Selector (OmniSharp: Select Project) missing .sln files

[Rubiss]

Issue Description

Not all of the .sln files in the workspace directory are available for selection in the project selector. The proper .sln cannot be selected resulting in "no definition found" messages when attempting to go to definition.

Steps to Reproduce

Open a directory with VSCode that contains 236 .sln files in various nested directories > Navigate to a file 6 folders deep (methods definition results in no definition found) > click the project selector in the status bar > "select 1 of 104" projects is displayed > the .sln (one folder level up from the file) does not display in the list of options.
Note that opening the 4th nested directory with VSCode allows the correct .sln to display in the dropdown, be selected, and properly go to definition.

Expected Behavior

All .sln files are available for selection in the project selector.

Actual Behavior

.sln files are missing from the project selector.

Environment information

VSCode version: 1.36.1
C# Extension: 1.20.0

Dotnet Information

.NET Core SDK (reflecting any global.json):
Version: 2.2.301
Commit: 70d6be0814

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:Program Files\dotnet\sdk\2.2.301\

Host (useful for support):
Version: 2.2.6
Commit: 7dac9b1b51

.NET Core SDKs installed:
1.0.4 [C:Program Files\dotnet\sdk]
2.1.101 [C:Program Files\dotnet\sdk]
2.1.201 [C:Program Files\dotnet\sdk]
2.1.202 [C:Program Files\dotnet\sdk]
2.1.302 [C:Program Files\dotnet\sdk]
2.1.505 [C:Program Files\dotnet\sdk]
2.1.602 [C:Program Files\dotnet\sdk]
2.2.301 [C:Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.9 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.6 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.9 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.6 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.5 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.9 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.6 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

|Extension|Author|Version|
|---|---|---|
|csharp|ms-vscode|1.20.0|;

[rchande]

@Rubiss It sounds like our project selection UI doesn't really scale to this level. I can't imagine that trying to select between ~100 items in that dialog is pleasant. Do you think the option "omnisharp.defaultLaunchSolution": null, would work better for you?

[Rubiss]

@rchande Unfortunately setting omnisharp.defaultLaunchSolution to the solution not showing in the projects dialog still does not allow it to load as the default. The dialog isn't that bad if you know what you are looking for :) Anyways, I can understand how it might not scale for this many solutions in nested directories. Thanks for looking into it.

[rchande]

@Rubiss Ok, so it sounds like this might be a bug in the sln discovery code. Can you describe more specifically what the directory structure looks like for a .sln file that isn't showing up?

[Rubiss]

@rchande Please find the attached directory structure image to a .sln that doesn't show.

I have removed file and folder names for safety

[modavi]

I recently ran into a similar issue with just two projects. The issue lies in findLaunchTargets

export async function findLaunchTargets(options: Options): Promise<LaunchTarget[]> {
    if (!vscode.workspace.workspaceFolders) {
        return Promise.resolve([]);
    }

    const projectFiles = await vscode.workspace.findFiles(
        /*include*/ '{**/*.sln,**/*.csproj,**/project.json,**/*.csx,**/*.cake}',
        /*exclude*/ '{**/node_modules/**,**/.git/**,**/bower_components/**}',
        /*maxResults*/ options.maxProjectResults);

    const csFiles = await vscode.workspace.findFiles(
        /*include*/ '{**/*.cs}',
        /*exclude*/ '{**/node_modules/**,**/.git/**,**/bower_components/**}',
        /*maxResults*/ options.maxProjectResults);

    return resourcesToLaunchTargets(projectFiles.concat(csFiles));
}

It finds all the cs files in your workspace, but will place a limit of options.maxProjectResults on the number of cs files it can detect (in resourcesToLaunchTargets it will distill this list of all cs files down into a single launch target which I believe is what maxProjectResults should actually be limiting).

It will then parse out a list of projects from these files. Unfortunately if the first project in your workspace has more than 250 cs files in it then it will simply ignore the next workspace folder and you will not be able to select it as the OmniSharp target project.

A workaround I was able to use was to set "omnisharp.maxProjectResults" to a large number, and it started allowing me to select both of my projects again.

[Rubiss]

Thank you @modavi. I have confirmed that increasing the value of "omnisharp.maxProjectResults" resolves the issue for me as well. I agree with your observations, that configuration seems misused as a limiter for cs file results. The usage does not align with the description of the configuration.

The maximum number of projects to be shown in the 'Select Project' dropdown (maximum 250).

[aaron-tyler-ds]

Thanks for the workaround! This issue also impacts our large codebase - the majority of our sln files can't be opened by default as they're not found due this issue.