vscode-csharp
vscode-csharp copied to clipboard
Multi Root Workspace Support
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.
Related: https://github.com/OmniSharp/omnisharp-vscode/issues/1762 https://github.com/OmniSharp/omnisharp-roslyn/issues/909
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.
Nice! I didn't see that. Thank you!
@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.
Is there an update or a workaround to this?
@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 👍
@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.
@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.
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.
@DustinCampbell FYI submitted PR #2053 as a solution for that ^ (just to close the loop here).
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? :)
@TheAifam5: How is it useless? Does it appear in the solution/file picker when you click the OmniSharp folder icon on the status bar?
@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
@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.
https://github.com/OmniSharp/omnisharp-vscode/issues/2853
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)?
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.
It doesnt even find project in the root -.-
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.
@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.
I would be OK with something like this:
{
"folders": [
{
"path": "MyLibrary",
"name": "🧩 MyLibrary"
},
{
"path": "MyLibrary.Test",
"name": "🧪 MyLibrary.Test"
}
],
"settings": {
"omnisharp.projects": [
"MyLibrary.sln"
]
}
}
@mdschweda that's worked! Incredible, I've had this failing to work for months. Immensely grateful for this tip! :)
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.
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.
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 😄
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.
PLEASE prioritize fixing this.
+1
+1
From this thread till now this issue has still not been resolved!