Multi Root Workspace Support

[ozyman42]

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.2)

Product Information:
 Version:            2.0.2
 Commit SHA-1 hash:  a04b4bf512

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

VS Code version: 1.18.1 C# Extension version: 1.13.1

Steps to reproduce

In open project, right-click open folder. Click add folder to workspace, then select a different C# project.

Expected behavior

Both folders will show intellisense, reference counters, have working goto definition, etc.

Actual behavior

The extension only seems to work with the first folder/project in the workspace. All other folders/projects have no reference counter, cannot detect code errors, and when clicking goto definition, it prompts that no definition was found.

[ozyman42]

Related: https://github.com/OmniSharp/omnisharp-vscode/issues/1762 https://github.com/OmniSharp/omnisharp-roslyn/issues/909

[DustinCampbell]

Hi @AlexLeung, you can click the project selector at the bottom-right of the status bar in VS Code to pick a different project to launch OmniSharp on.

The project picker already has Multi-Root Workspace support.

We're using https://github.com/OmniSharp/omnisharp-roslyn/issues/909 to track future improvements to allow OmniSharp itself to discover projects in more than one root folder.

[ozyman42]

Nice! I didn't see that. Thank you!

[janaka]

@DustinCampbell will the same (OmniSharp/omnisharp-roslyn#909) apply where there are multiple solution files (*.sln)?

And where can I track progress to release? it's not too clear in that above issues.

[alx-andru]

Is there an update or a workaround to this?

[akotranza]

@DustinCampbell Thanks for the explanation here and in #904. We have csprojs only built by CI which are under the root but not included in the root sln (this logic may be questionable)... but finally I can explain why intellisense never worked in these, and better yet get it working by opening vscode from within that project's folder 👍

[DustinCampbell]

@janaka : Not exactly. OmniSharp won't attempt to load multiple solution files. If you want to load a particular solution, you should use the status bar selector as I mentioned above.

[janaka]

@DustinCampbell ah ok. Our issue is that the current logic picks the first in alphabetical order when opening a folder with multiple *.sln files. Which typically isn't what we want to be the default hence causes intellisense to not work and causes confusion. Would a legit solution be to make the default solution configurable and check that into the repo? Wasn't sure if that's an anti-pattern. I can create a PR.

[DustinCampbell]

I don't think that'd be an anti-pattern. However, we do remember the last selected solution. So, you should only see this the first time you open that particular solution.

[janaka]

@DustinCampbell FYI submitted PR #2053 as a solution for that ^ (just to close the loop here).

[TheAifam5]

I had previously SLN file in my root directory, after changing to the VSCode workspaces - the sln file is useless :/ Maybe some integration with that behaviour? :)

[DustinCampbell]

@TheAifam5: How is it useless? Does it appear in the solution/file picker when you click the OmniSharp folder icon on the status bar?

[TheAifam5]

@DustinCampbell for example when the project structure looks like this:

• ProjectName.Api
• ProjectName.Api.Core
• ProjectName.Api.Repositories
• ProjectName.Auth
• ProjectName.Auth.Core
• ProjectName.Auth.Repositories
• etc..
• ProjectName.sln
• ProjectName.code-workspace

ProjectName.code-workspace content:

{
  "folders": [
    {
      "path": "ProjectName.Api",
      "name": "ProjectName (API)"
    },
    {
      "path": "ProjectName.Api.Core",
      "name": "ProjectName (API) Core"
    },
    {
      "path": "ProjectName.Api.Repositories",
      "name": "ProjectName (API) Repositories"
    },
   {
      "path": "ProjectName.Auth",
      "name": "ProjectName (Auth)"
    },
    {
      "path": "ProjectName.Auth.Core",
      "name": "ProjectName (Auth) Core"
    },
    {
      "path": "ProjectName.Auth.Repositories",
      "name": "ProjectName (Auth) Repositories"
    },
  ]

When the VSCode is in workspace view, OmniSharp does not see this "ProjectName.sln" solution. Sees only the projects which I have defined inside of "ProjectName.code-workspace".

The "ProjectName.Api" and "ProjectName.Auth" are dotnet core applications, other projects are just libraries. When the "ProjectName.Api" is selected from the status bar, there is no auto-completion inside other application project "ProjectName.Auth", but only there where the libraries are shared.

Regards, TheAifam5

[nelsonmorais]

@DustinCampbell Same issue here as described by @TheAifam5. Maybe if/when VSCode workspaces support adding single files to a workspace this problem can be properly addressed, because as of today, working with multiple projects and workspaces in VSCode is not the best experience.

[rchande]

https://github.com/OmniSharp/omnisharp-vscode/issues/2853

[swaner]

Just a note for other developers that cannot find the project picker in the statusbar. Just hit cmd + shift + p , search for "OmniSharp: Select Project".

For me nothing happened when clicking OmniSharp icon, maybe due too later version (1.17.1)?

[RichardD012]

In response to @swaner above, I have 4 projects in a folder: 3 .net core web apps and 1 .net core library. The 3 web projects reference the library in their .csproj and the code-workspace has both the library the and root of the web projects as being in the workspace.

2 of the web apps switch projects completely fine (either select project or clicking the project in the bottom left of code). However one of them defaults to opening the library and clicking the project name or typing select project only shows the library.

If I rapidly click the project name the other project will eventually show up. I'm not sure what is causing this one project but it has essentially the exact same structure as the other ones and nothing is remarkable. Something seems introduced in the last week or so with the project discovery that is causing problems for this one particular project.

[Dzivo]

It doesnt even find project in the root -.-

[TomasHubelbauer]

FYI with a setup like this:

mkdir demo1
dotnet new console
cd ..
mkdir demo2
dotnet new console

When using OmniSharp through VS Code, it will not find two different projects, instead it will consider both projects as one for some reason.

In my scenario I want OmniSharp to realize I have two different and distinct solutions when I run the above which I am not sure is possible without dotnet new sln in both projects.

[jsancho]

@DustinCampbell for example when the project structure looks like this:

• ProjectName.Api
• ProjectName.Api.Core
• ProjectName.Api.Repositories
• ProjectName.Auth
• ProjectName.Auth.Core
• ProjectName.Auth.Repositories
• etc..
• ProjectName.sln
• ProjectName.code-workspace

ProjectName.code-workspace content:

{
  "folders": [
    {
      "path": "ProjectName.Api",
      "name": "ProjectName (API)"
    },
    {
      "path": "ProjectName.Api.Core",
      "name": "ProjectName (API) Core"
    },
    {
      "path": "ProjectName.Api.Repositories",
      "name": "ProjectName (API) Repositories"
    },
   {
      "path": "ProjectName.Auth",
      "name": "ProjectName (Auth)"
    },
    {
      "path": "ProjectName.Auth.Core",
      "name": "ProjectName (Auth) Core"
    },
    {
      "path": "ProjectName.Auth.Repositories",
      "name": "ProjectName (Auth) Repositories"
    },
  ]

When the VSCode is in workspace view, OmniSharp does not see this "ProjectName.sln" solution. Sees only the projects which I have defined inside of "ProjectName.code-workspace".

The "ProjectName.Api" and "ProjectName.Auth" are dotnet core applications, other projects are just libraries. When the "ProjectName.Api" is selected from the status bar, there is no auto-completion inside other application project "ProjectName.Auth", but only there where the libraries are shared.

Regards, TheAifam5

I do have this exact same problem. Only with many more projects and it's rather awkward to have to change the selected project whenever I'm alternating files across projects.

Does anyone know of any workaround for the time being?

I've tried adding the solution file as a "project" to the workspace, but that breaks the omnisharp project picker.

[mdschweda]

I would be OK with something like this:

{
  "folders": [
    {
      "path": "MyLibrary",
      "name": "🧩 MyLibrary"
    },
    {
      "path": "MyLibrary.Test",
      "name": "🧪 MyLibrary.Test"
    }
  ],
  "settings": {
    "omnisharp.projects": [
       "MyLibrary.sln"
    ]
  }
}

[jsancho]

@mdschweda that's worked! Incredible, I've had this failing to work for months. Immensely grateful for this tip! :)

[jsancho]

Right, sadly I did say that a bit too soon.

The references between methods started to get picked up across some projects, and that's nice. But it's largely not working, there are no suggestions for adding using statements and renaming doesn't even work within 1 file let alone across them. The problems panel shows nothing at all when the build breaks at compile time.

Played a bit with the "select project" explicitly, restarting omnisharp and some additional settings like enableRoslynAnalyzers, but not managed much at all

Downloading VS for Mac, as I have a big refactor to do and VS Code is not really usable for this. Once done with the refactor, VS Code can be handy for edits that are more within one project.

[mdschweda]

Sorry for the misunderstanding. That was not supposed to be a working solution but rather a suggestion for how this problem may be tackled. If we were allowed to specify the list of projects and solutions manually, we would not have to rely on Omnisharp's discovery mechanism.

[TaylorWatson]

It's odd this keeps getting pushed aside. I think the first thread dates to early 2017 with this one November.

It makes workspaces completely unusable and just leads to you have 3-5 vs code windows open or simply using vs mac or parallels.

I'm really confused about why this can't be solved by letting us specify the projects manually even in the settings or like commented above the sln file. Perhaps someone more knowledgable can share if this is a feature we should ever expect or should we move onto something else.

Hopefully, it's something that can be addressed 😄

[NathanielRN]

I also wanted to mention that I've noticed this is a problem. However, it many not be something to do with OmniSpaces? When I have a workspace with only 2 different python directories the Microsoft Python extension also fails to get the "Go to Definition" feature working. Maybe this is a VSCode issue instead.

[JeremyCaron]

PLEASE prioritize fixing this.

[emouawad]

+1

[ChrisProlls]

+1

[frankiee12a9]

From this thread till now this issue has still not been resolved!

[mdschweda]

Here is a stupid workaround i figured out: workaround.zip

📂 Build
   📂 .vscode
      📄 launch.json
      📄 tasks.json
   📄 Solution.sln
📂 ProjectA
   📄 ProjectA.csproj
📂 ProjectB
   📄 ProjectB.csproj
📄 workspace.code-workspace

workspace.code-workspace:

{
  "folders": [
    {
      "path": "./Build",
      "name": "Build"
    },
    {
      "path": "./ProjectA",
      "name": "🅰 Project A"
    },
    {
      "path": "./ProjectB",
      "name": "🅱 Project B"
    }
  ]
}

Solution.sln:

...
Project("...") = "ProjectA", "..\ProjectA\ProjectA.csproj", "..."
EndProject
Project("...") = "ProjectB", "..\ProjectB\ProjectB.csproj", "..."
EndProject
...

tasks.json

// ...
{
  "label": "🔨 Build 🅰",
  "command": "dotnet",
  "type": "process",
  "args": [ "build", "../ProjectA/ProjectA.csproj" ],
  "problemMatcher": "$msCompile"
}
// ...

launch.json

// ...
{
  "name": "Launch 🅰",
  "type": "coreclr",
  "request": "launch",
  "preLaunchTask": "🔨 Build 🅰",
  // Use *exactly* this combination:
  "cwd": "${workspaceFolder}/../ProjectA",
  "program": "bin/Debug/net5.0/ProjectA.dll",
  // ...
}
// ...

[lariamato]

How many more years will this require to be fixed?

[CEbbinghaus]

This is something I am really struggling with for work. We have 20+ projects in 5 different solutions. Omnisharp likes loading a random csproj and goes from there loading 2-3 of the projects at most. I would Ideally be able to specify all csproj files that should be loaded in the settings.json

[JoeRobich]

@CEbbinghaus If the projects you need are all part of a solution, you can use the project selector to open the solution. You can run the command "OmniSharp: Select Project" to bring up the project selector.

[CEbbinghaus]

the projects you need are all part of a solution, you can use the project selector to open the solution.

Ideally, I would like to be able to work on all of the projects at once which are spread across 5 different solutions. I guess I could create another solution that includes every project from every other solution but that seems a little overkill. However, it might solve the problem.

[SomeoneIsWorking]

I initially thought since I have multiple workspace folders, OmniSharp would just run independently in separate instances. Even if you have a single sln, this extension can only create a launch entry for a single project at a time which is absurd since there is usually a stack such as API and App in separate projects.

[CEbbinghaus]

I guess I could create another solution that includes every project from every other solution but that seems a little overkill. However, it might solve the problem.

This is how I ended up getting it working. For anyone else interested, putting all needed projects into a single solution with dotnet sln loads them all for intellisense and is therefore a decent workaround to anyone facing this issue. Of course this also means that if projects are added or removed they also have to be added and removed from the solution which can be a hassle at times. Really hoping this gets implemented soon though since it's such a basic feature that so many other languages have already

[einord]

Still waiting here...

For me this is the number one most irritating thing when working with vscode. I usually have a workspace with multiple projects (such as multiple function apps or front- and backend).

Though I am starting to get quite handy with the Cmd + Shift + P > Omnisharp: Select project nowadays...

[PAHeartBeat]

+1 Still Waiting... Please prioritize this issue/feature.

It's even become worst when you have to find the link/source of the member from which the project or solution is loaded. It's sometimes very frustrating when you have more projects like 10+ and you can't get intelligent or Go To definition or Go To Implementation.

it's become worst if you open the project after a couple of months for some fixes or new features. you might not know the exact signature of the member or constructor of the class. and you have to go through multiple files based on what project reference you have in your csproj file.

I have 35 projects in my workspace. when I was finding the solution for this in some StackOverflow blog I read a developer has around 168 projects in the workspace. I can't imagine what level of frustration he will get in this case scenario.

To overcome this issue right now I am using a setting from OmniSharp as below.

"omnisharp.enableMsBuildLoadProjectsOnDemand": true

with this setting Omnisharp does the trick when you open a file from any project. OmniSharp will load that project including the project which is referenced in csproj file and run analysis one by one on all projects from the project reference group.

Environment Info VS Code: v1.74.3 OS: Windows 11 OmniSharp: v1.25.4 (C# Extension)

Dotnet Info

.NET SDK:
 Version:   7.0.102
 Commit:    4bbdd14480

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

Host:
  Version:      7.0.2
  Architecture: x64
  Commit:       d037e070eb

.NET SDKs installed:
  3.1.300 [C:\Program Files\dotnet\sdk]
  6.0.308 [C:\Program Files\dotnet\sdk]
  7.0.101 [C:\Program Files\dotnet\sdk]
  7.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not Found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[FinalFortune]

Came to see if there is perhaps a possibility of an improvement in performing this feature, seems not. As a work around I use Nuke to build me a super solution then use vscode to load it.

[xPathin]

This is one of the most annoying issues there is and people are waiting since 2017. Any hope this will get fixed one day?

[kupiakos]

Could this be moved to the Backlog instead of a closed release?