SDK resolver does not work with snap installations of SDK on Linux

[nguerrera]

See dotnet/vscode-csharp#3160

When installed via snap:

sudo snap install dotnet-sdk --beta --classic
sudo snap alias dotnet-sdk.dotnet dotnet

Then dotnet on PATH resolves to a realpath of /usr/bin/snap and not to a dotnet executable next to the sdk foler.

This breaks an assumption of the resolver that we can use realpath on dotnet on PATH to find the SDK.

We could maybe implement something like the much slower option of shelling out to dotnet --info as msbuildlocator and legacy omnisharp do. Or we would need a way to resolve to the real directory somehow. I am not sure if snap gives us this ability. Is there a way to query snap to know if there is a dotnet-sdk installed and where can we find it's real directory. Can we do this without forking processes and parsing stdout?

The slow path could be a fallback. If there is a dotnet on PATH, but it does not resolve to a realpath with an sdk directory, try running it with --info. This would fix other hypothetical deployments like a dotnet that is a shell script that execs dotnet with custom args or whatever. It may make sense to keep this as an ultimate fallback even if we find a more efficient way to handle the snap case.

[nguerrera]

cc @leecow @wheelerlaw @livarcocc

[float34]

I don't think only the snap is affected.
The very same problem occurs on Manjaro/Arch Linux (issue has been reported by many) when you install dotnet with pacman.
In this case pacman pulls the package from community repo.
And the package contains dotnet.sh which is effectively added to PATH after being installed to /usr/bin. Obviously it is not a symlink, so the resolving process fails.
The SDK itself is installed to /opt/dotnet/, all SDK folders and the executable are in place.
BTW, adding .json with legacy option solves/hides the issue.

[nguerrera]

Thanks, @Torquerrr, I'd seen the arch/manjaro issues, but thought it was something with mono there. Now we have the simpler explanation, and so I think even if we handle snap more efficiently we should have the ultimate fallback to slow path of shelling out.

That said, would it be hard to make that a symlink on arch? That will resolve faster. The shell script doesn't do anything but exec dotnet with same args.

[nguerrera]

If you see other reports of arch/manjaro issues, can you link here?

[float34]

@nguerrera

... but thought it was something with mono there. Now we have the simpler explanation, and so I think even if we handle snap more efficiently we should have the ultimate fallback to slow path of shelling out.

I forgot to mention that I do have the latest Mono (5.20) installed, as well as msbuild-stable package. But probably those are irrelevant indeed.
I have based my judgement mainly on your explanation of how the current resolver works that it looks for the target executable and SDKs folders nearby.

That said, would it be hard to make that a symlink on arch? That will resolve faster. The shell script doesn't do anything but exec dotnet with same args.

@alucryd could you please provide your thoughts on that?

[nguerrera]

The shell script doesn't do anything but exec dotnet with same args.

I read too quickly and was mistaken here, it sets DOTNET_ROOT. There is a better solution for this now to store where dotnet is installed globally for apphosts. Looking for the docs.

[nguerrera]

https://github.com/dotnet/designs/blob/master/accepted/install-locations.md

Instead of DOTNET_ROOT, /opt/dotnet can be written to /etc/dotnet/install_location

However, this will require updating to 3.0

[float34]

@nguerrera Just tried to manually create a symbolic link instead of .sh file pointing to /opt/dotnet/dotnet - still getting the error:
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk.Razor' specified could not be found. /usr/lib/mono/msbuild/15.0/bin/Sdks/Microsoft.NET.Sdk.Web/Sdk/Sdk.props.
dotnet --info returns a valid output.

[nguerrera]

What version is dotnet --version?

[float34]

@nguerrera

.NET Core SDK (reflecting any global.json):
 Version:   2.2.108
 Commit:    33ed5b90ce

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /opt/dotnet/sdk/2.2.108/

Host (useful for support):
  Version: 2.2.6
  Commit:  7dac9b1b51

.NET Core SDKs installed:
  2.2.108 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 2.2.6 [/opt/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[nguerrera]

Hmm, do you have "Microsoft.DotNet.MSBuildSdkResolver.dll" under /usr/lib/mono/msbuild?

[float34]

@nguerrera Nope. I've checked in /usr/lib/mono/msbuild/15.0/bin/, no other folders or files above that.

[nguerrera]

OK, that is actually a problem here on top of the symlink or lack thereof. That mono has the web sdk baked into it, no razor sdk, and no resolver to find dotnet.

cc @radical

[nguerrera]

(I really wish mono would stop baking sdks into its msbuild and using the resolver always, same as VS msbuild.)

[nguerrera]

cc @livarcocc

[float34]

@nguerrera Made a full filesystem search just to be sure and found only these two:

/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/15.0/Bin/SdkResolvers/Microsoft.DotNet.MSBuildSdkResolver/Microsoft.DotNet.MSBuildSdkResolver.dll

/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin/SdkResolvers/Microsoft.DotNet.MSBuildSdkResolver/Microsoft.DotNet.MSBuildSdkResolver.dll

[nguerrera]

Those are with the private mono in omnisharp so it's an issue that it's missing in the real mono. Out of curiosity, does it work if you temporarily uninstall mono? Are you able to upgrade mono to more recent version and does that help?

[radical]

@Torquerrr how did you install mono? It is supposed to include the resolver.

[float34]

@nguerrera Here's the OmniSharp Log after mono removal:

OmniSharp Log

Starting OmniSharp server at 8/10/2019, 10:31:48 AM Target: /home/torquerrr/Projects/NET Projects/NewWebApp

OmniSharp server started.
Path: /home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/run
PID: 4320

Starting OmniSharp on manjaro 0.0 (x64)
info: OmniSharp.Services.DotNetCliService
DotNetPath set to dotnet
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 1 MSBuild instance(s)
1: StandAlone 16.0 - "/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin"
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
MSBUILD_EXE_PATH environment variable set to '/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin/MSBuild.dll'
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: StandAlone 16.0 - "/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin"
MSBuildExtensionsPath = /home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild
BypassFrameworkInstallChecks = true
CscToolPath = /home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin/Roslyn
CscToolExe = csc.exe
MSBuildToolsPath = /home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin
info: OmniSharp.Cake.CakeProjectSystem
Detecting Cake files in '/home/torquerrr/Projects/NET Projects/NewWebApp'.
info: OmniSharp.Cake.CakeProjectSystem
Could not find any Cake files
info: OmniSharp.MSBuild.ProjectSystem
No solution files found in '/home/torquerrr/Projects/NET Projects/NewWebApp'
info: OmniSharp.MSBuild.ProjectManager
Queue project update for '/home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj'
info: OmniSharp.Script.ScriptProjectSystem
Detecting CSX files in '/home/torquerrr/Projects/NET Projects/NewWebApp'.
info: OmniSharp.Script.ScriptProjectSystem
Could not find any CSX files
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.RenameWorkspaceOptionsProvider, Order: 100
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.EditorConfigWorkspaceOptionsProvider, Order: 200
info: OmniSharp.WorkspaceInitializer
Configuration finished.
info: OmniSharp.Stdio.Host
Omnisharp server running using Stdio at location '/home/torquerrr/Projects/NET Projects/NewWebApp' on host 4216.
info: OmniSharp.MSBuild.ProjectManager
Loading project: /home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj
[warn]: OmniSharp.MSBuild.ProjectManager
Failed to load project file '/home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj'.
/home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. /home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject (System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, System.Object[] args) [0x00040] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1] (System.Boolean condition, System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, T1 arg0) [0x00003] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject[T1] (Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, T1 arg0) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].ExpandAndLoadImportsFromUnescapedImportExpressionConditioned (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, System.Collections.Generic.List1[Microsoft.Build.Construction.ProjectRootElement]& projects, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult, System.Boolean throwOnFileNotExistsError) [0x0024e] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].ExpandAndLoadImports (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult) [0x00027] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0 at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].EvaluateImportElement (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement) [0x0000d] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].PerformDepthFirstPass (Microsoft.Build.Construction.ProjectRootElement currentProjectOrImport) [0x000e6] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0 at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].Evaluate (Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Framework.BuildEventContext buildEventContext) [0x00103] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Evaluator4[P,I,M,D].Evaluate (Microsoft.Build.Evaluation.IEvaluatorData4[P,I,M,D] data, Microsoft.Build.Construction.ProjectRootElement root, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, System.Int32 maxNodeCount, Microsoft.Build.Collections.PropertyDictionary1[T] environmentProperties, Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Evaluation.IItemFactory2[S,T] itemFactory, Microsoft.Build.Evaluation.IToolsetProvider toolsetProvider, Microsoft.Build.Evaluation.ProjectRootElementCache projectRootElementCache, Microsoft.Build.Framework.BuildEventContext buildEventContext, Microsoft.Build.BackEnd.SdkResolution.ISdkResolverService sdkResolverService, System.Int32 submissionId, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x0002d] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project.Reevaluate (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x0005e] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00035] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00007] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project.Initialize (System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00126] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0 at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00093] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0 at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0 at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.String toolsVersion) [0x000f7] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.String toolsVersion) [0x00000] in <4e0a1f1d78cf4c1ebd6f9a3dbcebf3bb>:0
at OmniSharp.MSBuild.ProjectLoader.EvaluateProjectFileCore (System.String filePath) [0x0003f] in :0
at OmniSharp.MSBuild.ProjectLoader.BuildProject (System.String filePath) [0x0000d] in :0
at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Load (System.String filePath, OmniSharp.MSBuild.ProjectIdInfo projectIdInfo, OmniSharp.MSBuild.ProjectLoader loader) [0x00015] in :0
at OmniSharp.MSBuild.ProjectManager+<>c__DisplayClass29_0.b__0 () [0x00000] in :0
at (wrapper delegate-invoke) System.Func1[System.ValueTuple3[OmniSharp.MSBuild.ProjectFile.ProjectFileInfo,System.Collections.Immutable.ImmutableArray1[OmniSharp.MSBuild.Logging.MSBuildDiagnostic],OmniSharp.MSBuild.Notification.ProjectLoadedEventArgs]].invoke_TResult() at OmniSharp.MSBuild.ProjectManager.LoadOrReloadProject (System.String projectFilePath, System.Func1[TResult] loader) [0x0001b] in :0

Attempted to update project that is not loaded: /home/torquerrr/Projects/NET Projects/NewWebApp/NewWebApp.csproj

Output looks the same as before - except no more Mono initialization.

Edit: It looks like now it fails to find Microsoft.NET.Sdk.Web, whereas previously (when Mono was in place) it was Microsoft.NET.Sdk.Razor. But I am not 100% sure.

The project was created with dotnet new webapp.
I already had the very latest available mono installed for my distro (captured before removing):

Mono JIT compiler version 5.20.1 (makepkg/886c4901747 Wed Apr 17 15:49:14 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        Interpreter:   yes
        LLVM:          supported, not enabled.
        Suspend:       hybrid
        GC:            sgen (concurrent by default)

@radical I install it with pacman -S mono. But for me it looks like a problem unrelated to Mono at all.
I recall that in related issues people mentioned that they were able to fix that by downgrading dotnet itself. Probably I need to give it a try.

[float34]

@nguerrera, @radical
So this is more tricky to deal with.
It turns out that mono build for Arch from extra repo comes without msbuild instance, and no Microsoft.DotNet.MSBuildSdkResolver.dll present.
Then you'll need to install msbuild package from AUR - and here you choose from msbuild-stable (which I did) and msbuild plus msbuild-sdkresolver.
After removing msbuild-stable and installing both msbuild and msbuild-sdkresolver the error is gone, and the Microsoft.DotNet.MSBuildSdkResolver.dll can now be found in /usr/lib/mono/msbuild/15.0/bin/SdkResolvers/.
But now OmniSharp dislikes something else:

OmniSharp.MSBuild.ProjectLoader
NETSDK1061: The project was restored using Microsoft.AspNetCore.App version 2.2.6, 
but with current settings, version 2.2.0 would be used instead. To resolve 
his issue, make sure the same settings are used for restore and for subsequent 
operations such as build or publish. Typically this issue can occur if the 
RuntimeIdentifier property is set during build or publish but not during restore. 
For more information, see https://aka.ms/dotnet-runtime-patch-selection.

Looks like it's a known issue?

[nguerrera]

It looks like the C# plugin / omnisharp is not up to date. How are you installing that? Can you try the scenario:

1. Without mono installed
2. With latest C# plugin for VS code

As for the scenario with a mono, with a proper resolver, that NETSDK1061 is not in itself an issue. The linked doc would explain the the cases where that can happen and how to avoid it. But, if there's something about how restore is happening in VS Code that is triggering it, that is not known.

[float34]

@nguerrera You can find the log attached above by me showing how does it look like without mono installed (https://github.com/dotnet/cli/issues/12110#issuecomment-520127598)
C# plugin is indeed the latest version, installed from within VS Code itself.
More and more I start to think that this is the Arch/Manjaro-specifig bug, the only way to overcome which is setting the LegacyResolver in omnisharp.json.
As I also noted, mono build for Arch does not have MsBuild instance - not sure what should I do next.

[nguerrera]

My bad, I misread the latest version of the C# plugin elsewhere. I will try to spin up an arch VM to play with some of this, but it won't be too quick to be able to do that. Thank you for all of the extra info.

[float34]

@nguerrera Sure, thanks in advance! I am also thinking of spinning a clean Manjaro installation in the VM. So we can compare installed packages' versions.

[float34]

@rchande, @radical I am afraid Mono SDK is somehow involved.
As far as I remember even the dotnet purging does not affect the OmniSharp output - it is the same The SDK 'Microsoft.NET.Sdk.Razor' specified could not be found.
I think I can provide some additional info after clean VM run.

[float34]

@nguerrera
After spending some time with clean Ubuntu 19.04 installation I think I have found a solution. It will apply mostly to Arch/Manjaro users, but likely the same approach could be used for other cases/OSes/packaging types.
Let's start from the basic packages almost anyone who reported the issue (and related issues) have.
In parentheses I will specify versions installed on my machine.

1. dotnet-sdk + dotnet-runtime + dotnet-host (2.2.108 for SDK, 2.2.6 for Host and Runtime)
2. Mono (5.20.1)
3. VSCode (1.37.1)
4. VSCode C# Extension with OmniSharp (1.21.0/1.34.0)
5. MSBuild (16.00)

And one can run into three types of errors with this (OmniSharp):

1. The SDK 'Microsoft.NET.Sdk' specified could not be found
2. The SDK 'Microsoft.NET.Sdk.Web' specified could not be found
3. The SDK 'Microsoft.NET.Sdk.Razor' specified could not be found
   In my case it has always been the 3rd option.

But then I set "omnisharp.useGlobalMono": "never" in settings.json.

And immediately I've embraced them all:
For dotnet new console project I have the 1st case,
for dotnet new webapp project I have the 2nd case.
But not the 3rd anymore.

Last week I tried creating a symlink for /usr/bin/dotnet pointing to /opt/dotnet/dotnet, and it did not help.
Well, it did - but guess what? - I have overlooked that because of the Mono which has been chosen by OmniSharp as the primary SDK. And its output overshadowed the working solution. Hence I saw the 3rd error type no matter what I did.

Unfortunately you cannot remove Mono completely. First, because it is used as a base for MSBuild (correct me if I am wrong), second - Mono is required for Unity development workflows (but it seem to work if you just turn the Mono off globally as I showed above).

Bottom line:

1. If you have the .sh script in /usr/bin/dotnet instead of symlink pointing to the SDK (/opt/dotnet/dotnet) - replace the script with symlink.
   Also set "omnisharp.useGlobalMono": "never" in settings.json if you have Mono installed.

I will try to let the dotnet Arch package maintainer know that the current way of setting this does not work.

2. OmniSharp uses Mono by default:

[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 2 MSBuild instance(s)
            1: Mono 16.0 - "/usr/lib/mono/msbuild/15.0/bin"
            2: StandAlone 16.0 - "/home/torquerrr/.vscode/extensions/ms-vscode.csharp-1.21.0/.omnisharp/1.34.0/omnisharp/.msbuild/Current/Bin"

So I guess it behaves the way that it is able to find the Sdk, and the Web, but not the Razor, because first two are present in Mono.
I'd personally like to use pure dotnet for web development and Mono for Unity, but not Mono all the time, even for console projects.

3. Mono does not have the SDK Resolver included by default. Even if it did - how should it behave? It is absolutely cryptic to me.

P.S. I don't think that this approach is much better than setting the MSBuildSDKsPath environment variable as has been suggested many times, but I hope it sheds some light on the problem.

[devel0]

getting similar problem with error The SDK 'Microsoft.NET.Sdk' specified could not be found. trying to invoking roslyn workspace open project at this line or follow repro docker prj

------------ENTRYPOINT
Microsoft.NETCore.App 3.0.0-preview9-19423-09 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
dotnet executable = [/usr/bin/dotnet]
PATH              = [/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
---> OpenProject
Msbuild failed when processing the file '/src/test/test.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found.  /src/test/test.csproj
---> GetCompilation
has documents = False

[cyphercider]

For anyone else having this problem after installing the dotnet sdk using apt on ubuntu, I found that having dotnet at /usr/share/dotnet doesn't work on its own. However, if I create a symlink from /usr/share/dotnet to ~/dotnet, it works. I also have set the MSBuildSdksPath:

export MSBuildSDKsPath="/usr/share/dotnet/sdk/$(dotnet --version)/Sdks"

[mattiaswerner]

I was struggling with omnisharp not resolving the dotnet-sdk snap on 20.04 until I discovered that a simple

ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet

did the trick. No need for msbuild path exports or an omnisharp json legacy resolver.

[programatta]

I was struggling with omnisharp not resolving the dotnet-sdk snap on 20.04 until I discovered that a simple

ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet

did the trick. No need for msbuild path exports or an omnisharp json legacy resolver.

Thanks! It's works as a charm!

Only, I found other problem, for example, if you want execute your project from command line:
dotnet run <your.dll>
or
dotnet run bin/Debug/netcoreapp3.1/<your.dll>
threw an exception.
I solved this problem here:
dotnet/core#2186 (comment)

p.d: My apologies, but my English is not very good.

[leolopez89]

@jeffkhull I solve the problem only exporting the variable

export MSBuildSDKsPath="/usr/share/dotnet/sdk/$(dotnet --version)/Sdks"

Thanks a lot!!!

[Gerhard-Piette]

DO NOT USE Ubuntu.
Not even the Binary file from https://dotnet.microsoft.com/download/dotnet/5.0 works because the dotnet executable is not recognized on Ubuntu. I guess it is related to dotnet-sdk on snap on Ubuntu.

I have no problems using the .net5 RC1 on Fedora 33 beta.

Download the dotnet-sdk SDK manually.
I have downloaded the Binaries from https://dotnet.microsoft.com/download/dotnet/5.0
No package manager.

Start VSCode with a script file with this content:
export PATH=$PATH:/YYY/
/home/XXX/Downloads/VSCode/code-insiders

where you have to adapt XXX and YYY to your case.
YYY is the folder where you have stored the SDK.

DO NOT USE Ubuntu snap.
Someone working on snap dotnet-sdk must have introduced an automatic "dotnet" alias that is listed but can not be removed with the "sudo snap unalias dotnet" command because Error: "cannot find manual alias "dotnet" in any snap".
Unfortunately the people working on omnisharp do not care about this problem.

From my console:

xxx:~$ dotnet

Usage: dotnet [options]
Usage: dotnet [path-to-application]

Options:
-h|--help Display help.
--info Display .NET information.
--list-sdks Display the installed SDKs.
--list-runtimes Display the installed runtimes.

path-to-application:
The path to an application .dll file to execute.
xxx:$ snap aliases
Befehl Alias Anmerkungen
dotnet-sdk.dotnet dotnet -
xxx:$ sudo snap unalias dotnet
Fehler: cannot find manual alias "dotnet" in any snap

Previously:

I made this post already here and here.

On Ubuntu 20.04.1, the problem is the snap alias. Do not install it.

Instead do this:

sudo snap install dotnet-sdk --channel=5.0/beta --classic

DO NOT install the alias because it makes Omnisharp not find the SDK.
sudo snap alias dotnet-sdk.dotnet dotnet

It can be removed with:
sudo snap unalias dotnet

Start VSCode with a script file with this content:
export PATH=$PATH:/snap/dotnet-sdk/current/
/home/XXX/Downloads/VSCode/code-insiders

You have to adapt the second line, that starts VSCode insiders, to your case.

[noah1510]

Would it be possible to look for the SDK in the DOTNET_ROOT environment variable?
DOTNET_ROOT is already an intended environment variable by the sdk when you try to directly run a binary produced by the dotnet sdk.
All the extention has to do is check if that variable exists and then look for the sdk in that path.

Adding the SDK to the path causes a lot of problems (at least the snap installation) but having it in a separate variable should be a good 'workaraound'.

[Krishnadas-KP]

I was struggling with omnisharp not resolving the dotnet-sdk snap on 20.04 until I discovered that a simple

ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet

did the trick. No need for msbuild path exports or an omnisharp json legacy resolver.

Fantastic. This solved for me too. Thank you

[tazuddinleton]

Getting following error when running dotnet run :

relocation error: /usr/lib/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

[wheelerlaw]

Getting following error when running dotnet run :

relocation error: /usr/lib/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

Open a new issue. This doesn't seem at all related to the topic of this issue.

[alexcohn]

Similar problem on arm64 Mac, with vscode Insiders. Running dotnet --info produces this:

.NET SDK (reflecting any global.json):
 Version:
 Commit:    N/A

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.1
 OS Platform: Darwin
 RID:
 Base Path:   /Users/alex/UnrealEngine/Engine/Binaries/ThirdParty/DotNet/6.0.302/mac-arm64/sdk/6.0.302/

global.json file:
  /Users/alex/UnrealEngine/global.json

Host:
  Version:      6.0.7
  Architecture: arm64
  Commit:       0ec02c8c96

.NET SDKs installed:
  6.0.302 [/Users/alex/UnrealEngine/Engine/Binaries/ThirdParty/DotNet/6.0.302/mac-arm64/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.7 [/Users/alex/UnrealEngine/Engine/Binaries/ThirdParty/DotNet/6.0.302/mac-arm64/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.7 [/Users/alex/UnrealEngine/Engine/Binaries/ThirdParty/DotNet/6.0.302/mac-arm64/shared/Microsoft.NETCore.App]

Download .NET:
  https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info

My dotnet was installed by UnrealEngine. Is this an incompatible version? Why is .NET SDK (reflecting any global.json) empty? Should something special be addd to global.json?

{
  "sdk": {
    "version": "6.0.302"
  }
}

[nagilson]

Snap installs are managed by canonical, so we created a new issue here canonical/dotnet-snap#13 and also updated the documentation.