Multi Root Workspace Support #1889
Comments
|
Related: |
|
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 OmniSharp/omnisharp-roslyn#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.code-workspace content: 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. Regards, |
|
@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. |
|
Just a note for other developers that cannot find the project picker in the statusbar. For me nothing happened when clicking OmniSharp icon, maybe due too later version (1.17.1)? |
|
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. Played a bit with the "select project" explicitly, restarting omnisharp and some additional settings like Downloading VS for Mac, as I have a big refactor to do and VS Code is not really usable for this. |
|
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! |
|
Here is a stupid workaround i figured out: 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",
// ...
}
// ... |
|
How many more years will this require to be fixed? |
|
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 |
|
@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. |
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. |
|
I initially thought since I have multiple workspace folders, OmniSharp would just run independently in separate instances. |
This is how I ended up getting it working. For anyone else interested, putting all needed projects into a single solution with |
|
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... |
|
+1 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 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. 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 Dotnet Info |
|
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. |
|
This is one of the most annoying issues there is and people are waiting since 2017. Any hope this will get fixed one day? |
|
Could this be moved to the Backlog instead of a closed release? |
|
Utterly embarrassing, absolutely ridiculous, and unacceptably absurd that there still hasn't been any updates on this in 2024. |
and others
Environment data
dotnet --infooutput: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.
The text was updated successfully, but these errors were encountered: