The SDK 'Microsoft.NET.Sdk' specified could not be found #3160
Comments
|
Okay, so the issue is caused by this line inside of Unless that the environment variable A possible solution would be to create a provider that searches for MSBuild instances in system-wide installations. Alternatively, one could just write another SdkResolver that extends from the BaseSdkResolver that looks for Sdks elsewhere in the system than just |
Finding SDKs using that default resolver is not the happy path. There's a a resolver that runs first that is supposed to find things that come from the .NET Core SDK. https://github.com/dotnet/cli/tree/master/src/Microsoft.DotNet.MSBuildSdkResolver When that fails, the default resolver, gets a try. This is largely a legacy thing that the default resolver can find a fixed copy of the sdk next to msbuild. Many msbuild distributions (VS 2019 included) don't have anything there, and those that still do should remove them. Currently, the more appropriate resolver requires a I am not yet familiar with snap, and the snap distribution isn't yet part of the official process of developing and testing the .NET Core SDK. There may be other issues lurking behind this. We will be discussing adding it to our process. |
|
Oh, what you referenced as the "legacy" resolver, is actually not legacy at all. The default resolver is the legacy one with respect to getting tasks and targets that ship with .NET Core SDK. The code I pointed to is for this Microsoft.DotNet.MSBuildSdkResolver.dll, that's the one that should find the things in .NET Core SDK, and I am assuming the PATH is setup differently, which is causing it not to work. Fixing this should focus on that resolver. |
|
|
|
So with the debugging output enabled, it looks like the OmniSharp MSBuildLocator is having a hard time finding that resolver you mentioned: Full log: |
|
For now, you should be able to workaround things by forcing omnisharp to use the legacy resolver that just shells out to dontet --info. You can do this by creating ~/.omnisharp/omnisharp.json with this content: I don't think that failure to load a satellite assembly is the actual issue. Notice it couldn't find Microsoft.Build.resources.dll either. I believe the problem is that |
Then either that definitely needs to change, or OmniSharp should be using the legacy resolver by default, since that's the way Snap appears to be providing the packages and Snap is $ ll $(which dotnet)
lrwxrwxrwx. 1 root root 17 Jul 29 11:59 /var/lib/snapd/snap/bin/dotnet -> dotnet-sdk.dotnet*
$ ll $(which dotnet-sdk.dotnet)
lrwxrwxrwx. 1 root root 13 Jul 29 11:59 /var/lib/snapd/snap/bin/dotnet-sdk.dotnet -> /usr/bin/snap*I know Snap does some funny things on how to figure out what command is being executed.
So then you mean that the MSBuildSdkResolver can alternatively shell out to |
Or a new SDK resolver is written specifically to handle SDKs installed by Snap. |
Okay done. @nguerrera lmk what you think |
|
That is roughly the same approach as when legacy resolution is enabled, but using --list-sdks instead of --info + grep for base path will not respect global.json. Ideally, I think we should fix the main resolver in dotnet/cli to handle this case somehow. Putting this in omnisharp also won't solve the problem for other configurations of mono msbuild + snap sdk. I will open an issue on dotnet/cli |
|
Did you try this: #3160 (comment) ? |
The legacy code that shells out dotnet --info, which can be enabled with that json, is not a proper sdk resolver. It forces the sdk using MSBuildSdksPath. I believe this is where that happens: https://github.com/OmniSharp/omnisharp-roslyn/blob/51cf29ca5785ad4973ad0579ece445e7d1992484/src/OmniSharp.MSBuild/SdksPathResolver.cs#L32 |
|
That predates the proper plugin model for sdk resolution. The legacy code was kept behind that flag as an escape hatch, but MSBuildSdkResolver was intended to fully replace it. If in fact we need to shell out in some cases, we should do that in MSBuildSdkResolver, potentially as a fallback. I would like to try to find a more efficient way for snap though. https://github.com/dotnet/cli/issues/12110 tracks fixing MSBuildSdkResolver so that we don't need new resolvers and we don't need to turn on the legacy code. |
|
My recommendation would be to use #3160 (comment) as a workaround and use https://github.com/dotnet/cli/issues/12110 to track the fix. This can probably be closed against that. cc @rchande |
|
@nguerrera |
|
@Torquerrr Thanks. Better to discuss that here: https://github.com/dotnet/cli/issues/12110 I wrote " This would fix other hypothetical deployments like a dotnet that is a shell script that execs dotnet with custom args or whatever." Well I guess this isn't hypothetical. So we could fix it that way. Basically make the official resolver work like the legacy omnisharp resolver if resolving the faster way fails.... |
|
@nguerrera Should I duplicate my comment in #12110 then? |
|
Please! Thanks |
|
@wheelerlaw @Torquerrr @nguerrera Thanks for the great discussion. Since we believe this fix belongs in the SDK, I'm going to close this in favor of https://github.com/dotnet/cli/issues/12110 . |
That actually fixed it for me on macOS.
|
|
Issue Description
Fresh installation of .NET Core 3, VSCode, and the C# extension fails to open apps created by
dotnet new console -o test-appon Fedora 29. Some of the related issues have workarounds, but they only work on Windows.Steps to Reproduce
sudo snap install dotnet-sdk --beta --classic sudo snap alias dotnet-sdk.dotnet dotnetsudo rpm --import https://packages.microsoft.com/keys/microsoft.asc sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo' dnf check-update sudo dnf install codetest-appfolder in VSCode. It will show an error.Expected Behavior
The project opens successfully, I am able to debug the program.
Actual Behavior
Small window pops up with an error. I have to manually configure the debug configurations.
Logs
OmniSharp log
Debug log:
C# log
n/a
Environment information
VSCode version: 1.36.0
C# Extension: 1.20.0
Mono Information
OmniSharp using built-in monoDotnet Information
.NET Core SDK (reflecting any global.json): Version: 3.0.100-preview6-012264 Commit: be3f0c1a03Runtime Environment:
OS Name: fedora
OS Version: 29
OS Platform: Linux
RID: fedora.29-x64
Base Path: /var/lib/snapd/snap/dotnet-sdk/41/sdk/3.0.100-preview6-012264/
Host (useful for support):
Version: 3.0.0-preview6-27804-01
Commit: fdf81c6faf
.NET Core SDKs installed:
3.0.100-preview6-012264 [/var/lib/snapd/snap/dotnet-sdk/41/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [/var/lib/snapd/snap/dotnet-sdk/41/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.0-preview6-27804-01 [/var/lib/snapd/snap/dotnet-sdk/41/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Visual Studio Code Extensions
The text was updated successfully, but these errors were encountered: