Omnisharp-roslyn: MSBuild "Couldn't load project" because `The SDK 'Microsoft.Net.Sdk' specified could not be found`

Created on 4 Mar 2019 · 25Comments · Source: OmniSharp/omnisharp-roslyn

I'm trying to use OmniSharp 1.32.9 with LSP support in Eclipse aCute (instead of older versions).
I can connect to OmniSharp through LSP, so the connection part seems fine. But OmniSharp logs a failure that make the LS request never receive a response

[Log]   [dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        FAILURE: Could not locate '/home/mistria/runtime-New_configurationds(2)/.metadata/.plugins/org.eclipse.acute/omnisharp-roslyn/omnisharp/msbuild/15.0/Bin/Microsoft.Build.resources.dll'.
[Warning]   [warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/home/mistria/runtime-New_configurationds(2)/NewDotnetProject/NewDotnetProject.csproj'.
[Error] [fail]: OmniSharp.MSBuild.ProjectManager
        Attempted to update project that is not loaded: /home/mistria/runtime-New_configurationds(2)/NewDotnetProject/NewDotnetProject.csproj

After that, no LSP request receives a response.
The omnisharp/msbuild/15.0/Bin/Microsoft.Build.resources.dll file is indeed not present in any recent package of omnisharp.

Source

mickaelistria

Most helpful comment

You're breaking something every time. Please test it well.

We are sorry about that.

However, opting into "omnisharp.path": "latest" pulls the latest build from the master branch which by its nature may not always be stable (or might be affected by some CI issues), since not every merge is an official supported release. Therefore it's only recommended to use "omnisharp.path": "latest" to check the latest functionality/verify some bugs fixes from OmniSharp etc. but not for long term sustainable usage.

The safer way is to set "omnisharp.path" to one of the versions found here https://github.com/OmniSharp/omnisharp-roslyn/blob/master/CHANGELOG.md, they will be more stable than just taking latest master branch build.

But of course, the safest way is to simply use the version of the OmniSharp that ships with the given editor extension (VS Code, emacs and so on).

Hope this helps.

filipw on 18 Apr 2019

👍8 ❤4

All 25 comments

@johnnyasantoss Could it be related to https://github.com/OmniSharp/omnisharp-roslyn/pull/1349 ?

mickaelistria on 5 Mar 2019

I wonder if omitting .resources here and return null would fix the issue?

bjorkstromm on 8 Mar 2019

@johnnyasantoss Could it be related to #1349 ?

@mickaelistria I don't think that it is related to that. What the PR #1349 did was to change the way that Omnisharp searches for MSBuild instances across the system, in a way that it prefers instances that have .net core installed, and disfavors the standalone one. :)

johnnyasantoss on 12 Mar 2019

Last version that was successfully tested for LSP was 1.29.1. I tried some intermediary versions in the meantime, but could see much progress because of #1269 . Latest version should fix #1269 but I'm now stuck by this issue.

With 1.29.1 too, msbuild 15.0 is included and I don't see the Microsoft.Build.resources.dll file, but it doesn't fail.
So it seems to me that the issue is not in the packaging but rather than the MSBuild detection has a bug and looks (and fails) for non-existent files; while it was working fine with the same environment in 1.29.1 (and maybe later, but I can't bisect with my use-case because of #1269).

mickaelistria on 13 Mar 2019

On Slack, @demelev mentions

Yesterday the friend of mine got it worked on ArchLinux, he didn’t report about such an error.
try to find where those dlls are `fd Microsoft.Build.resources /usr`
on my machine they are at ‘/usr/local/share/dotnet/sdk/2.1.301/en/Microsoft.Build.resources.dll’

So I removed my current dotnet installation (that did not contain the Microsoft.Build.resources.dll) and reinstalled the fresh one (which does contain this dll).
But nothing changes, the msbuild location is still resolving to the msbuild folder inside OmniSharp which misses the Microsoft.Build.resources.dll and then fails.

@demelev: are you using directly the content of the omnisharp-linux-x64.zip folder or are you using something else or tweaking the content?