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

Thanks for the quick response. Than, please test well what you develop before merging to main. An opensource, non-commercial product doesn’t have to be a cracking one. I can not call such kind of things as a bug, they are obviously there when the plugin is getting loaded. If you want to keep this to be used, please be careful while coding and test, test, test and test again.

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.

@ocdogan

I can not call such kind of things as a bug, they are obviously there when the plugin is getting loaded

Do you have any idea how hard it is to get all the various .NET SDKs, versions of MSBuild, Visual Studio instances, and the rest to play nicely so that when you go to build a project it builds the way you expect? I suspect you don’t since as far as I can tell you’ve never contributed here, but let me tell you it’s hard. It’s not just a matter of “oh look, there’s bug, oh well let’s ship anyway!” There are all sorts of independent variables that when combined result in a very, very large set of possible end-user environments and any one of them could end up breaking. Not to mention there’s forward compatibility issues when working on build tooling - something that worked fine could break in the future in unanticipated ways when new parts of the build chain are released.

In general I would urge you to have a little more understanding and patience towards the maintainers of OSS projects that you consume and use. I applaud @filipw for his helpful and measured response. Suggesting that the folks who give a lot of time to this project are not “careful” or that they don’t “test, test, test and test again” is honestly a little insulting.

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

FYI I ran into a similar issue of projects failing to be loaded, and the error Could not locate ... Microsoft.Build.resources.dll. I run OmniSharp with an Emacs setup on macOS. I was also first confused by the Microsoft.Build.resources.dll error, but turns out the actual issue of the projects failing to load was related to the dotnet executable not being on PATH when the OmniSharp process is started from within Emacs. So, as the macOS .NET SDK install puts the dotnet executable in /usr/local/share/dotnet/dotnet, after adding /usr/local/share/dotnet to PATH it the projects loads OK.

I’m suspecting this has something to do with how Microsoft.DotNet.MSBuildSdkResolver attempts to resolve paths for SDKs based on getting info via the main dotnet CLI executable (if present).

I got the same issue on Linux and I happen to have mono’s msbuild manually compiled and isntalled. I added export MSBuildSDKsPath=/usr/local/lib/mono/msbuild/Current/bin/Sdks to my bashrc. The path will be different if installed via packages or manually to a a prefix that is not /usr/local.