OmniSharp server picks up the wrong version of Visual Studio

[golf1052]

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:

.NET Command Line Tools (1.0.3)

Product Information:
 Version:            1.0.3
 Commit SHA-1 hash:  37224c9917

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.3

VS Code version: 1.11.2
C# Extension version: 1.9.0

Steps to reproduce

1. Download and install Visual Studio with .NET Core support.
2. Download and install Visual Studio preview without .NET Core support. (I have Visual Studio Preview setup with only Python support).
3. Create a new .NET Core project using dotnet new console.
4. Open the project using VSCode.

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.

Starting OmniSharp server at 4/28/2017, 3:04:46 AM
    Target: c:\Users\Sanders\dotnettest

OmniSharp server started
    Path: C:\Users\Sanders\.vscode\extensions\ms-vscode.csharp-1.9.0\bin\omnisharp\OmniSharp.exe
    PID: 22872

OmniSharp: -s c:\Users\Sanders\dotnettest --hostPID 13324 --stdio DotNet:enablePackageRestore=false --encoding utf-8 --loglevel information formattingOptions:useTabs=false formattingOptions:tabSize=4 formattingOptions:indentationSize=4
[info]: OmniSharp.Startup
        Omnisharp server running using Stdio at location 'c:\Users\Sanders\dotnettest' on host 13324.
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Initializing in c:\Users\Sanders\dotnettest
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Auto package restore: False
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Update workspace context
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Resolving projects references
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
        MSBuild will use local Visual Studio installation.
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
        No solution files found in 'c:\Users\Sanders\dotnettest'
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to process project file 'c:\Users\Sanders\dotnettest\dotnettest\dotnettest.csproj'.
c:\Users\Sanders\dotnettest\dotnettest\dotnettest.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.  c:\Users\Sanders\dotnettest\dotnettest\dotnettest.csproj
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(IElementLocation elementLocation, String resourceName, Object arg0)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImportsFromUnescapedImportExpression(String directoryOfImportingFile, ProjectImportElement importElement, String unescapedExpression, Boolean throwOnFileNotExistsError, List`1& imports)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
   at Microsoft.Build.Evaluation.Project.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.ProjectCollection.LoadProject(String fileName, IDictionary`2 globalProperties, String toolsVersion)
   at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create(String projectFilePath, String solutionDirectory, ILogger logger, MSBuildOptions options, ICollection`1 diagnostics, Boolean isUnityProject)
   at OmniSharp.MSBuild.MSBuildProjectSystem.CreateProjectFileInfo(String projectFilePath, Boolean isUnityProject)

[info]: OmniSharp.Script.ScriptProjectSystem
        Detecting CSX files in 'c:\Users\Sanders\dotnettest'.
[info]: OmniSharp.Script.ScriptProjectSystem
        Could not find any CSX files
[info]: OmniSharp.Startup
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[info]: OmniSharp.Startup
        Configuration finished.

This worked fine before I had the Preview version installed.

[DustinCampbell]

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.

[DustinCampbell]

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.

cc @rainersigwald, @AndyGerlicher

[golf1052]

Running VSCode from the appropriate VS 2017 instance does work.

[DustinCampbell]

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"

[rainersigwald]

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).

[golf1052]

Setting VSINSTALLDIR and VisualStudioVersion worked 👍🏾

[DustinCampbell]

@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.

[rainersigwald]

That's true @DustinCampbell; I filed dotnet/msbuild#2029 so it doesn't get forgotten again.

[DustinCampbell]

Thanks man! Appreciated.

[nanhopper]

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!

[DustinCampbell]

Great point @nanhopper -- thanks!

[DustinCampbell]

@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>"
    }
}

[nanhopper]

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?

[DustinCampbell]

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

[nanhopper]

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> .

[DustinCampbell]

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(...).

[rainersigwald]

The issue that @nanhopper is reporting will go away after dotnet/msbuild#1697 is fixed. Setting MSBuildSDKsPath is a good workaround for now.

[nanhopper]

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> .

[DustinCampbell]

This should be addressed with OmniSharp/omnisharp-roslyn#847, which sets MSBuildSDKsPath to the .NET CLI.