MSBuild "Couldn't load project" because The SDK 'Microsoft.Net.Sdk' specified could not be found
#1416
Comments
|
@johnnyasantoss Could it be related to #1349 ? |
|
I wonder if omitting |
@mickaelistria I don't think that it is related to that. What the PR #1349 did was to change the way that Omnisharp searches for MSBuild instances across the system, in a way that it prefers instances that have .net core installed, and disfavors the standalone one. :) |
|
Last version that was successfully tested for LSP was 1.29.1. I tried some intermediary versions in the meantime, but could see much progress because of #1269 . Latest version should fix #1269 but I'm now stuck by this issue. With 1.29.1 too, msbuild 15.0 is included and I don't see the |
|
On Slack, @demelev mentions So I removed my current @demelev: are you using directly the content of the |
|
If I fully remove the |
In my case, it seems like the included instance is not found at all, and the the instance that's inside the SDK is found but can't be loaded.
I guess item 1. never worked so it's fine it still doesn't, but 2. seems to be a regression caused by #1349 |
|
I use omnisharp-osx.tar.gz because I am working on macOS. But right now I get omnisharp-linux-x64.tar.gz from release page and tried it out. When I run it through calling |
|
If I start OmniSharp with environment variable |
|
See also #1400 which is about the same issue. |
Do you have I'll create a VM here to see if I can replicate this :) |
|
I don't have |
|
So I've run and here is the .csproj |
|
Similar error is shown for a project generated with |
mickaelistria
changed the title
mickaelistria
changed the title
The SDK 'Microsoft.Net.Sdk' specified could not be found
|
Found out that dotnet/msbuild#2532 (comment) seems to be a valid workaround. |
|
Hello all, We recently added some changes that improve how the sdks are discovered. In vscode could you try setting"omnisharp.path": latest and restarting omnisharp ? |
|
This fixed it for me akshita31! thanks. after setting that value to "latest" I saw on startup |
|
You're breaking something every time. Please test it well. |
We are sorry about that. However, opting into The safer way is to set But of course, the safest way is to simply use the version of the OmniSharp that ships with the given editor extension (VS Code, emacs and so on). Hope this helps. |
|
Thanks for the quick response. Than, please test well what you develop before merging to main. An opensource, non-commercial product doesn't have to be a cracking one. I can not call such kind of things as a bug, they are obviously there when the plugin is getting loaded. If you want to keep this to be used, please be careful while coding and test, test, test and test again. |
Do you have any idea how hard it is to get all the various .NET SDKs, versions of MSBuild, Visual Studio instances, and the rest to play nicely so that when you go to build a project it builds the way you expect? I suspect you don't since as far as I can tell you've never contributed here, but let me tell you it's hard. It's not just a matter of "oh look, there's bug, oh well let's ship anyway!" There are all sorts of independent variables that when combined result in a very, very large set of possible end-user environments and any one of them could end up breaking. Not to mention there's forward compatibility issues when working on build tooling - something that worked fine could break in the future in unanticipated ways when new parts of the build chain are released. In general I would urge you to have a little more understanding and patience towards the maintainers of OSS projects that you consume and use. I applaud @filipw for his helpful and measured response. Suggesting that the folks who give a lot of time to this project are not "careful" or that they don't "test, test, test and test again" is honestly a little insulting. |
|
Sorry all, I think I got misunderstood. I'm a fun of this project and thanks to everyone contributing to it, it's a real success. I'm not trying to ignore the effort behind, I'm just asking for more. Yes, I'm not a contributor of development but as in the nature of using OSS projects somehow we're all becoming testing contributors and being a tester/user must not mean that has to struggle with bugs this regularly. By testing more someone loose a bit more time, but a serious amount of users can save more than that. That's what I just wanted to point and remind this. Please don't take all words personal. |
|
I got the same issue on Linux and I happen to have mono's msbuild manually compiled and isntalled. I added |
|
FYI I ran into a similar issue of projects failing to be loaded, and the error I'm suspecting this has something to do with how |
|
This should be resolved by now. We switched to MsBuild 16.3 and things are generally a lot better. |
I'm trying to use OmniSharp 1.32.9 with LSP support in Eclipse aCute (instead of older versions).
I can connect to OmniSharp through LSP, so the connection part seems fine. But OmniSharp logs a failure that make the LS request never receive a response
After that, no LSP request receives a response.
The
omnisharp/msbuild/15.0/Bin/Microsoft.Build.resources.dllfile is indeed not present in any recent package of omnisharp.The text was updated successfully, but these errors were encountered: