I am getting an issue with installing the .NET SDK, at first when I went into visual studio 2019 it said that I was missing the dotnet runtime sdk so I installed it like it asked and restarted my computer. I then went on to visual studio 2019 again, and the same issue arose, I went into my command prompt and typed dotnet --list-sdks
and it displayed no sdks
. I have all of the runtimes installed, but it says No SDKs were found. image . I tried re-installing the sdks but the same problem stuck. I even went as far as to re-install IIS. I can't do anything without this being fixed please help soon!

- 20,912
- 8
- 60
- 78
-
The latest .NET 3.1 SDK behaves strangely because VS Installer manages it. I installed the 3.1.7 hosting bundle and suddenly *all* my SDKs (going back to 1.1) were gone: `dotnet --list-sdks` listed nothing and my .NET Core projects wouldn't load. VS Installer says that 3.1.401 (for 16.7) is installed but it's confused and you can't reinstall it outside of VS Installer. I had to install 3.1.107 (for 16.4) to get it to load and run my projects again. – madreflection Sep 04 '20 at 19:23
-
@TomTom calm down, the sdk version I am trying to install is 3.1.401. – Sep 04 '20 at 19:28
-
@madreflection Did you get it fixed or are you still having problems with it, if you did, how did you fix it? – Sep 04 '20 at 19:28
-
In my specific case, yes, it's working. It still doesn't list 3.1.401 but projects created before 3.1.401 disappeared work. I should note that I also uninstalled every SDK from ARP... `dotnet --list-sdks` didn't list them but they were still in ARP. I then installed the latest SDK for each of the older .NET Core versions; at that time, they were: 1.1.14, 2.1.202, 2.1.809, 2.2.207, 3.0.103. I finally installed 3.1.107 instead of 3.1.401. Again, `dotnet --list-sdks` still doesn't list 3.1.401 even though VS Installer says it's installed, but everything works for me as it did before. – madreflection Sep 04 '20 at 19:33
-
That was about 3 weeks ago and I haven't run into any problems since then, but I'm still waiting to see if there's another shoe be dropped. I'm hoping that the update to 16.8 installs a new SDK version and truly fixes the situation of the latest version not being listed. That might just be the other shoe. – madreflection Sep 04 '20 at 19:36
-
@madreflection Visual studio says that my installation is also installed, but when I create a simple command line project with .net sdk it just says that there are no projects and it asks me to attach it to a program rather than just run. And the shortcut for running the program doesn't work either. – Sep 04 '20 at 19:37
-
1Try installing [3.1.107](https://dotnet.microsoft.com/download/dotnet-core/3.1) and see if that helps. That's as much as I can give you. – madreflection Sep 04 '20 at 19:38
-
@madreflection Unfortunately this didn't work, but thanks for trying! – Sep 04 '20 at 19:44
-
Assuming it's even the same problem (and it's nigh on impossible to determine if it is), you may have to go through the same reinstallation sequence I did. It's not fun and there's an element of risk, but when Visual Studio is essentially unusable because it won't load projects, well, desperate times and all that... – madreflection Sep 04 '20 at 19:56
-
@madreflection I just fixed this issue, check out my answer. – Sep 05 '20 at 09:30
-
my problem is opposite of your problem sdk's exist in dotnet --info command but not exist in visual studio . – mahdi Jan 02 '23 at 17:06
6 Answers
Before you try a manual install, I'd check if the Path in the system's environment variables is correctly configured for your system.
Given that there's always one shared host that moves forward, it will either pick the x86 or the x64 version on your machine. This issue of not picking the right one might happen if you install multiple/different versions.
Run the where.exe dotnet
command to see where the host is looking for the SDK (it's the first entry returned). If you're on a x64 machine, you want to have C:\Program Files\dotnet listed first.
If it's not, edit the Path system's environment variable to have the location you want showing up higher. Doing that should fix the issue of the SDK versions you installed not showing up when you run dotnet --info
.
See The latest installed .NET SDK not found for complete instructions.

- 20,912
- 8
- 60
- 78

- 2,544
- 2
- 14
- 11
-
"If you're on a x64 machine, you want to have C:\Program Files\dotnet listed first." is this true even when building x86 projects? – Dave Cousineau Feb 21 '21 at 04:16
-
@DaveCousineau Yes – you should run the x64 SDK on your machine. It can build executables for many other environments, e. g., x86, but it's the x64 software that should run on _your_ computer – Rolf Staflin Jun 08 '23 at 06:12
-
-
Yes this worked for me using .net core sdk version 7.0.306. Thank you very much – Abey Bruck Jul 29 '23 at 01:25
Answer above by Maira is correct and fixed the issue however for those that need a little help go to start menu, type "path" and select "Edit the System Environment variables". When that opens, under the "Advanced" tab click "Environment Variables". Under System Variables find the "Path" variable and click "Edit". Find "C:\Program Files\dotnet" and click "Move Up" so that it is above the (x86) variable.

- 839
- 1
- 8
- 13
-
2
-
2Note to others: this handy interface doesn't seem to be available in earlier versions of Windows (I am using Windows 8.1), it may be a Windows 10+ thing. I followed the same steps, but had to copy the environment variable text to notepad and edit it there, then paste back to the dialog and save. Also note that it doesn't seem to refresh immediately, so be patient when typing `where.exe dotnet` to check if it worked. – Eric Mutta Nov 09 '21 at 22:55
-
1Exactly! This solved my problem. Somehow, visual studio and other tools can recognize my .net 6 sdk but not dotnet cli tool. but this solved it. thanx – DLL_Whisperer Dec 22 '21 at 21:37
-
This is what worked for me. You have saved me useful working man hours! I have also done this for other installations that I think were affected by the same. Fantastic! – Joseph May 11 '23 at 10:59
-
-
Thanks for showing us where exactly we can find the environment variable. – Abey Bruck Jul 29 '23 at 01:25
I managed to find the answer to this problem, and anyone else who is having this problem can most likely fix it with this solution too! So the reason it breaks is because of the way the .NET Core SDK installer works, it does not install the SDK correctly for some reason, so you have to do it manually. Go to this link, where you would normally get the installer for the SDK but rather than downloading the normal version, download the binaries version. It should download as a .zip, so extract it and then copy the contents of the folder. Go to C:\Program Files (x86)\dotnet\
and then remove it's contents, finally paste your clipboard into the folder. Now try it out, open a new command prompt or PowerShell, and type dotnet --info
. It should tell you that you have all the SDK's and Runtimes installed. Keep in mind, you will have to download the newest version of the binaries, that way you have the latest version of the SDK's.
The reason this works is that you are manually pasting the SDK's into the folder, if anyone could start a ticket for the installer to Microsoft, {EDIT: MS created an internal ticket and this answer is wrong. See next answer End Edit} that would be great, and link them to this post so that they can understand what's going on. Some of you might have come here because you are fed up with reading Microsoft documentation and to be honest, so was I! Now this might not fix all the problems you are having, for example, I am still having problems with visual studio and their .NET implementation but if I or anyone figures it out, I will add it to this answer. Hope you have a great day, bye!

- 20,912
- 8
- 60
- 78
-
1Thanks for this. I manually put the files in the C:\Program Files\dotnet and deleted the folders in C:\Program Files (x86)\dotnet – Ranjith V Nov 27 '20 at 07:16
-
That's weird my DotNet Core had worked for the last four of five SDK's without a problem. Then blew up out of nowhere without installing anything. Anyways this helped, thanks! – djangojazz Feb 18 '21 at 02:54
-
This answer is incorrect. See the next answer. https://weblog.west-wind.com/posts/2019/Apr/20/Adventures-in-NET-SDK-Installation-SDKs-not-Showing-Up explains why this is incorrect. – RickAndMSFT Apr 11 '21 at 20:39
-
Just by deleting the contents of C:\Program Files (x86)\dotnet\ allowed cmd to see sdk 5.0 installed. – J33NO Aug 25 '21 at 04:44
-
You can only delete dotnet.exe from `C:\Program Files (x86)\dotnet` as well, even if the update to the PATH doesn't work (like it didn't for me) – Subjective Reality Dec 13 '21 at 23:28
-
-
1Delete dotnet.exe from C:\Program Files (x86)\dotnet works for me. Bug still exists in Mar 2023 – user2753116 Mar 14 '23 at 05:45
dotnet do not seem to match well with SDKs / runtimes with 32-bits and 64-bits. If you have both variants and want to only use the 64-bits (or generally, cant list up any SDK-s), you can try this :
- Inside folder : C:\Program Files (x86)
- Rename folder 'dotnet' to 'dotnet_x68'
- Inside a shell (remember to either run command 'refreshenv' from Chocolatey for example to refresh your environment, if you have choco installed.. )
- Enter now this command :
- dotnet --info
- Also list the SDKS :
- dotnet --list-sdks
This fixed up my development environment. Note that if you want to use dotnet against x86 system, you might consider to instead uninstall x64 variants of dotnet runtime and sdks as dotnet do not seem to work very good from command line with a mix of them both (and avoid renaming the x86 folder of dotnet of course as suggested above.

- 3,189
- 1
- 27
- 22
I found that I had two program files, One called Program Files (x86) and one called Program Files. I went to Settings, About and looked at my System Type. I have a 64-Bit operating system and so I went into Program Files (x86) and found another dotnet folder. I deleted the dotnet folder and restarted Visual Studio. It Worked after that.

- 31
- 3
-
If you have both `Program Files` and `Program Files(x86)` this means itself you have 64 bit operating system. `Program Files` contain 64 bit software versions. `Program Files(x86)` contains 32 bit software versions. – Nikage May 16 '22 at 08:52
-
+1 this fixed for me, alternatively I believe you should be able to edit the system path to point to the`Program Files` rather than the `Program Files(x86)` `dotnet` folder – Mouse Jul 23 '23 at 17:12
If you get this issue like I did on a ARM based Mac M1 or M2 then do the following.
- remove this directory completely /usr/local/share/dotnet
- run the installer package again
I believe this issue happened when I accidentally installed dotnet-ef x64 instead of arm64.

- 1,025
- 1
- 14
- 31