Skip to content
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

Closed
golf1052 opened this issue Apr 28, 2017 · 19 comments · Fixed by #1451
Closed

OmniSharp server picks up the wrong version of Visual Studio #1438

golf1052 opened this issue Apr 28, 2017 · 19 comments · Fixed by #1451
Assignees
Milestone

Comments

@golf1052
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

Running VSCode from the appropriate VS 2017 instance does work.

@DustinCampbell
Copy link
Member

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
Copy link
Member

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
Copy link
Author

Setting VSINSTALLDIR and VisualStudioVersion worked 👍🏾

@DustinCampbell
Copy link
Member

@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
Copy link
Member

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

@DustinCampbell
Copy link
Member

Thanks man! Appreciated.

@nanhopper
Copy link

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
Copy link
Member

Great point @nanhopper -- thanks!

@DustinCampbell
Copy link
Member

@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
Copy link

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
Copy link
Member

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
Copy link

nanhopper commented Apr 30, 2017 via email

@DustinCampbell
Copy link
Member

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
Copy link
Member

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

@nanhopper
Copy link

nanhopper commented May 2, 2017 via email

@DustinCampbell DustinCampbell self-assigned this May 3, 2017
@DustinCampbell DustinCampbell added this to the 1.10 milestone May 3, 2017
@DustinCampbell
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants