Issue with dotnet version 2.1.500 and later

[JulioJu]

Hi !

Today, I've experienced a problem with $ dotnet --version : 2.1.500.

But all works well with $ dotnet --version : 2.1.403, no problems with 2.1.403, only with 2.1.500. Is it normal ?

I've tested on a complete new project, generated thanks
$ dotnet new web && dotnet new sln && dotnet sln add Aspnet.csproj,
and with the following vimrc:

        call plug#begin('~/.vim/plugged')
        Plug 'w0rp/ale'
        Plug 'OmniSharp/omnisharp-vim'
        call plug#end()
        filetype plugin indent on
        let g:OmniSharp_timeout = 5
	let g:OmniSharp_proc_debug = 1
        let g:ale_linters = { 'cs': ['OmniSharp'] }

Thanks command :message in Neovim we have the output:

stdout: OmniSharp.Http.Startup[0]', '      Starting OmniSharp on arch 0.0 (x64)', '']
stdout: OmniSharp.Cake.CakeProjectSystem[0]', '      Detecting Cake files in ''/tmp/Aspnet''.', '']
stdout: OmniSharp.Cake.CakeProjectSystem[0]', '      Could not find any Cake files', '']           
stdout: OmniSharp.Http.Startup[0]', '      Project system ''OmniSharp.DotNet.DotNetProjectSystem'' is disabled in the con
figurat
stdout: OmniSharp.MSBuild.ProjectSystem[0]', '      Detecting projects in ''/tmp/Aspnet/Aspnet.sln''.', '']
stdout: OmniSharp.MSBuild.ProjectManager[0]', '      Queue project update for ''/tmp/Aspnet/Aspnet.csproj''', '']
stdout: OmniSharp.Script.ScriptProjectSystem[0]', '      Detecting CSX files in ''/tmp/Aspnet''.', '']           
stdout: OmniSharp.Script.ScriptProjectSystem[0]', '      Could not find any CSX files', '']           
stdout: OmniSharp.Http.Startup[0]', '      Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWo
rkspace
stdout: OmniSharp.Http.Startup[0]', '      Configuration finished.', '']
stdout: OmniSharp.Http.Startup[0]', '      Omnisharp server running on port ''43887'' at location ''/tmp/Aspnet'' on host
 -1.', 
stdout: OmniSharp.MSBuild.ProjectManager[0]', '      Loading project: /tmp/Aspnet/Aspnet.csproj', '']
stdout:[49m: OmniSharp.MSBuild.ProjectManager[0]', '      Failed to load project file ''/tmp/Aspnet/Aspnet.csproj''.', ''
]
stdout: OmniSharp.MSBuild.ProjectManager[0]', '      Attemped to update project that is not loaded: /tmp/Aspnet/Aspnet.cs
proj', '']

Thanks in advance ;-).

EDIT: see also #437 (comment)

[JulioJu]

Tested again with version 2.1.403, and 2.1.500. Doesn't work with 2.1.500.

I've tested with the new Dotnet version 2.2.100, all work well with this version. [never worked on my computer]

@nickspoons

As the problem seems to be only with version 2.1.500, maybe I could close this issue ?

But, as we see at https://dotnet.microsoft.com/download/dotnet-core/2.1, version 2.1.500 is an LTS version.

[nickspoons]

I'm sorry @JulioJu I haven't found time to investigate. Have you by any chance tried VSCode to see if OmniSharp-roslyn is working with2.1.500?

I think it might be a good idea to leave this issue open for a while and see if it affects anyone else.

[nickspoons]

@JulioJu I can confirm that there appears to be a problem with 2.1.500 - I can load projects created with dotnet 2.1.300 but not 2.1.500

[nickspoons]

@JulioJu unfortunately it's going to be difficult to debug this, since most users (including me and I assume you?) are using an old version of OmniSharp-roslyn, since the Http version which OmniSharp-vim uses is broken after 1.32.1. There are a couple of issues that look related but I can't tell since there have been several changes in OmniSharp-roslyn.

[JulioJu]

@nickspoons
Sorry, I've tested again with version 2.2.100`, and it not works too. (When I've tested before, I've forgotten to change my PATH variable in my zshrc, therefore OmniSharp used the old version 2.1.403 when I launched NeoVim. Therefore version 2.2.100 has never worked on my computer).

I've tried to test with a new version of omnisharp-roslyn compiled by me, as you explained at OmniSharp/omnisharp-roslyn#1274 (comment). But I don't understand how the compiled version should be put in ~/.omnisharp/omnisharp-roslyn. The generated tree is different.

I didin't seen any particular issue published on omnisharp-roslyn or omnisharp-vscode projects about a problem with dotnet v.2.1.500.

Please, could you release your own version of omnisharp-roslyn, compiled on your ArchLinux ?

Thanks a lot in advance :-) !

[axvr]

This all seems very strange to me, because I've been using .NET Core 2.1.500 for quite a while now with no issues at all.

I captured this from my terminal pane, and editing the resulting code in Vim with OmniSharp-vim worked perfectly for me.

[axvr@arctic ~]$ cd Documents/Projects/                                 
[axvr@arctic Projects]$ mkdir Test  
[axvr@arctic Projects]$ cd Test/    
[axvr@arctic Test]$ dotnet --version
2.1.500                             
[axvr@arctic Test]$ dotnet new sln  
The template "Solution File" was created successfully.                  
[axvr@arctic Test]$ dotnet new console                                  
The template "Console Application" was created successfully.            

Processing post-creation actions... 
Running 'dotnet restore' on /home/axvr/Documents/Projects/Test/Test.csproj...                                                                    
  Restoring packages for /home/axvr/Documents/Projects/Test/Test.csproj...                                                                       
  Generating MSBuild file /home/axvr/Documents/Projects/Test/obj/Test.csproj.nuget.g.props.                                                      
  Generating MSBuild file /home/axvr/Documents/Projects/Test/obj/Test.csproj.nuget.g.targets.                                                    
  Restore completed in 139.23 ms for /home/axvr/Documents/Projects/Test/Test.csproj.                                                             

Restore succeeded.                  

[axvr@arctic Test]$ dotnet sln add Test.csproj                          
Project `Test.csproj` added to the solution.                            
[axvr@arctic Test]$ ls              
obj  Program.cs  Test.csproj  Test.sln                                  
[axvr@arctic Test]$

I'm running Fedora Linux 29, however I'm not using the official packages from Microsoft, instead I'm using these builds https://copr.fedorainfracloud.org/coprs/g/dotnet-sig/dotnet/.

[nickspoons]

Yes, it's confusing and upsetting 😢

I just tried that build I compiled when I commented on omnisharp-roslyn#1202 and it works fine with dotnet 2.1.500

I'm not really sure about making a release - I can wrap up what I have into a tarball but it's better if you can build it yourself @JulioJu - this one is already quite out of date. To use it, I added these to my .vimrc:

let g:OmniSharp_server_path = '/home/nickspoon/tools/omnisharp-roslyn/bin/Debug/OmniSharp.Http.Driver/net461/OmniSharp.exe'
let g:OmniSharp_server_use_mono = 1

[JulioJu]

@axvr I've tested with the official compiled version by Microsoft, and with the packaged version of ArchLinux.

@nickspoons thanks for your information. I will test next week.
As OmniSharp/omnisharp-roslyn#1274 take a very long time to be fixed, maybe it could be very cool to make an official tarball. It seems to be simple to make a release https://help.github.com/articles/creating-releases/ . If you are not admin on https://github.com/OmniSharp/omnisharp-roslyn, and admins of this repository won't make an alternative release, maybe you could make a release on the current repository ?

It could be very cool for newbies that want use your excellent plugin !

[JulioJu]

@nickspoons tested. All work well with dotnet 2.2.100 and the current master of omnisharp-roslyn. Thanks for your help ! see #437 (comment)

I believe it could be very cool to publish a recent official release build on Arch Linux. If you want I could post a new issue to ask that at https://github.com/OmniSharp/omnisharp-roslyn/issues/ ?

What do you think about that ?

[nickspoons]

@JulioJu I don't have any permissions for [OmniSharp/omnisharp-roslyn]. I don't think it would be right to host omnisharp-roslyn releases in omnisharp-vim.

However the current situation is very frustrating. If you can convince the OmniSharp-roslyn guys to publish an Arch Linux build then that will presumably be useful to other arch users ... but I'm not sure it will work. The omnisharp-roslyn repo has a good release build system running with Travis so they'll want any other releases they do to use similar tooling. And it appears to be something in the Travis build that is causing the problem.

At somepoint somebody with the right combination of knowledge and time is going to need to investigate properly - possibly by recreating the ubunty environment that Travis uses and tinkering the the builds there? I don't know. I'm painfully short on time myself at the moment!

All of that said, by all means create an issue with omnisharp-roslyn. I'd love to be able to start using the latest versions of omnisharp-roslyn again, and keep up with the changes they are making over there!

[JulioJu]

@nickspoons

No current releaser seems to be on Arch Linux. If it's confirmed, we could ask if they accept to grant your permissions at [OmniSharp/omnisharp-roslyn]. Then, you could publish your own binary of Omnisharp Roslyn thanks this steps https://help.github.com/articles/editing-and-deleting-releases/ (no need to make a new release with a new tag, just manually add your own version of OmniSharp-Roslyn on the last existing release). Or ask if you could send an email with in its content your binary, then an existing releaser could manually add your binary to the last existing release. The name of this binary could be for example omnisharp.http-linux-x64.omnisharp-vim.tar.gz for no chances of confusions.

What do you think about that ?

As I'm nobody (no contributions in this Repository, no particular skills) I can't ask for me :-).

[JulioJu]

@nickspoons

Sorry, tested further.

The last version of OmniSharp can't retrieve omnicompletion with ALE. It displays the errors, but not omnicompletion. (see #437).

And when I try to compile older versions of this, there is an error. I don't understand why, maybe the version of the mono or of an library, something like that. see #437 (comment)

If you won't publish your OmniSharp bin, could you send me by email ? Thanks in advance.

[nickspoons]

@JulioJu I'm not going to publish my compiled omnisharp-roslyn. As described in the omnisharp-roslyn issues mentioned previously, mine was a hacked together solution for debugging - the fact that it works doesn't make it at ready to be shared as a release.

The "linux" release at omnisharp-roslyn works perfectly well on arch linux. The issues we have been having since 1.32.2 affect all *nix variants, so a specific arch linux build won't help.

As to your completion - ALE is only used for error highlighting in omnisharp-vim. ALE can perform autocompletion, but it does this internally and only for LSP language servers, which omnisharp-roslyn is not (currently). So to get completions you can use <C-x><C-o>, or use a tool that gives you omnifunc autocompletion such as mucomplete.

[nickspoons]

@JulioJu I can send you a tarball of my outdated omnisharp-roslyn if you want me to, but why? Didn't you say you had successfully built it yourself?

[JulioJu]

@nickspoons

Ok I understand

Sorry, I was not clear. No any completion work with omnisharp-roslyn 2881c46e2212b41aed22ee5ec1aafab99b6b6ecf (the last one commit the 12/11/2018), even if I type <C-x><C-o> (see #437).

When I try to compile 2881c46e2212b41aed22ee5ec1aafab99b6b6ecf, all work when I follow OmniSharp/omnisharp-roslyn#1202 (comment).

When I checkout to older release, the compilation fail, even if I check OmniSharp/omnisharp-roslyn#1202 (comment) (I've tested lot of times, with several release). see #437 (comment)

Sorry, I was unclear !

I like if you send me your old binary, thanks. I send you an email :-). Thanks a lot.

[JulioJu]

See also #437 (comment)

@nickspoons maybe could you confirm ? If you confirm, maybe I must wait that OmniSharp/omnisharp-roslyn#1361 will be closed before open a new issue on omnisharp-roslyn ?

I've tried to upgrade all package of build/Packages.csproj and replace all reference of dotnet core 2.1 to dotnet core 2.2 and upgrade from net461 to net462 without results (build fail). Probably upgrade packages is more complicated ? And maybe it's not the caused of the error described at #437 (comment) ? What do you think about that ?

[JulioJu]

@nickspoons after many search I've found a cool workaround !

Replace:

omnisharp-vim/autoload/OmniSharp.vim

Line 607 in 8829316

call OmniSharp#proc#RunAsyncCommand(command, a:sln_or_dir)

by

  let savedPath = $PATH
  let $PATH = '/media/data/home/dotnet2.1.301/:'.$PATH
  call OmniSharp#proc#RunAsyncCommand(command, a:sln_or_dir)
  let $PATH = savedPath

Then when you are in your Vim, you keep your dotnet installed globally ! (e.g. 2.2.100). You could test, in a file .cs to type :echom $PATH | !dotnet --version or :terminal bash -c 'echo $PATH ; dotnet --version' !

@nickspoons what do you think about that ! Like that, you keep dotnet 2.2.100 installed globally, and omnsiaharp-roslyn is loaded with its compatible version, with it's version in which one it was build (dotnet 2.1.103, see https://github.com/OmniSharp/omnisharp-roslyn/blob/master/global.json).

And I've tested with the version of omnisharp-roslyn 3.2.8 build thanks #437 (comment) (in this comment, replace each occurrence of 3.2.5 by 3.2.8).

Note: I've noticed that with the following configuration, I have the same problem as described at #437 (comment), even with dotnet 2.1.103 globally installed. Therefore the following configuration should be get off the vimrc.

        let g:OmniSharp_server_use_mono = 1
        let g:OmniSharp_server_path = '/media/data/home/omnisharp-roslyn/artifacts/publish/OmniSharp.Http.Driver/mono/OmniSharp.exe'

[JulioJu]

@nickspoons so cool, I've seen OmniSharp/omnisharp-roslyn#1274 (comment) therefore I close the current issue. I'm happy.

Maybe you could update https://github.com/OmniSharp/omnisharp-vim#Server and advise to use pre-released version of OmniSharp ?

[nickspoons]

Great job getting this diagnosed and fixed @JulioJu!

For now I think it's less confusing to just wait for the next OmniSharp-roslyn release. Downloading and installing the pre-release is a bit messy, and in the meantime the old 1.32.1 release still seems to work fine for most people (maybe not? I'm not sure).

The ones who are desperate enough to watch this issue will see that there's a solution now anyway 😄

[masaeedu]

@nickspoons

The ones who are desperate enough to watch this issue will see that there's a solution now anyway 😄

Is this solution patching the omnisharp-vim as shown in this comment?

[nickspoons]

@masaeedu you don't need to patch vim, the solution in that comment just manually adds a specific dotnet version to the beginning of your $PATH. If you want to do this in the plugin rather than just altering your $PATH you can do that.

The solution @JulioJu is taking about is the fix to Http communication in OmniSharp-roslyn so we can start using newer versions than 1.32.1. Lots of issues have been fixed and improved in later versions but OmniSharp-vim has been stuck. However @JulioJu found and fixed the problem on the OmniSharp-roslyn end.

There hasn't been a tagged OmniSharp-roslyn release including the fix yet, but it'll be along soon. Anyone wanting to upgrade immediately can try a prerelease build of OmniSharp-roslyn, see this comment

[JulioJu]

@nickspoons pre-release here https://github.com/OmniSharp/omnisharp-roslyn/releases/tag/v1.32.12 !!

Therefore maybe you could update the README now ? And change default behaviour of :OminSharpInstall ? ;-) ?

[nickspoons]

I saw it @JulioJu, but there was a problem with that release (note that there are no Linux/Mac assets).

I informed the OmniSharp-roslyn guys and they have made a new release - I'll update soon.

[nickspoons]

@JulioJu updated

[JulioJu]

So cool ! End of a very very old issue… Near height months !