-
Notifications
You must be signed in to change notification settings - Fork 19
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 doesn't work with mono 4.8 #439
Comments
cc @AndrienkoAleksandr : this is the issue I've told you about, with more details. Feel free to ask for more if it can help. I'll try with mono 5.2 soon and report whether this fix the issue. |
I just tried again with the LS from master (which includes 12cf220 ).
The LS is working fine for projects which have a |
@mickaelistria Did you generate project with help dotnet 2.0? Because for me this commit activated inside Eclipse CHE correct autocomplete, hover, for dotnet projects generated with help dotnet 2.0 (I don't use project generated with help 1.0.4). |
Project is generated with |
Unfortunately, in order to support .NET Core 2.0, OmniSharp needs to take advantage of the new "--assembly-loader" flag in Mono 5.2. This is, due to internal API changes in the latest .NET Core 2.0 SDK. There are several issues with details. Here's one where the problem is discussed at length: dotnet/vscode-csharp#1495 |
Thanks @DustinCampbell . Is there an easy way to check for mono version (maybe you're already aware of some dependency that can do it) and to decide whether to set the flag according to it? |
In Node? I'd probably just regex out the version number from Note that without the flag, using the latest .NET Core 2.0 SDK will still fail on old versions of Mono. |
Note that without the flag, using the latest .NET Core 2.0 SDK will still
fail on old versions of Mono.
Right. However we can imagine the users who have an old version of mono may
remain on this older versions, whereas people doing .NET Core 2.0 are more
likely to have the new version.
So shipping a language server that's compatible with .NET Core 1.0 at
least, and optionally compatible with .NET Core 2.0 if user has a .NET Core
2.0-compatible mono seems like a decent trade-off.
|
Makes sense. One thing to keep in mind is that it isn't about building .NET Core 2.0 apps. The issue is with using the .NET Core 2.0 SDK, which can still be used to build .NET Core 1.1 apps. |
#441 helps as it removes the dependency on mono and then make the setup more portable.
I confirm it's using the omnisharp-linux-x64 server with the embedded mono. As I'm not a .NET expert, I'm failing at interpreting that message. |
You might try updating the .NET Core 2.0 SDK. 2.0.0-preview2-006497 is pretty old and there were definitely some issues with MSBuild task dependencies in the past. You should be able to get the latest here: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.0.0/dotnet-sdk-latest-linux-x64.tar.gz. |
Note: I listed the tarball because, IIRC, you're on Fedora 26. |
@DustinCampbell thanks. |
The latest RPM for RHEL is here: https://github.com/dotnet/cli/tree/release/2.0.0. |
On Tue, Aug 8, 2017 at 3:18 PM, Dustin Campbell ***@***.***> wrote:
The latest RPM for RHEL is here: https://github.com/dotnet/cli/
tree/release/2.0.0
Thanks, but IIRC, those are not compatible with recent Fedora because of
issue with icu: https://github.com/dotnet/cli/issues/4865 (and some other
ones)
|
Preview 2 should be here: https://copr.fedorainfracloud.org/coprs/g/dotnet-sig/dotnet/. We dont have anything newer (yet). |
@mickaelistria: If you could try the tarball to verify whether that solves the issue or not would be helpful. |
Thanks guys. I'll try the tarball promptly (today or tomorrow) and report
back whether it works. If you didn't hear from me by then, feel free to
ping me.
|
So the server works for project using a |
Actually, the error is different now
I guess I didn't install .NET Core properly so some binaries can't be resolved. |
awesome! That's what I was hoping for. 😄 This is a regression that I noticed earlier today. I've already merged a fix and produced a new 1.23.1 release of omnisharp-roslyn. I'm guessing omnisharp-node-client needs updated @david-driscoll? |
Hurray! I tried the latest release v7.1.2 which uses omnisharp-roslyn 1.23.1 and it worked well on Fedora 26 with a version recent of dotnet-core 2.0 and no dependency on mono! |
Great! |
A recent change to better support mono 5.2 ( 12cf220 ) seems to break support for mono 4.8.
Most operations either timeout or return empty results when something is expected
Here are some of the 1st few messages received from LS after an initialize request as example
My setup:
The text was updated successfully, but these errors were encountered: