-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OmniSharp server picks up the wrong version of Visual Studio #1438
Comments
This is actually an MSBuild issue. In this situation, we've determined that VS 2017 is on the box and allowed MSBuild to locate itself properly. However, in the case of multiple versions of VS 2017, it just picks one. Try opening VS Code from the Developer Command Prompt associated with the correct instance of VS 2017. |
Here's where MSBuild just picks one instance of VS when there are many installed: https://github.com/Microsoft/msbuild/blob/11119f63f8c612874c39ca020d7ebd3377ec49af/src/Shared/BuildEnvironmentHelper.cs#L246. |
Running VSCode from the appropriate VS 2017 instance does work. |
I'm glad to hear that it's easily worked around. If you wanted to be fancy, you could set the environment variables that MSBuild cares about from the Developer Command Prompt yourself: "VSINSTALLDIR" and "VisualStudioVersion" |
MSBuild's specification for finding VS installation is at dotnet/msbuild#1461. Unfortunately, it's fairly difficult to divine which of several possible VS installations is the "right" one for a given project, so we need help (in the form of the environment variables). |
Setting |
@rainersigwald: I notice that the issue you linked was closed because it was fully implemented. However, there's no warning when the number of VS installations is > 1. |
That's true @DustinCampbell; I filed dotnet/msbuild#2029 so it doesn't get forgotten again. |
Thanks man! Appreciated. |
I had a similar issue since the 1.9.0 update, on a devbox with only the VS 2107 Build Tools installed. I worked around it by doing a set MSBuildSDKsPath=C:\Program Files\dotnet\sdk\1.0.1\Sdks before opening the project, but I think this is still a small regression. Thanks for the awesome extension! |
Great point @nanhopper -- thanks! |
@nanhopper: another solution here would be to create an omnisharp.json file in the root folder opened in VSCode with the following content: {
"msbuild": {
"MSBuildSdksPath": "<your path>"
}
} |
I tried that, but it didn't work. When looking at debug logs and here it does not seem that the file is passed on as args to the omnisharp server. What am I missing? |
That file gets picked up by the OmniSharp server if it's in the CWD (your VS Code workspace path). You can also create one globally. See, Configuration Options on the omnisharp-roslyn wiki. cc @filipw |
The file does get picked up as you say but it would seem it only accepts
formatting options?
https://github.com/OmniSharp/omnisharp-roslyn/blob/c786717208d4167fc584d12bce4a6b3099cb09ae/src/OmniSharp.Abstractions/Options/OmniSharpOptions.cs
In any case, don't worry about it, as I have a workaround :)
…On Sat, Apr 29, 2017 at 6:49 PM, Dustin Campbell ***@***.***> wrote:
That file gets picked up by the OmniSharp server if it's in the CWD (your
VS Code workspace path). You can also create one globally. See, Configuration
Options
<https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options>
on the omnisharp-roslyn wiki.
cc @filipw <https://github.com/filipw>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKGNk3X0Qjmaw-uYcyTaatxw9gFiVqzCks5r02olgaJpZM4NLIJn>
.
|
It doesn't just allow formatting options. Those are just the only options that are statically included. The msbuild options are read dynamically in OmniSharp.MSBuild\MSBuildProjectSystem.Initialize(...). |
The issue that @nanhopper is reporting will go away after dotnet/msbuild#1697 is fixed. Setting |
OK, thanks Rainer!
…On Mon, May 1, 2017 at 7:29 PM, Rainer Sigwald ***@***.***> wrote:
The issue that @nanhopper <https://github.com/nanhopper> is reporting
will go away after dotnet/msbuild#1697
<dotnet/msbuild#1697> is fixed. Setting
MSBuildSDKsPath is a good workaround for now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKGNk6M0uqr1cdT-fY2Dx9dTCsPNEuewks5r1haRgaJpZM4NLIJn>
.
|
This should be addressed with OmniSharp/omnisharp-roslyn#847, which sets MSBuildSDKsPath to the .NET CLI. |
It looks like if Visual Studio and Visual Studio Preview are installed the OmniSharp server will always try to the Preview version of the local Visual Studio installation for MSBuild.
Environment data
dotnet --info
output:VS Code version: 1.11.2
C# Extension version: 1.9.0
Steps to reproduce
dotnet new console
.Expected behavior
C# project loads properly.
Actual behavior
C# extension reports:
Warning: Some projects have trouble loading. Please review the output for more details.
Here's my output log.
This worked fine before I had the Preview version installed.
The text was updated successfully, but these errors were encountered: