64

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.

Improve this question

14 Answers 14

Active Oldest Votes
97

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"
  }
}
Improve this answer
  • 3
    This fixed my problem, but I don't know why! I have other projects without this file that are working. – CSharper Jul 4 '19 at 9:51
  • 3
    Though this file exists, I need to update the version – Gopi Jul 9 '19 at 7:09
  • 7
    Cheers, while this helps, I found out that VS 2019 stops opening .net core projects when you don't have installed 2.2.205 version. Using global.json is just inconvenient and tool should not rely on it. It should use the latest version of whatever target. MS is trying us again. – Stefan Jarina Jul 26 '19 at 18:34
  • 3
    As per @Gopi, I found that the file did exist in the root folder, but the version number in it was for an old SDK that I did not have installed. I ran "dotnet --list-dsks" to find the most recent and updated the file with the correct SDK number. The solution then loaded. – Glen Little Aug 28 '19 at 21:20
  • 2
    @CSharper: VS looks for parent folder chain also for global.json. Probably you particular folder did not contain global.json, but some parent folder did contain one, which defined a version explicitely, which you did not have. So if the particular folder you overwrite it, now it works. Also your other projects reside in a folder where there are no global.json at all so no restrictive constraint prevents VS to load – g.pickardou Apr 18 '20 at 19:10
25

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.

Improve this answer
  • 2
    This should be accepted answer as that is exactly what is happening. I have currently installed 2.2.205, 2.2.301, 2.2.401, 3.0.100 --- However if you remove the 2.2.205 Visual Studio 2019 will just break (won't open ANY .net Core 2.2 projects) even though you have already newest 2.2.401. – Stefan Jarina Jul 26 '19 at 18:27
  • THIS is the permanent fix, not adding "global.json". The specific versions are here: dotnet.microsoft.com/download/dotnet-core/2.2 – Salar Oct 29 '19 at 3:11
  • 1
    This answer suffers from not being written in such a way will be accurate in the future, for instance, it’s currently out of date. Which is the reason modifying global.json is the way to go. The author first said v2.2.106 was required but it didn’t work until v2.2.105 was installed. – Ramhound Dec 24 '19 at 9:24
12

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 Files\dotnet\ 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.

Improve this answer
  • 2
    Very helpful! In my case, which is reversed: I have 2 paths point to program files\dotnet and program files(x86)\dotnet, I removed sencond one, then visual studio get able to load projects. – Dongdong Oct 29 '19 at 18:25
  • today, I found real reason. when I remove second path, the 1st path started working, and projects could be loaded. but once when I switched to another solution which has a global.json, and that json specify a different version of SDKs, then VS will no longer to load both projects. what I did is simply remove global.json, then both solutions start working. so the key reason is: you have right SDK version installed which specified by global.json. – Dongdong Oct 30 '19 at 17:30
9

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
Improve this answer
  • 1
    This is the answer – Andrew Bullock Nov 2 '20 at 17:05
  • Yes, I've been trying to resolve it for hours for .NET 5 in Visual Studio 16.8. My netstandard 2.0 cross-platform library project wasn't loading on Windows x64 despite working fine in Visual Studio for Mac. Downloading and installing .NET 5 x86 solved the problem. – Ivan Mir Dec 9 '20 at 14:33
8

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.

Improve this answer
  • This is probably the right solution. Don't go downloading lots of differnet SDKs.This solution will suffice.Thanks WillT for sharing. – netfed Apr 4 '20 at 18:14
2

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)
Improve this answer
2

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:\Users\admin (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

Improve this answer
1

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

Improve this answer
  • In my case I did not have C:\Program Files\dotnet among PATH environment variables (neither C:\Program Files (x86)\dotnet). After I've added the first one, it got OK. Thanks for the hint (to reload VS :) ) – Alexander Apr 30 '20 at 14:25
1

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
Improve this answer
1

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.

Improve this answer
0

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 Files\dotnet) to be before x86 dotnet (C:\Program Files (x86)\dotnet`) in the %PATH% environment variable and it worked just fine.

Improve this answer
  • 1
    Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – bertieb Aug 6 '19 at 14:59
  • @bertieb, done :) – bruno.almeida Aug 9 '19 at 8:44
0

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?!

Improve this answer
0

If you see this error with Visual Studio 16.8, update NuGet.exe to 5.8.0

https://ivanderevianko.com/2020/11/fixed-error-netsdk1005-assets-file-doesnt-have-a-target-for-net48

Improve this answer
0

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 Files\dotnet) 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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.