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

Properly discover .NET SDK path #768

Closed
DustinCampbell opened this issue Sep 20, 2016 · 19 comments
Closed

Properly discover .NET SDK path #768

DustinCampbell opened this issue Sep 20, 2016 · 19 comments
Assignees
Milestone

Comments

@DustinCampbell
Copy link
Member

When running a design-time build with MSBuild, OmniSharp needs to specify the .NET SDK as the MSBuildExtensionPath. Otherwise, the MSBuild targets imported by .NET Core csproj projects can't be found. Discovering this should happen in one of two ways:

  • MSBuild can be updated to properly locate the .NET SDK. It already has logic to find well-known locations on Windows. This would be ideal because it makes life much easier for MSBuild hosts.
  • Work will need to be done to properly locate this path on Windows and OSX/Linux. This work would happen in OmniSharp.
@DustinCampbell DustinCampbell added this to the 2.0 milestone Sep 20, 2016
@DustinCampbell DustinCampbell self-assigned this Sep 20, 2016
@DustinCampbell
Copy link
Member Author

After discussing this with the MSBuild team, it seems that the recommended solution would be to use the Microsoft.Build.Runtime package when it's available. This will include MSBuild.exe + the basic targets and tasks needed to build a .NET Core project. The work to create this package is tracked here: dotnet/msbuild#1039.

@wjk
Copy link
Contributor

wjk commented Sep 23, 2016

@DustinCampbell Is there any workaround that would tide me over until that issue is resolved? I’m currently getting the following error in my csproj-based solution. It is preventing me from getting any IntelliSense for my csproj projects.

Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "/Users/wjk/.vscode/extensions/ms-vscode.csharp-1.5.0-beta1/out/src/.omnisharp-coreclr/Extensions/15.0/Microsoft.Common.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

@DustinCampbell
Copy link
Member Author

Are these MSBuild-based .NET Core projects (which are still being developed), or are they regular desktop .csproj projects?

@wjk
Copy link
Contributor

wjk commented Sep 23, 2016

Yes, they are .NET Core projects. I find that while the MSBuild-based Core infrastructure is still under development, projects using it build just fine.

@wjk
Copy link
Contributor

wjk commented Sep 23, 2016

I find that if I symlink /usr/local/share/dotnet/sdk/1.0.0-preview3-003618/15.0 to the directory in the error message, the file-not-found error is resolved. However, I then get this error for each .NET Core-based project in my solution, which also prevents me from getting any IntelliSense.

[ERROR:OmniSharp#ProjectFileInfo] The reference assemblies for framework ".NETCoreApp,Version=v1.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
[WARNING:OmniSharp#MSBuild] Failed to process project file '/Volumes/Sources/SunburstApps/src/Win32UI/src/Microsoft.GDIPlus/Microsoft.GDIPlus.csproj'.
/Volumes/Sources/SunburstApps/src/Win32UI/src/Microsoft.GDIPlus/Microsoft.GDIPlus.csproj

@DustinCampbell
Copy link
Member Author

Don't symlink that folder. Instead, here's what you can do:

  1. git clone https://github.com/OmniSharp/omnisharp-roslyn
  2. cd omnisharp-roslyn
  3. Now, tweak the /src/OmniSharp/project.json slightly to comment out OmniSharp.DotNet. You might also need to comment out OmniSharp.DotNetTest
  4. ./build.sh to build OmniSharp
  5. In VS Code, select Preferences -> User Settings and then add the following setting: "omnisharp.path": "/path/to/omnisharp-roslyn/artifacts/publish/OmniSharp/default/netcoreapp1.0/OmniSharp"
  6. Open your project folder in VS Code
  7. At the root, create a new file called omnisharp.json with the following content:
{
    "msbuild": {
        "msbuildextensionspath": "/usr/local/share/dotnet/sdk/1.0.0-preview3-003618"
    }
}

Finally, close and restart VS Code with your project. Good luck!

Note that I typed that directly into GitHub without verifying on my Mac, so your mileage might vary slightly.

@wjk
Copy link
Contributor

wjk commented Sep 23, 2016

@DustinCampbell Unfortunately, I cannot currently test this due to OmniSharp/omnisharp-roslyn#643. If you or anyone else could help me resolve that issue, I would be very appreciative.

@DustinCampbell
Copy link
Member Author

I'm digging in on that issue as well.

@wjk
Copy link
Contributor

wjk commented Sep 24, 2016

@DustinCampbell I've followed the above instructions on my Windows 10 machine. (Due to the issue linked above I still have not yet gotten this to work on my Mac.) Unfortunately, OmniSharp still fails to parse the csproj files; this time it gives me this error:

[WARNING:OmniSharp#MSBuild] Failed to process project file 'c:\Users\William\Documents\GitHub\SunburstApps\src\Win32UI\src\Win32UI.TaskDialogs\Win32UI.TaskDialogs.csproj'.
c:\Users\William\Documents\GitHub\SunburstApps\src\Win32UI\src\Win32UI.TaskDialogs\Win32UI.TaskDialogs.csproj(1,1)
System.TypeInitializationException: The type initializer for 'BuildEnvironmentHelperSingleton' threw an exception. ---> System.InvalidOperationException: Could not determine a valid location to MSBuild. Try running this process from the Developer Command Prompt for Visual Studio.
   at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args)
   at Microsoft.Build.Shared.BuildEnvironmentHelper.Initialize()
   at Microsoft.Build.Shared.BuildEnvironmentHelper.BuildEnvironmentHelperSingleton..cctor()
   --- End of inner exception stack trace ---
   at Microsoft.Build.Internal.Utilities.GetEnvironmentProperties()
   at Microsoft.Build.Evaluation.ProjectCollection.get_EnvironmentProperties()
   at Microsoft.Build.Evaluation.ProjectCollection.InitializeToolsetCollection()
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties, IEnumerable`1 loggers, IEnumerable`1 remoteLoggers, ToolsetDefinitionLocations toolsetDefinitionLocations, Int32 maxNodeCount, Boolean onlyLogCriticalEvents)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties)
   at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create(String projectFilePath, String solutionDirectory, ILogger logger, MSBuildOptions options, ICollection`1 diagnostics) in C:\Users\William\Documents\GitHub\omnisharp-roslyn\src\OmniSharp.MSBuild\ProjectFile\ProjectFileInfo.cs:line 129
   at OmniSharp.MSBuild.MSBuildProjectSystem.CreateProjectFileInfo(String projectFilePath) in C:\Users\William\Documents\GitHub\omnisharp-roslyn\src\OmniSharp.MSBuild\MSBuildProjectSystem.cs:line 258

@DustinCampbell
Copy link
Member Author

At the start of the OmniSharp Log, did it verify that it started the omnisharp that you built and specified in "omnisharp.path"? Also, on Windows, you might specify "net451" rather "netcoreapp1.0" in the path.

@wjk
Copy link
Contributor

wjk commented Sep 24, 2016

Trying the net451 version of OmniSharp does indeed give me better results.

@wjk
Copy link
Contributor

wjk commented Sep 24, 2016

With your steps outlined above followed, VSCode does indeed search for the *.props files in the correct location. Unfortunately, this still doesn't mean that it is successful. I am now getting an error where it is looking for the props files in the sdk\...\14.0 directory, which does not exist on my machine. There is a sdk\...\15.0 directory, but changing the ToolsVersion of the csproj to match this causes OmniSharp to state that the tools version is unsupported. I am using version 1.0.0-preview3-003665 of the .NET CLI. I will open an issue there.

@DustinCampbell
Copy link
Member Author

Yes, this is because the feature is simply not implemented yet. All of this is in active development. 😄

@wjk
Copy link
Contributor

wjk commented Sep 24, 2016

Is this an issue in OmniSharp proper, or should I open an issue/PR on dotnet/cli or even MSBuild?

@DustinCampbell
Copy link
Member Author

DustinCampbell commented Sep 24, 2016

Nope. The reason this isn't working like you'd like is because of this. You're in the right spot. It's just that the work has only just started.

@wjk
Copy link
Contributor

wjk commented Sep 24, 2016

I have some good news to report: Your process outlined above work perfectly — on my Mac. On the Windows PC I still get the above errors. I suppose this is only a bug related to my Windows PC’s unique setup, though, as my Mac opens the 15.0-based projects without complaint.

@DustinCampbell
Copy link
Member Author

Glad to hear it. It's definitely still a work-in-progress though. 😄

@DustinCampbell
Copy link
Member Author

The original plan for this backlog item is no longer relevant. The extension now installs OmniSharp along with a copy of MSBuild to handle csproj proejcts.

@DustinCampbell DustinCampbell modified the milestones: 1.5, 1.6 Nov 16, 2016
@Thaina
Copy link
Contributor

Thaina commented Jun 20, 2017

I still got this issue in 1.10.0

OmniSharp server started wth Mono
Path: /Users/komodo/.vscode/extensions/ms-vscode.csharp-1.10.0/bin/run
PID: 8115

Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "/Users/komodo/.vscode/extensions/ms-vscode.csharp-1.10.0/bin/omnisharp/msbuild/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk

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

No branches or pull requests

3 participants