OmniSharp.MSBuild.Discovery.MSBuildLocator picks wrong MSBuild path #1094
Comments
|
From @rchande on January 2, 2018 21:48 @DustinCampbell This is interesting. Seems like we need to actually verify that .NET is also installed for a given MSBuild installation. Thoughts on how we should do that? |
|
@rchande: Sorry for the delay here. We'd probably need to test for the appropriate package(s) here: https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.Host/MSBuild/Discovery/Providers/VisualStudioInstanceProvider.cs#L56-L70. |
|
Got hit by this as well. Is there at least a workaround? Env variable? Settings? |
|
👍 would like a real workaround. I just uninstalled the MS Build Tools for now. |
|
Work around: |
|
Succeeded with the workaround from @pquiring, but with copying over targets files: Copy from "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.CSharp.*" to "C:\Users<username>.vscode\extensions\ms-vscode.csharp-1.15.2.omnisharp\1.32.2-beta.21\msbuild\Override" P.S.
|
|
I was not getting autocomplete for Unity3D, but after following @pquiring 's solution, it works -- thanks! |
|
This doens't seem to be solved atleast with vs code 1.27.1 |
|
Same problem in vscode today after omnisharp update |
|
This has just started happening to me as well. I'm wondering if there's an issue with the OmniSharp update. Is there a way to pin to the previous version? |
|
same problem with 1.16.0.omnisharp and vscode 1.27.1 os windows 7 sp1 |
|
This error just started happening after updating. 1.16 omnisharp, vscode 1.27.1 windows10 x64 |
|
This started happening for me after the 1.16.0 update, too:
|
|
@UncleInf @johnnyreilly @boris-741 @LuizPelegrini @zvinless I'm sorry you're running into issues. From what's reported, it sounds like there's an issue with the "standalone" MSBuild shipped with OmniSharp on Windows. There are a couple of workarounds you can do while we investigate:
Thanks for your patience--we are actively investigating. |
|
Also @UncleInf @johnnyreilly @boris-741 @LuizPelegrini @zvinless, if you could set |
Downgrading omnisharp to 1.15 and disabling extension auto update worked for me! Thanks for the support @rchande ! |
|
@rchande thanks for the help! I think I'm actually running into a different issue, but here's my log. I noticed the warnings at the end after the extensions update. The actual behavior in VSCode is kind of erratic. Let me know if there is a different place where I should post this. |
|
@rchande - atached. I did change logging level to debug, but it seems that I don't get more messages. |
|
Here's my log: |
|
@UncleInf @johnnyreilly @boris-741 @LuizPelegrini @zvinless We believe we have identified the cause of the "GetReferenceNearestTargetFrameworkTask" issue and we've created a beta of the C# extension that includes the fix. Please install the beta VSIX (https://github.com/OmniSharp/omnisharp-vscode/releases/download/v1.16.1-beta1/csharp-1.16.1-beta1.vsix) and let us know if that resolves the problem |
|
I'd love to give you some feedback @rchande but I can't get the VSIX to work - I'm getting a "Windows cannot open this sort of file (.vsix)" error 😢 |
|
@johnnyreilly You can install the VSIX by going to the extensions pane in VS Code and clicking the ellipsis button -> Install from VSIX |
|
Thanks - will attempt Done. Just firing up now |
|
|
Having the same issue using |
|
I'm having the same issue: dotnet --info Startup log: What is the recommended work around? |
|
@aydjay rename directory |
|
I've had this problem in OSX. Went to user settings in VS Code and disabled "Global Mono". It loads the |
|
I've had this issue as well. I'm toying with pushing VS Code + Omnisharp instead of Visual Studio Express for a project I am working on, but am really being put off by this bug. A proper workaround where I could specify where MSBuild lives would be much better. |
|
I ran into this problem in a .NET Core project, the initial symptoms were many compile errors that boiled down to With VS 2017OmniSharp log:Result:Error reported in VS Code: After installing VS 2019OmniSharp log:Result:It works. Adding I was a curious about this and tried to dig a bit to find out why this happens or what other options are there to control the choice of MSBuild to be used. Seems like it's on purpose that the builtin MSBuild is sorted lower than VS ones (source), which for me seems strange since the current builtin one is MSBuild 16, while VS2017 is MSBuild 15. Upon seeing this method I see now that it's also not a coincidence that VS 2019 / MSBuild 16 was picked over MSBuild 15; seems like the "pick 16 over 15" rule wouldn't apply to the builtin MSBuild, though, since it gets a lower score. That is very unfortunate, seems like there is a dependency on MSBuild 16 but MSBuild 15 can be picked if you happen not to have a newer VS, which in my case caused some lost time in debugging all of this. |
|
related: #1545 |
|
I have the same problem. Here's the output of the build locator: I've got .NET Core 3.0 SDK installed as well as multiple 2.x versions and VS 2019. The VS 2019 MSBuild probably gets the priority and as a result, I'm getting the following error: Update: Upgrading VS to the latest (16.3.x) version fixes the issue. |
|
Date is now almost 2020 and we still are facing same issue.for sake of god tell us how to specify msbuild path manually. |
|
please post your OmniSharp log so that we can have a look at what happens in your environment - what appears to be the same issue, is actually a combination of multiple things |
|
Following is log from my Starting OmniSharp server at 12/23/2019, 1:35:56 PM OmniSharp server started. Assembly loaded: OmniSharp.Cake No solution files found in 'c:\Users\BEHNAM\Desktop\dnt' Trimmed for sake of brevity |
|
thanks according to your log OmniSharp sees 3 MsBuild instances: OmniSharp will actually always select Visual Studio 2019 if you have it, but your version is |
|
I did as pquiring's suggestion this time it complains |
Thanks @filipw , but this is why i am here.we should be able to choose which build tool to use shouldn't we?besides i forced Omnishrap to pick it's standalone build tool using pquiring's suggestion (check my previous comment) but still i faced another problem. furthermore VSCode (and omnisharp) are both separate product from |
Please do not use old workarounds because you will only get into trouble. These workarounds are not supported since that logic is internal. If you start messing up the paths it can get even worse.
The MsBuild support offered by VS is a lot more sophisticated than the embedded MsBuild that comes with OmniSharp so if VS is present on your machine OmniSharp will use it. .NET Core 3.1 has a breaking change where it doesn't work with MsBuild < 16.3 so having an older build of VS at the same machine leads to an issue.
It only installs beta builds from master if you set My recommendation is to remove |
this is supported already, however it's a very advanced feature. I would only recommend using it for testing scenarios and OmniSharp development, or supporting more esoteric Linux-based OS where discovery doesn't work well. You can read about it here #1545 (comment) For regular use cases it is not needed and it should be enough to do not have outdated VS or have no VS at all on the machine. |
|
I will close this issue to not create further confusion. The MsBuild instance scoring has been improved in the recent months.
If you have further problems, please open a new issue. |
@filipw This doesn't sound like a good solution. Why would OmniSharp choose something smaller than 16.3 if it can't use it? Especially when it ships a compatible embedded MsBuild 16.3? The selection logic still sounds flawed to me. I'm willing to put some time into a PR that tries to do something like respect the current selection preference order, but skip what is not compatible (i.e. skip versions smaller than 16.3, 16.4 in beta), do you think that makes sense? |
the instance is currently selected before the target framework is known (since, we need the msbuild instance to read the csproj file in the first place). Since VS2019 msbuild instance is in most cases the best choice, we didn't want to explicitly exclude <16.3 yet as that might be detrimental for other (.NET Core 3.x) users. However as 16.3+ becomes more and more popular it might be a good idea to make that a cut off point. We already did exclude VS2017 completely from the selection for that very reason. |
|
OK so my last take on this :) I am assuming that the embedded MSBuild works for all target frameworks; if it doesn't then I guess there is really no better way :( |
|
unfortunately the embedded msbuild is not functionally equivalent to that what ships with mono or VS itself, this is particularly relevant for example for unity projects or projects with custom SDK, and should normally be the last resort fallback. just like we eliminated VS2017 from being discovered though, I can imagine we will soon eliminate VS2019 <16.3 too which will make this issue go away. That said, I don't think it's a terrible assumption that if you have VS2019 installed and want to do .NET Core 3.1 on your machine, your VS2019 will be updated accordingly. |
|
I having trouble to charge intellisense on VSCODE to Unity. I used |
after struggling for couple of days finally this solution worked out for me. Thank you |
|
Ok wtf i just installed VS again (3 years later) i need for a project and it broke all my VS Code projects. Any work being done on this matter ? Why the f*** cant we choose which MSBuild will be used 1: Visual Studio Community 2019 16.11.31624.102 16.11.0 OR 2: StandAlone 17.0.0 |
|
you can override the used MSBuild using |
|
If VS is installed on the machine, it will be preferred over the bundled MSBuild. You can disable that and force OmniSharp to use only its own MSBuild by adding an omnisharp.json file to the root of your project with the content |
and others
From @pquiring on December 25, 2017 17:27
Environment data
dotnet --infooutput:.NET Command Line Tools (2.1.3)
Product Information:
Version: 2.1.3
Commit SHA-1 hash: a0ca411ca5
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Apps\dotnet\sdk\2.1.3\
Microsoft .NET Core Shared Framework Host
Version : 2.0.4
Build : 7f262f453d8c8479b9af91d34c013b3aa05bc1ff
VS Code version: 1.19.1
C# Extension version: 1.13.1
Steps to reproduce
Install .Net Core standalone
Install VS Code
Install VS Build Tools with VC++ only (not .NET component)
or
Install VS IDE with VC++ only (not .NET component)
Open .csproj in VS Code.
Expected behavior
OmniSharp runs
Actual behavior
OmniSharp tries to use MSBuild from VC++ and fails.
If I install .NET in VS Build Tools it works.
How can I force OmniSharp to ignore MSbuild environments that do NOT have .NET included?
Thanks.
Copied from original issue: dotnet/vscode-csharp#1941
The text was updated successfully, but these errors were encountered: