The net core sdk cannot be located как исправить

Official C# support for Visual Studio Code (powered by OmniSharp) - OmniSharp/omnisharp-vscode

Introduction

This page contains more information about the error:

The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path.

What this error means is that this extension ran the command dotnet and dotnet was NOT found on the PATH within the extension’s process.

If you don’t have the .NET Core SDK installed, fixing this error is usually simple enough: visit https://dot.net/core-sdk-vscode to download and install the .NET Core SDK.

If you do have the .NET Core SDK installed, then this means that the directory containing dotnet (Linux and macOS) or dotnet.exe (Windows) is not on your PATH, at least in this extension’s process. The rest of this page will provide advice on understanding why.

Known issues

Before we get to a list of troubleshooting steps, lets first enumerate a few known reasons why this error happens:

  1. If you very recently installed the .NET SDK —
    • If you had Visual Studio Code open at the time you installed the .NET SDK, and you haven’t restarted it, you should do so.
    • On Windows, on some machines, environment variable changes don’t immediately take effect. Restart your computer to see if that resolves this problem.
  2. If the .NET SDK was installed through Linux Snap — see Linux Snap instructions

General troubleshooting steps on Linux/Mac

The first step in troubleshooting this problem is to see if this problem also happens is a terminal/shell. After you have launched a terminal or shell, type in which dotnet.

If which dotnet produces a PATH, then the .NET SDK was able to successfully modify the PATH, but VS Code isn’t picking it up. VS Code attempts to scrape the environment by launching the default shell under the covers. But this process can be fragile. You can attempt to work around this by starting VS Code from your Terminal. Alternatively, you can attempt to debug VS Code to understand what is going wrong — at this time at least, the function to debug is getUnixShellEnvironment. Lastly, you could manually add a symbolic link from within a directory which is on the PATH in all processes to wherever dotnet is installed (see below for instructions).

If which dotnet produces no output, then this means the .NET SDK wasn’t able to modify the PATH or add a symbolic link, or the .NET SDK for your platform doesn’t do so. You can fix this by either adding a symbolic link yourself (example: sudo ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet where /usr/share/dotnet/dotnet should be replaced with wherever the .NET SDK installer for your platform was installed to), or by modifying your PATH manually (example: modify ~/.bashrc add add something like export PATH=$PATH:/new/directory/here).

General troubleshooting steps on Windows

First, as mentioned above, if you installed the .NET SDK since you last rebooted Windows, you might start by just rebooting to see if that fixes things.

Otherwise, you can start troubleshooting this problem is to see if this problem also happens is a command prompt:

  • Start a command prompt:
    • Hit WinKey+R to bring up the Windows run dialog
    • Type in cmd.exe
  • When the command prompt starts, type in where.exe dotnet.

If the result of running where.exe is that a path to dotnet.exe is printed (example: C:Program Filesdotnetdotnet.exe) then the .NET SDK has successfully added itself to the Windows Path. There are no known reasons why PATH wouldn’t be propagated to the VS Code process. You could try starting VS Code from the command prompt to see if that helps.

If the result of running where.exe is a message like INFO: Could not find files for the given pattern(s). then the .NET SDK wasn’t able to add itself to the PATH. You could try uninstalling and reinstalling the .NET SDK. You could also try examining the default path with the following steps:

  • Bring up System Properties:
    • Windows 10 — On the Start Menu, search for ‘This PC’ and bring up properties
    • Before — On the Start Menu, search for ‘My Computer’ and bring up properties
  • Go to the Advanced settings
  • Click the button for ‘Environment Variables’
  • Find ‘Path’ in either the user or system list
  • See if the dotnet.exe directory (example: C:Program Filesdotnet) is in the list. If not you could add it.
  • If it is in the list, you could see if maybe another directory has added it self incorrectly (example: added an opening quote without a trailing quote), or if the set of environment variables has grown very large — there is a limit of 32,767 total characters.

Note about 64-bit installs of the .NET SDK

In 64-bit environments the .NET SDK will fail to be discovered if the 32-bit dotnet path comes before the 64-bit dotnet path in the Environment PATH variable. Try removing the 32-bit path entirely from your PATH variable and relaunch VS Code to see if your issue is resolved.

Special instructions

Linux Snap instructions

The Linux Snap packages for the .NET Core SDK, by default, will not create the dotnet link. To do so, run sudo snap alias dotnet-sdk.dotnet dotnet. More information about this can be found in the .NET Core SDK release notes.

Note that, as of the time of this writing, there are also other incompatibilities between this extension and the .NET Core SDK Snap package beyond the dotnet PATH issue. This incompatibility may result in:

Some projects have trouble loading. Please review the output for more details.
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download

More information about this problem can be found in dotnet/cli#12110.

Some community members have been successful in using the Snap install by following the instructions listed in Configuring Snap installs of dotnet-sdk.

Another possible workaround is to add the following to ~/.omnisharp/omnisharp.json.

{
    "MSBuild": {
        "UseLegacySdkResolver": true
    }
}

I’m following this tutorial — Share Azure Spatial Anchors
across sessions and devices — at Microsoft Docs.

It requires I open a project in VS,
but when I try to open it I get the following error:

error : The project file cannot be opened by the project system,
because it is missing some critical imports or the referenced SDK
cannot be found.

Detailed Information: Unable to locate the .NET Core SDK. Check that
it is installed and that the version specified in global.json (if any)
matches the installed version.

I have the SDK version specified in the JSON
and all the other tools specified in the tutorial, but still nada. 
I think I’m missing a step somewhere. Any help would be hugely appreciated.

Scott - Слава Україні's user avatar

asked May 1, 2019 at 17:02

muz's user avatar

0

Step 1) First run dotnet --list-sdks from the command line (as in Grzegorz Smulko’s answer). Take note of the greatest version number.

enter image description here

Step 2) Create a global.json file at the root of the solution with the exact version number from step 1. it needs to contain all the digits otherwise it wont work. This is the my version at the time of writing

{
  "sdk": {
    "version": "3.1.101"
  }
}

answered May 25, 2019 at 21:16

Max Carroll's user avatar

Max CarrollMax Carroll

1,1811 gold badge4 silver badges6 bronze badges

8

Try running dotnet --list-sdks in the console.
According to the info on the pages that appear after downloading .NET Core SDKs from https://dotnet.microsoft.com/download, you need to have version v2.2.106 for VS2017 and v2.2.203 for VS2019.

With only the v2.2.203 installed projects didn’t load for me in VS2019.
I had to install v2.2.105 too.

answered May 10, 2019 at 16:55

Grzegorz Smulko's user avatar

3

I fixed it by installing the x86 version of the SDK.

It looks like each version of Visual Studio has it’s own corresponding dotnet version that it builds on. This is due to msbuild requirements.

If you are a Visual Studio user, there are MSBuild version requirements so use only the .NET Core SDK supported for each Visual Studio version. If you use other development environments, we recommend using the latest SDK release.

https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.6/2.2.6.md

As detailed on that page, you’ll need the following versions of dotnet for each visual studio version:

  • Visual Studio 2017 (Windows): .NET Core SDK x86 2.2.108
  • Visual Studio 2019 version 16.0: .NET Core SDK x86 2.2.205
  • Visual Studio 2019 version 16.1: .NET Core SDK x86 2.2.301
  • Visual Studio 2019 version 16.2: .NET Core SDK x86 2.2.401

answered Jul 29, 2019 at 10:09

soniiic's user avatar

soniiicsoniiic

3462 silver badges5 bronze badges

4

I had this problem because I uninstalled some older dotnet SDKs. Not only would VS2019 no longer load dotnet core projects, but dotnet was no longer available on my path and so not available on the command line as simply dotnet.

After installing multiple older versions of dotnet and reparing my VS2019 install, I was finally able to fix it by adding C:Program Filesdotnet to my path. Then VS2019 would load the project again.

Also, none of this affected VS2017, which could load and fully work with the project. And it worked on the command line when I specified the full path to the dotnet executable.

answered Jul 9, 2019 at 18:25

Jason's user avatar

JasonJason

2512 silver badges3 bronze badges

3

None of the above worked for me. I noticed that I was having the issue on every type of project, even non-netcore. I was able to use the global.json and get that working. Then I noticed that I had a global.json in a directory further up which was referencing an alpha build of .net core. Deleted that file and bingo no further issue.

tl;dr

Make sure that there are no global.json files further up in your directory structure that are screwing things up.

Community's user avatar

answered Feb 11, 2020 at 20:50

WillT's user avatar

WillTWillT

2482 silver badges5 bronze badges

1

In my case, remove program files(x86)dotnet in Environment path then restart visual studio and it worked.

answered Feb 3, 2020 at 3:52

Hoang Tran's user avatar

Hoang TranHoang Tran

1611 silver badge4 bronze badges

2

I found the same issue. It was releated with this bug https://github.com/dotnet/core-setup/issues/4236

That seems to be a bug in dotnet x86 version.

I just changed x64 dotnet (C:Program Filesdotnet) to be before x86 dotnet (C:Program Files (x86)dotnet`) in the %PATH% environment variable and it worked just fine.

answered Aug 5, 2019 at 12:01

bruno.almeida's user avatar

3

I had the same error a while back which caused my web api projects to fail during the solution loading process.

I solved it by reinstalling the following items from https://dotnet.microsoft.com/download

  • .Net Core Runtime (2.2.401 was the latest at the time)
  • .Net Core SDk (2.2.6 was the latest at the time)

answered Aug 28, 2019 at 7:00

ian korkie's user avatar

I faced this problem in vs 2019 v16.3
I have uninstalled old versions of netcore 2.1 SDK except version 2.1.801.

I found a file global.json in the folder: c:Usersadmin (my login user is admin) that point to uninstalled version 2.1.602

Although netcore SDK version 2.1.801 is installed, it’s not used because it doesn’t match the Patch number.

from documentation:

The patch version is defined by the last two digits (yz) in the last portion of the number (xyz) for SDK versions 2.1.100 and higher. For example, if you specify 2.1.300 as the SDK version, SDK selection finds up to 2.1.399 but 2.1.400 isn’t considered a patch version for 2.1.300.

I modified the file to point to 2.1.801 and it’s working fine

answered Sep 25, 2019 at 17:28

M.Hassan's user avatar

I ran into this today, where a solution has some (but not all) the projects using .net core; I had not been into this project in probably a month and had not intentionally done anything with the .net SDKs, so this was a mystery what the heck happened.

My project has no global.json at the root, creating one with the the latest (3.1.201) from dotnet --list-sdks didn’t help. WTF?

Then I found this: https://developercommunity.visualstudio.com/content/problem/896868/unable-to-locate-the-net-core-sdk-after-1650-previ.html

Visual Studio now removes previous .NET Core SDKs. If you encounter this problem, you can:

– Install .NET Core SDK from https://dotnet.microsoft.com/download.

  • Don’t use global.json. The latest version of the .NET Core SDK is the default and can build apps targeting earlier versions of the .NET Core Runtime.

  • Include a roll forward indicator (in global.json) such as the following which will ensure running with any SDK higher than 3.1.100 [see link for details]

A routine install of the latest .NET sdk (3.1.300) resolved this issue, but this feels like really poor behavior of Visual Studio — if it can’t find an SDK, maybe tell us which one it’s looking for? Ugh.

answered May 28, 2020 at 15:07

Steve Friedl's user avatar

I was able to fix the VS 2019 issue with the below steps

  1. Run dotnet --list-sdks to know the exact version of the SDK installed
  2. Modify the global.json file in the root folder of the project (In my case it was showing 2.2.100 but I had 2.2.401 installed, I edited the same to point to that version and I was able to reload the projects

MMM's user avatar

MMM

2,5843 gold badges24 silver badges42 bronze badges

answered Mar 3, 2020 at 13:44

agnei's user avatar

agneiagnei

111 bronze badge

I tried everything listed in the answers with the same error in VS 2019 and ultimately the thing that wound up fixing it was following these steps:

Right-clicked on Solution and hit ‘Resolve Errors’

I spent a full day installing and uninstalling various .net packages and of all the things, that’s the one that got it to build.
…If Microsoft can tell where an error is, why doesn’t it just try to resolve it automatically?!

answered Jan 16, 2020 at 20:15

Erin B's user avatar

Erin BErin B

1217 bronze badges

answered Nov 12, 2020 at 14:30

druss's user avatar

drussdruss

1312 bronze badges

This can happen if you uninstall old versions of .NET Core SDK which all take a lot of space. What happens is the uninstaller removes the PATH entry of the dotnet executable, even the one by other .NET installations, so VS cannot find it. If that is the case, if you type in where dotnet in the terminal, you won’t get anything. Find the path to dotnet.exe manually (usually C:Program Filesdotnet) and add it to PATH. Check in Control Panel whether there is a version actually installed. Make sure to log off and log in again, otherwise it won’t work even if you restart VS.

Another possibility is that there is a mismatch between the versions. Type in dotnet --version in the terminal and check the default version. If you get a different version than expected, you can set the exact version you want used by VS by using the global.json file as instructed in other answers.

answered Dec 1, 2020 at 13:28

Gru's user avatar

Содержание

  1. The .NET Core SDK cannot be located #3401
  2. Comments
  3. GhostShot3 commented Nov 10, 2019 •
  4. Environment data
  5. Steps to reproduce
  6. Expected behavior
  7. Actual behavior
  8. FlyingWraptor commented Nov 10, 2019
  9. FlyingWraptor commented Nov 10, 2019
  10. GhostShot3 commented Nov 11, 2019
  11. gregg-miskelly commented Nov 11, 2019
  12. GhostShot3 commented Nov 12, 2019
  13. gregg-miskelly commented Nov 12, 2019
  14. GhostShot3 commented Nov 15, 2019
  15. nightblade9 commented Dec 3, 2019
  16. MikaelElkiaer commented Dec 17, 2019 •
  17. newVincentFong commented Jan 16, 2020
  18. Environment
  19. Reference
  20. My Solution
  21. Reason
  22. agawasare commented May 21, 2020
  23. JoeRobich commented May 21, 2020
  24. JackTiber commented May 28, 2020
  25. gregg-miskelly commented May 28, 2020
  26. JackTiber commented May 28, 2020
  27. Cabola commented Jun 2, 2020
  28. visuallization commented Aug 25, 2020
  29. Drexlin commented Sep 17, 2020
  30. JackTiber commented Sep 17, 2020
  31. The .NET Core SDK cannot be located when it’s installed as a snap with dotnet-sdk. #3502
  32. Comments
  33. NatoBoram commented Jan 10, 2020 •
  34. Issue Description
  35. Steps to Reproduce
  36. Expected Behavior
  37. Actual Behavior
  38. OmniSharp log
  39. C# log
  40. Environment information

The .NET Core SDK cannot be located #3401

Environment data

dotnet —info output:
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download

Host (useful for support):
Version: 3.0.0
Commit: 95a0a61858

.NET Core SDKs installed:
No SDKs were found.

.NET Core runtimes installed:
Microsoft.NETCore.App 3.0.0 [C:Program Files (x86)dotnetsharedMicrosoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [C:Program Files (x86)dotnetsharedMicrosoft.WindowsDesktop.App]

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

VS Code version:
1.40

C# Extension version:
1.21.6

Steps to reproduce

Expected behavior

VScode find .net core sdk

Actual behavior

VScode can’t find .net core sdk but i installed it

The text was updated successfully, but these errors were encountered:

Same thing when using 1.21.7

Failed to install

Please, don’t install the 3.0-rc1 SDK — that is an outdated release candidate.

@GhostShot3 the output you have from above indicates that the C# extension is working correctly — you don’t have a .NET SDK installed, just a .NET runtime. Did you install an SDK? Here is the current install link from https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install

Yes i install i tryed and say already installed

Can you try uninstalling it and reinstalling it? I suspect something went wrong with the first install.

Worked, thank you

Just wanted to chime in and say I saw the same problem, with the same resolution.

In my case, I uninstalled several things (.NET Core 2.2.7, .NET Core 3.0, NuGet, Mono) and reinstalled just the .NET Core 3.0. That seemed to resolve the problem.

It looks like VSCode was picking up the MSBuild/etc. from the Mono folder (mine was Mono 6.0 for some reason), but anyway, reinstall for the win.

(I’m on Linux if that matters)

I have this problem when starting VSCodium with drun.
Starting VSCodium from zsh and it works as expected.

Can anyone explain what the different in these two methods could be? Something related to paths I imagine.

Update: Actually, I do get what I expected from dotnet —info when running that in a terminal.
And if I have one instance of VSCodium open that I started from terminal. Any extra instances I open with drun now works.

Update 2: It was strictly a VSCodium issue, works fine in VSCode.

Environment

  • .NET Core SDK 3.1
  • VSCode C# Extension 1.21.9
  • Mac

Reference

If you had Visual Studio Code open at the time you installed the .NET SDK, and you haven’t restarted it, you should do so.

My Solution

Exit VSCode and open it.

Reason

I try not to exit vscode on my mac when it’s connected to a monitor because vscode has some
GPU rendering problem in this circumstances. This habbit leads to the problems.

Also note, if you are installing .net sdk on a platform where we do not provide an installer or where you want to automate the installation. The dotnet-install script should configure everything necessary. https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

This issue pops up on Ubuntu 20.04 following both links above, when installing using APT, snap or the script cited. I can run which dotnet and verify the sdk binary is in PATH, but when opening vs code from the same terminal session using code . it still throws the errors around the missing SDK.

This issue isn’t a problem with this extension — this is either a problem with VS Code, or with your shell. There is instructions in there on debugging VS Code if you are so inclined.

@gregg-miskelly thanks for the link! So oddly, that did help with VS Code popup regarding a missing SDK, but then in the actual output logs of the Omnisharp plugin’s language server, it still fails to find an SDK binary to use. Originally, I had the sdk installed via APT, but most recently used SNAP to see if that worked.

At this point, I am going to do a full wipe of the machine and start from scratch, to also support a couple of hardware updates I am making. Will check back in either way, but definitely a lot of issues installing it on LTS versions of Ubuntu.

If there’s still people having this issue then try this:

  1. From start menu search for «this pc», right click and select properties.
  2. Click Advanced system settings
  3. Click on «Environment Variables. «
  4. Select either the Users or Systems «Path» variable and click Edit.
  5. In either of them you should find the path to your «dotnet» folder

now in my case I had 2 C:Program Files (x86)dotnet and C:Program Filesdotnet if you actually go to the folders you’ll notice that there’s no sdk folder within the C:Program Files (x86)dotnet folder. So simply select C:Program Filesdotnet and click the «move up» button. Then click OK all the way out of there, now try and see if things are working..

I basically just had to restart my pc after installing the .NET sdk. Then it all worked! I guess some changes (env variables?) needed a reboot.

@JackTiber Where you able to solve your issue? I’m having the same problem and wondering if going nuclear is my only option at this point. Thanks.

@Drexlin I did. At the end of the day, the best method I found was to remove any trace of the SDK (snap especially which can have even more issues than installing via APT in the docs) and then re-installing using APT. Once it is installed, verify that you can get the binary on your path with which dotnet , but do not try to use it yet. Restart your machine, which I recommend actually shutting down completely and then bringing it back up. At that point, it started working for me.

The link @gregg-miskelly provided is pretty helpful in detailing the troubleshooting steps.

Honestly, if I had to guess this probably has something to do with where the binary is installed on Debian based systems and the spawned shell for the extension / VS Code, which is somehow why the restart makes a difference. Some environment variable that isn’t set after installation is probably set during startup and fixes the issue. Recently worked with a Fedora 32 machine and had all of 0 problems getting the SDK installed and working with the extension and code.

Источник

The .NET Core SDK cannot be located when it’s installed as a snap with dotnet-sdk. #3502

Issue Description

The .NET Core SDK cannot be located when it’s installed as a snap

Steps to Reproduce

Expected Behavior

The extension should work.

Actual Behavior

The extension doesn’t work.

The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path.

OmniSharp log

Starting OmniSharp server at 2020-01-10, 11:31:19 a.m.
Target: /home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation.sln

OmniSharp server started.
Path: /home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/run
PID: 17803

Starting OmniSharp on ubuntu 19.10 (x64)
info: OmniSharp.Services.DotNetCliService
DotNetPath set to dotnet
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 1 MSBuild instance(s)
1: StandAlone 16.3 — «/home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild/Current/Bin»
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
MSBUILD_EXE_PATH environment variable set to ‘/home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild/Current/Bin/MSBuild.dll’
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: StandAlone 16.3 — «/home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild/Current/Bin»
CscToolExe = csc.exe
MSBuildToolsPath = /home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild/Current/Bin
CscToolPath = /home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild/Current/Bin/Roslyn
BypassFrameworkInstallChecks = true
MSBuildExtensionsPath = /home/gendnat/.vscode-insiders/extensions/ms-vscode.csharp-1.21.9/.omnisharp/1.34.9/omnisharp/.msbuild
info: OmniSharp.Cake.CakeProjectSystem
Detecting Cake files in ‘/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation’.
info: OmniSharp.Cake.CakeProjectSystem
Could not find any Cake files
info: OmniSharp.MSBuild.ProjectSystem
Detecting projects in ‘/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation.sln’.
info: OmniSharp.MSBuild.ProjectManager
Queue project update for ‘/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj’
info: OmniSharp.Script.ScriptProjectSystem
Detecting CSX files in ‘/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation’.
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.MSBuild.ProjectManager
Loading project: /home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj
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/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation’ on host 17658.
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download
[warn]: OmniSharp.MSBuild.ProjectManager
Failed to load project file ‘/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj’.
/home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK ‘Microsoft.NET.Sdk.Web’ specified could not be found. /home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject (System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, System.Object[] args) [0x00040] in :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 :0
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject[T1] (Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, T1 arg0) [0x00000] in :0
at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].ExpandAndLoadImportsFromUnescapedImportExpressionConditioned (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, System.Collections.Generic.List 1[Microsoft.Build.Construction.ProjectRootElement]& projects, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult, System.Boolean throwOnFileNotExistsError) [0x00254] in :0
at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].ExpandAndLoadImports (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult) [0x00027] in :0 at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].EvaluateImportElement (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement) [0x0000d] in :0
at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].PerformDepthFirstPass (Microsoft.Build.Construction.ProjectRootElement currentProjectOrImport) [0x000e6] in :0 at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].Evaluate (Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Framework.BuildEventContext buildEventContext) [0x0011c] in :0
at Microsoft.Build.Evaluation.Evaluator 4[P,I,M,D].Evaluate (Microsoft.Build.Evaluation.IEvaluatorData 4[P,I,M,D] data, Microsoft.Build.Construction.ProjectRootElement root, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, System.Int32 maxNodeCount, Microsoft.Build.Collections.PropertyDictionary 1[T] environmentProperties, Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Evaluation.IItemFactory 2[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, System.Boolean interactive) [0x0002f] in :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 :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 :0
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00000] in :0
at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00007] in :0
at Microsoft.Build.Evaluation.Project.Initialize (System.Collections.Generic.IDictionary 2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00126] in :0 at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary 2[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 :0
at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary 2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in :0 at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary 2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in :0
at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary 2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection) [0x00000] in :0 at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.Collections.Generic.IDictionary 2[TKey,TValue] globalProperties, System.String toolsVersion) [0x000f7] in :0
at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.String toolsVersion) [0x00000] in :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.Func 1[System.ValueTuple 3[OmniSharp.MSBuild.ProjectFile.ProjectFileInfo,System.Collections.Immutable.ImmutableArray 1[OmniSharp.MSBuild.Logging.MSBuildDiagnostic],OmniSharp.MSBuild.Notification.ProjectLoadedEventArgs]].invoke_TResult() at OmniSharp.MSBuild.ProjectManager.LoadOrReloadProject (System.String projectFilePath, System.Func 1[TResult] loader) [0x0001b] in :0

Attempted to update project that is not loaded: /home/gendnat/Code/bitbucket.org/groupecmi/gri-ms-vacation/Vacation/Vacation.csproj

C# log

Failed to spawn ‘dotnet —info’

Environment information

VSCode version: 1.42.0-insider
C# Extension: 1.21.9

Mono Information OmniSharp using built-in mono Dotnet Information A valid dotnet installation could not be found. Visual Studio Code Extensions

Extension Author Version
Angular2 johnpapa 8.3.0
beautify HookyQR 1.5.0
code-settings-sync Shan 3.4.3
csharp ms-vscode 1.21.9
dart-code Dart-Code 3.7.1
datapack-helper pca 0.6.1
debugger-for-chrome msjsdiag 4.12.4
debugger-for-edge msjsdiag 1.0.13
discord-vscode icrawl 3.13.0
docs-yaml docsmsft 0.2.4
dotenv mikestead 1.0.1
EditorConfig EditorConfig 0.14.4
git-project-manager felipecaputo 1.7.1
githistory donjayamanne 0.4.13
gitlens eamodio 10.2.0
Go ms-vscode 0.12.0
gradle-language naco-siren 0.2.3
jbockle-format-files jbockle 3.0.0
jenkinsfile-support ivory-lab 0.4.4
jshint dbaeumer 0.10.21
language-mcfunction arcensoth 0.16.0
markdown-pdf yzane 1.4.1
mssql ms-mssql 1.8.0
mustache dawhite 1.1.1
ng-template Angular 0.900.4
npm-intellisense christian-kohler 1.3.0
output-colorizer IBM 0.1.2
path-intellisense christian-kohler 1.4.2
php-cs-fixer junstyle 0.1.129
polacode pnp 0.3.4
python ms-python 2020.1.57204
read-time johnpapa 0.2.0
sqltools mtxr 0.21.6
systemd-unit-file coolbear 1.0.6
typescript-javascript-grammar ms-vscode 0.0.53
vscode-docker ms-azuretools 0.9.0
vscode-edge-devtools ms-edgedevtools 1.0.6
vscode-firefox-debug firefox-devtools 2.6.1
vscode-markdownlint DavidAnson 0.33.0
vscode-npm-script eg2 0.3.10
vscode-react-native msjsdiag 0.13.2
vscode-typescript-next ms-vscode 3.8.20200109
vscode-typescript-tslint-plugin ms-vscode 1.2.3
vscode-yaml redhat 0.6.1
vscodeintellicode VisualStudioExptTeam 1.2.2
vsliveshare ms-vsliveshare 1.0.1456
xml DotJoshJohnson 2.5.0

Now that all those tools aren’t able to output dotnet —info , let me just print that command real quick.

Part of the problem is that dotnet-sdk will expose the command as dotnet-sdk.dotnet instead of dotnet . /snap/dotnet-sdk/current/ can be added to $PATH as a workaround, but then you lose auto-completion, so it’s not a valid solution.

The text was updated successfully, but these errors were encountered:

Источник

When working with Azure DevOps, or locally sometimes with Visual Studio, you may get the following error if there’s a mismatch. It can depend on what versions of the SDK you’ve got on your machines, either local or build agent.

Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

A related error message that I also see regularly together with the one above is:

error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.

This error can happen when the defined version of the .NET Core SDK differs from the configured value when running the dotnet tools. (e.g., the SDK version).
Realizing others may run into the same, here are some quick ways that I made it work — if it can help anyone, that’s great.

Option: Define the correct .NET Core SDK in Azure DevOps

If you’re using Azure DevOps, you can easily define the version of the .NET SDK that should be targeted when running the dotnet commands.

You already should know the version you want to target. In my example, it’s 2.2.402. Knowing this means you can ensure that your build pipeline points to the correct versions too.

Use the correct .NET Core SDK version using a Task in the UI.

If you use the visual designer for building your Azure DevOps pipelines, you can define the .NET Core SDK version to use super-easy.

Add a new build task named Use .NET Core:

Azure DevOps build Task that defines the .NET Core version to target.

In a simple pipeline, it can look like this. Ensure that the task you add is at the beginning, so all subsequent dotnet tasks use the version you’ve defined:

Use .NET Core build task in Azure DevOps

As a verification, I also added a custom .NET Core task dotnet --list-sdks which will output in the console log what version is being targeted. Sure enough, it ensures that the configuration was a success.

Use the correct .NET Core SDK version using YAML

If you’re using YAML pipelines instead of the visual pipelines, the task(s) look like this.

Specify the .NET Core version to target in the pipeline:

steps:
- task: UseDotNet@2
  displayName: 'Use .Net Core sdk 2.2.402'
  inputs:
    version: 2.2.402
    includePreviewVersions: true

Verify that the pipeline indeed is using the correct version when it runs:

steps:
- task: DotNetCoreCLI@2
  displayName: 'dotnet --list-sdks '
  inputs:
    command: custom
    custom: '--list-sdks '

I resolved all the issues without any code changes, which is what I ideally want — no changes to code due to tooling or SDK issues.

Option: adjust global.json

Unless it’s about upgrading to the latest security patch or version, I wouldn’t consider changing the version in the codebase unless there is a logical reason. I’d instead do it in the pipelines and ensure the tools know how to work with the code.

If you want to go down the other route and modify the global.json, you can, of course, do that to match whatever version the build agents and developers have installed.

A global.json file can look like this:

{
  "sdk": {
    "version": "2.2.402"
  }
}

More reading

  • global.json overview (Microsoft Docs)
  • Using the .NET Core Task (Microsoft Docs)

The other day after installing some windows update, I tried to open Visual Studio. I opened my project and I received an error regarding .Net Sdk.

The project file cannot be opened. Unable to locate the .NET SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

It was kind of frustrating because I didn’t install anything new I just installed some windows update. Also this can happen for different reasons. So I thought this made me pull my own hair out, maybe by sharing this you don’t have to go through the same.

The .Net Sdk Is Not Actually Installed

First things first, removing some low hanging fruits. First wee need to see if the Sdk is actually installed. Navigate to C:Program Filesdotnetsdk and see if you can find folders associated with different sdk versions. If you can’t find any folder there that means the sdk is not installed. In that case Install the sdk or repair it if you receive a message about it being already installed. Try running dotnet --list-sdks command to see if it lists the sdk.

The .Net Sdk Is Installed But it Has Wrong System Type

The thing about the Sdk is that you can’t mix 64x with 86x versions of the sdk. Technically you can but you need to be careful which version of dotnet is going to be selected first. More on this in next section. But if an sdk is installed, be careful you have the correct system type.

The .Net Sdk is Installed But Wrong Dotnet CLI is Trying to Run It

Sometimes you check your dotnet sdk folder and you see the sdk are installed. But when you run dotnet --list-sdks you don’t see anything. In that case try running list-sdks command with an absolute path to the correct version of dotnet. Like C:Program Filesdotnet  dotnet –list-sdks, if after running this you see the installed sdk then there are some path problems. You need to check your environment variables to make sure the correct version of dotnet is on your path. More on that in next section.

Dotnet CLI is Not on Your Path (System’s Environment Variable)

We need to first see how dotnet CLI is selected to run our commands. Take a look at this environment variables.

We see here that x64 version of the dotnet is above the x86 version of it. That means the x64 version is going to be selected to run my commands. So now if I only install the x86 version of the sdks, I’m going to have a problem. Because the x64 version of dotnet is unable to use the x86 sdks. What I need to do is to either install the x64 version of the sdk or move the x86 version above x64 version so it can be selected first.

Further Reading and References

Dotnet list-sdks does not list the installed SDKs

Microsoft Visual Studio 2019: The project file cannot be opened. Unable to locate the .NET SDK

.NET SDK not found after successful install

“No SDKs were found” after install “dotnet-hosting-2.1.2-win.exe”

Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

Summary

In this post we saw why sometimes the correct sdk is not found on your system. We saw different things we can check for in these cases and how to fix them.

Понравилась статья? Поделить с друзьями:
  • The name or description contains inappropriate text как исправить
  • The multi part identifier could not be bound ошибка sql
  • The mss dll file is installed in the windows or windows system directory как исправить
  • The movies черные персонажи как исправить
  • The movie database python ошибка