Visual studio не видит sdk net core
Обновлено: 07.07.2024
The text was updated successfully, but these errors were encountered:
richlander commented Mar 28, 2019
ambs commented Apr 5, 2019
Don't ask me where I found this, but the following command has fixed the issue for me (probably worth a try):
dotnet nuget locals all -c
I also have added this to my omnisharp.json:
@zeroskyx , where did you find the omnisharp.json file? Thanks
EDIT2: did not solve it.
@zeroskyx , where did you find the omnisharp.json file? Thanks
EDIT1:
/.omnisharp/
EDIT2: did not solve it.
richlander commented Apr 14, 2019
Please try it (or a later release), and share if that resolves the problem for you.
MaxXor commented May 20, 2019
@richlander The issue does still happen in latest version 1.19.1. I created a new program with dotnet new console and loaded the directory in vscode.
My project file looks like this:
Doeke commented May 22, 2019
@MaxXor I suddenly got the exact same error today, when it was working fine before. I was eventually able to fix it by installing Visual Studio Community 2019. Instead of using MSBuild Visual Studio Community 2017 15.9.28307.280, it detected Visual Studio Community 2019 16.1.28917.181 and now it works again.
Note, I tried installing older omnisharp versions but it had no effect (1.19.1 to 1.19 and then 1.18)
MaxXor commented May 22, 2019
@Doeke Sadly that doesn't work for me on Linux.
rheinz57 commented Jul 1, 2019
Don't ask me where I found this, but the following command has fixed the issue for me (probably worth a try):
dotnet nuget locals all -c
I also have added this to my omnisharp.json:
Just running the "dotnet nuget locals all -c" worked for me
I still get this error when creating new projects with dotnet new console on Windows 10.
This did not work for me:
Don't ask me where I found this, but the following command has fixed the issue for me (probably worth a try):
dotnet nuget locals all -c
I also have added this to my omnisharp.json:
Just running the "dotnet nuget locals all -c" worked for me
chaselal commented Jul 10, 2019
Installing Visual Studio 2019 and opening my .sln in Visual Studio 2019 fixed the problem for me.
richlander commented Jul 18, 2019
I tried this on a new macOS machine and did not run into this problem with the latest 3.0 preview and VS Code. If anyone is still having this problem, can you provide a detailed description of your environment?
TheSimpleZ commented Aug 2, 2019
I have the same problem on Ubuntu 19.04, using dotnet 3.0.100-preview7-012821.
I made a project using dotnet new webapi and opened it in VSCode.
nguerrera commented Aug 2, 2019
@TheSimpleZ From the logs, your sdk was installed via snap and we have an issue with SDK resolution there.
@nguerrera Thank you! Now it works well.
I got this problem today with the latest VS Code installed on Manjaro ( visual-studio-code-bin 1.36.1-1 I believe). I also ran into this issue last week on Arch Linux; installing msbuild 16+ solved it.
gx2g commented Sep 23, 2019
I'm on Windows 10 1903, install vs-code. Noticed when you create your first program it stores it in the the users root directory folder. if you move it from this folder you'll need to clear local resources (cache).
Using the command above : dotnet nuget locals all -c
once I did that I could then run my app which I placed in Documents folder. This resolved all output issues in vs-code.
miegir commented Sep 24, 2019
Don't ask me where I found this, but the following command has fixed the issue for me (probably worth a try):
dotnet nuget locals all -c
I also have added this to my omnisharp.json:
I just upgraded to dotnet core 3.0 on MacOS and OmniSharp failed to load my projects. Setting the UseLegacySdkResolver to true worked for me :)
eatenapple commented Sep 27, 2019
I uninstalled 'Remote - WSL' extension. maybe SDK-Path problem (where to set in VScode?)
trampster commented Sep 29, 2019
I'm having this problem with the dotnet core 3.0 full release, and omnisharp 1.34.4-beta.23 on ubuntu 18.04 :(
filipw commented Sep 29, 2019
you could try adding omnisharp.json file:
and see if it helps. If it doesn't please post your OmniSharp log.
where is omnisharp.json?
my
/.omnisharp/ folder is empty. should it be?
I created the omnisharp.json file and it fixed the problem.
I assume this means that the current SdkResolver is broken. is there a fix coming? when is it safe to remove the UseLegacySdkResolver setting?
trampster commented Sep 29, 2019
I see that this issue is closed, but clearly is still happening using the latest version, can it please be reopened?
I have a suspicion that up until now all your ubuntu users using dotnet core 3.0 were using the snap package because Microsoft doesn't provide deb packages for previews, now that the full release is out, could it be that you had a non snap related issue all along but no one noticed because no one could test it.
Well the full release is out it, uses debs not snaps and it's broken please reopen.
Here is my dotnet --info showing that I am not using the snap sdk
Runtime Environment:
OS Name: ubuntu
OS Version: 18.04
OS Platform: Linux
RID: ubuntu.18.04-x64
Base Path: /usr/share/dotnet/sdk/3.0.100/
It requires I open a project in VS, but when I try to open it I get the following error:
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.
19.8k 43 43 gold badges 59 59 silver badges 111 111 bronze badges 771 1 1 gold badge 4 4 silver badges 3 3 bronze badges14 Answers 14
Step 1) First run dotnet --list-sdks from the command line (as in Grzegorz Smulko's answer). Take note of the greatest version number.
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
With only the v2.2.203 installed projects didn't load for me in VS2019. I had to install v2.2.105 too.
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.
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. 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 you should make your comment an answer probably or add it as a PS to the answer. It fixed my problem!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.
As detailed on that page, you'll need the following versions of dotnet for each visual studio version:
Make sure that there are no global.json files further up in your directory structure that are screwing things up.
In my case, remove program files(x86)\dotnet in Environment path then restart visual studio and it worked.
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.
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. Similar issue here. looks like deleting the x86 dotnet folder fixes it, so that the system can find the one it "should" be finding.I had the same error a while back which caused my web api projects to fail during the solution loading process.
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.
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
I was able to fix the VS 2019 issue with the below steps
- Run dotnet --list-sdks to know the exact version of the SDK installed
- 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
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?
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'
If you see this error with Visual Studio 16.8, update NuGet.exe to 5.8.0
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.
Highly active question. Earn 10 reputation (not counting the association bonus) in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.Related
Hot Network Questions
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
VS Code version:
1.40
Steps to reproduce
Expected behavior
Actual behavior
The text was updated successfully, but these errors were encountered:
FlyingWraptor commented Nov 10, 2019
GhostShot3 commented Nov 11, 2019
Failed to install
gregg-miskelly commented Nov 11, 2019
Please, don't install the 3.0-rc1 SDK -- that is an outdated release candidate.
GhostShot3 commented Nov 12, 2019
Yes i install i tryed and say already installed
gregg-miskelly commented Nov 12, 2019
Can you try uninstalling it and reinstalling it? I suspect something went wrong with the first install.
GhostShot3 commented Nov 15, 2019
Worked, thank you
nightblade9 commented Dec 3, 2019
Just wanted to chime in and say I saw the same problem, with the same resolution.
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.
newVincentFong commented Jan 16, 2020
Exit VSCode and open it.
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.
agawasare commented May 21, 2020
JoeRobich commented May 21, 2020
JackTiber commented May 28, 2020
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.
gregg-miskelly commented May 28, 2020
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.
JackTiber commented May 28, 2020
@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.
Cabola commented Jun 2, 2020
If there's still people having this issue then try this:
- From start menu search for "this pc", right click and select properties.
- Click Advanced system settings
- Click on "Environment Variables. "
- Select either the Users or Systems "Path" variable and click Edit.
- 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 Files\dotnet\ 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 Files\dotnet\ and click the "move up" button. Then click OK all the way out of there, now try and see if things are working..
visuallization commented Aug 25, 2020
Drexlin commented Sep 17, 2020
@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.
JackTiber commented Sep 17, 2020
@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.
Читайте также: