Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server is not started with solution file and instead looks in current working directory for solution #473

Open
Ruin0x11 opened this issue Mar 26, 2019 · 15 comments · Fixed by #476
Labels

Comments

@Ruin0x11
Copy link

When starting the server with a sln file, the solution will not be opened unless omnisharp-start-omnisharp-server is run with the working directory the same as the directory containing the sln.

Here is an example if the solution were d:/build/project/project.sln and the current window when running omnisharp-start-omnisharp-server has a buffer for d:/build/project/subfolder/file.cs.

[11:10:13] starting server using project folder/solution path "d:/build/project/project.sln"
[11:10:13] Using server binary on c:/users/iapicker/.emacs.d/.cache/omnisharp/server/v1.32.11/OmniSharp.exe
[11:10:14] INFORMATION: OmniSharp.Stdio.Host, Starting OmniSharp on Windows 6.2.9200.0 (x64)
[11:10:14] INFORMATION: OmniSharp.Services.DotNetCliService, DotNetPath set to dotnet
[11:10:14] INFORMATION: OmniSharp.MSBuild.Discovery.MSBuildLocator, Located 3 MSBuild instance(s)

            1: DeveloperConsole 15.6.7 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"

            2: Visual Studio Enterprise 2017 15.9.28307.518 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"

            3: StandAlone 15.0 - "c:\users\iapicker\.emacs.d\.cache\omnisharp\server\v1.32.11\msbuild\15.0\Bin"
[11:10:14] INFORMATION: OmniSharp.MSBuild.Discovery.MSBuildLocator, Registered MSBuild instance: DeveloperConsole 15.6.7 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"
[11:10:15] INFORMATION: OmniSharp.Cake.CakeProjectSystem, Detecting Cake files in 'd:\build\project\subfolder'.
[11:10:15] INFORMATION: OmniSharp.Cake.CakeProjectSystem, Could not find any Cake files
[11:10:15] INFORMATION: OmniSharp.WorkspaceInitializer, Project system 'OmniSharp.DotNet.DotNetProjectSystem' is disabled in the configuration.
[11:10:15] INFORMATION: OmniSharp.MSBuild.ProjectSystem, No solution files found in 'd:\build\project\subfolder'
[11:10:15] INFORMATION: OmniSharp.Script.ScriptProjectSystem, Detecting CSX files in 'd:\build\project\subfolder'.
[11:10:15] INFORMATION: OmniSharp.Script.ScriptProjectSystem, Could not find any CSX files
[11:10:15] INFORMATION: OmniSharp.WorkspaceInitializer, Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[11:10:15] INFORMATION: OmniSharp.WorkspaceInitializer, Configuration finished.
[11:10:15] INFORMATION: OmniSharp.Stdio.Host, Omnisharp server running using Stdio at location 'd:\build\project\subfolder' on host -1.

Server version is v1.32.11. omnisharp-emacs version is 20190228.622.

@razzmatazz
Copy link
Contributor

Hi @Ruin0x11 . I have noticed it myself. We probably need to get rid of sln file selector when starting up and just use projectile/git root to set cwd for the server.

Thats what VS Code does, for example.
I don't have that much spare time lately, but will try to hack something. There are other bugs with later server versions as well, for example "duplicate type" issue #464

@razzmatazz
Copy link
Contributor

@Ruin0x11, could you check if the latest version (due to be released in MELPA in a couple of hours) fixes the issue?

I have changed omnisharp-emacs code so it does not ask for solution file anymore and will use the directory provided by projectile-root -- which is usually your SCM/git root.

@Ruin0x11
Copy link
Author

Ruin0x11 commented Apr 23, 2019

I just updated and now I'm getting errors about unloaded projects. I had to change some things as the source is confidential, but the overall root project directory is d:\project, the subproject with files I want to work on is d:\project\subproject\subproject.csproj, and the project's solution contains other csproj files in other subdirectories. After waiting for the server to finish loading I tried finding references of an identifier inside subproject and found no results except the definition I started the search on, where there should have been some found before.

Usually when I loaded the project before I would directly load d:\project\subproject\subproject.csproj with no issues (if in a buffer visiting d:\project\subproject). The current loader loads d:\project instead.

Also I tried running the server with a buffer visiting the project root and there was no difference.

Also, the project root that omnisharp chose did not contain any sln or csproj files, but in the actual source repo a sln file was contained in the parent directory of the chosen project root, and a csproj was in at least one child directory.

[19:27:52] starting server on project root "d:/project"
[19:27:52] Using server binary on c:/users/iapicker/.emacs.d/.cache/omnisharp/server/v1.32.11/OmniSharp.exe
[19:27:55] INFORMATION: OmniSharp.Stdio.Host, Starting OmniSharp on Windows 6.2.9200.0 (x64)
[19:27:55] INFORMATION: OmniSharp.Services.DotNetCliService, DotNetPath set to dotnet
[19:27:55] INFORMATION: OmniSharp.MSBuild.Discovery.MSBuildLocator, Located 3 MSBuild instance(s)

            1: DeveloperConsole 15.6.7 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"

            2: Visual Studio Enterprise 2017 15.9.28307.518 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"

            3: StandAlone 15.0 - "c:\users\iapicker\.emacs.d\.cache\omnisharp\server\v1.32.11\msbuild\15.0\Bin"
[19:27:55] INFORMATION: OmniSharp.MSBuild.Discovery.MSBuildLocator, Registered MSBuild instance: DeveloperConsole 15.6.7 - "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"
[19:27:57] INFORMATION: OmniSharp.Cake.CakeProjectSystem, Detecting Cake files in 'd:\project'.
[19:27:58] INFORMATION: OmniSharp.Cake.CakeProjectSystem, Could not find any Cake files
[19:27:58] INFORMATION: OmniSharp.WorkspaceInitializer, Project system 'OmniSharp.DotNet.DotNetProjectSystem' is disabled in the configuration.
[19:27:58] INFORMATION: OmniSharp.MSBuild.ProjectSystem, No solution files found in 'd:\project'
[19:27:58] INFORMATION: OmniSharp.MSBuild.ProjectManager, Queue project update for 'd:\project\subproject\subproject.csproj'
[19:27:58] INFORMATION: OmniSharp.Script.ScriptProjectSystem, Detecting CSX files in 'd:\project'.
[19:27:58] INFORMATION: OmniSharp.Script.ScriptProjectSystem, Could not find any CSX files
[19:27:58] INFORMATION: OmniSharp.WorkspaceInitializer, Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[19:27:58] INFORMATION: OmniSharp.MSBuild.ProjectManager, Loading project: d:\project\subproject\subproject.csproj
[19:27:58] INFORMATION: OmniSharp.WorkspaceInitializer, Configuration finished.
[19:27:58] INFORMATION: OmniSharp.Stdio.Host, Omnisharp server running using Stdio at location 'd:\project' on host -1.
[19:28:01] INFORMATION: OmniSharp.MSBuild.ProjectManager, Adding project 'd:\project\other_subproject\other_subproject.csproj'

<...>

[19:28:02] INFORMATION: OmniSharp.MSBuild.ProjectManager, Loading project: d:\project\other_subproject\other_subproject.csproj
[19:28:02] WARNING: OmniSharp.MSBuild.ProjectManager, Failed to load project file 'd:\project\other_subproject\other_subproject.csproj'.
[19:28:02] ERROR: OmniSharp.MSBuild.ProjectManager, Attempted to update project that is not loaded: d:\project\other_subproject\other_subproject.csproj
[19:28:02] ERROR: OmniSharp.MSBuild.ProjectManager, Attempted to update project that is not loaded: d:\project\another_subproject\another_subproject.csproj

<...>

[19:28:08] INFORMATION: OmniSharp.OmniSharpWorkspace, Miscellaneous file: d:\project\subproject\File.cs added to workspace

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 23, 2019

@Ruin0x11 I see you have omnisharp-expected-server-version set to 1.32.11 -- the latest/default one is 1.32.18 -- can you check if reseting that variable to default value (and installing the corresponding server version) fixes things for you?

If I understand correctly, the latest omnisharp-roslyn server versions do not require .sln file to be present and it probably ignores them.

@Ruin0x11
Copy link
Author

After upgrading, there is no noticeable difference in the log output. Finding references still doesn't work either.

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 24, 2019

It seems omnisharp-roslyn server is not able to load your project(s). This is most probably a server issue since it appears that .csproj files are discovered but not loaded.

What kind of framework/runtime/sdk do you use for your projects? Is it .net framework 4.x or .net core, or Unity? If all else fails you may want to register an issue with https://github.com/OmniSharp/omnisharp-roslyn team–they maintain the actual omnisharp-roslyn server which omnisharp-emacs uses.

@Ruin0x11
Copy link
Author

Strangely I could load the same project with no issues using the previous version of omnisharp-emacs and omnisharp-roslyn v1.32.11, so long as I picked the correct solution file from the popup. But now that you can't select it anymore it seems like omnisharp-emacs always picks the incorrect one. I think that "incorrect working directory being set" and "the need to manually select a project file" are two separate issues. Even with the working directory issue, so long as I did the workaround of selecting a buffer in the same working directory as the project I chose, I could still load the project fine. That isn't the case anymore with the most recent changes, as far as I can tell.

The projects use net452 as a version identifier. The dependency framework we use is internal to our organization and part of a very large monorepo (nothing to do with NuGet/VS), but so long as the repo's environment is initialized the solutions are openable with Visual Studio, and I was previously also able to open them with omnisharp without any major issues.

@sebasmonia
Copy link

I'm having the same problem, I have a ProjectName repo with several solutions. Each one lives in their own sub directory.
C:\Repos\ProjectName contains C:\Repos\ProjectName\ModuleA\ModuleA.sln and C:\Repos\ProjectName\ModuleB\ModuleB.sln both with projects under them.

After the last update my setup is a no-go apparently.

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 25, 2019

@sebasmonia @Ruin0x11

M-x omnisharp-start-omnisharp-server supports the universal parameter whereas hitting:

  • C-u M-x omnisharp-start-omnisharp-server would ask for a root directory for cwd where the server should start. Maybe selecting a subdirectory with a particular solution helps?

Otherwise I will need to check what has changed in recent omnisharp-roslyn versions..

Could any of you check how VSCode behaves in your case? As it uses the same omnisharp-roslyn server underneath.

@sebasmonia
Copy link

Using prefix arg to select the directory didn't work :(

I don't have VS Code, if not using Emacs I go full VS201X.

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 25, 2019 via email

@sebasmonia
Copy link

Updated to the latest server and now it works! Which makes me think it's time to bump the minimum server version :)

thanks for helping us getting this figured out!

@Ruin0x11 grab the latest server from here: https://github.com/OmniSharp/omnisharp-roslyn/releases

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 25, 2019

@sebasmonia Thats great! Btw, you are using the manually-downloaded-server setup, right? Otherwise omnisharp-expected-server-version variable should have triggerred omnisharp-start-omnisharp-server to ask you to install an updated version automatically. Unless you have omnisharp-expected-server-version overriden to in your .emacs.d/init.el

@sebasmonia
Copy link

sebasmonia commented Apr 25, 2019 via email

@Ruin0x11
Copy link
Author

I reinstalled the server with the latest version and things seem to work now, but only if I manually specify the working directory of the project every time. I think this should at least be the default for solutions with subprojects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants