cannot open dotnet cli projects

[lucamorelli]

I'm trying to follow this post http://www.tattoocoder.com/setting-up-asp-net-core-debugging-in-vs-code/

trying to see if I can start tto use vs code, but I'm having problems.

I tried this in 2 configuration: a windows 10 insider build 14328 with vs 15 preview, and mac mini: I installed dot net cli 1.0.0-beta-001598 (the one from the github site), installed the omnisharp extension inside vs code 1.0 and tried to open the HelloMvcApi and I receive an error message "Some projects have troble loading..." this is the omnishapr log

[INFO] Starting OmniSharp at 'c:\test\cli-samples-master\HelloMvcApi'...
[INFO] Started OmniSharp from 'C:\Users\luca\.vscode\extensions\ms-vscode.csharp-0.3.7\bin\omnisharp.cmd' with process id 3324...
[INFORMATION:OmniSharp.Dnx.DnxPaths] Looking for sdk version in 'c:\test\cli-samples-master\global.json'.
[INFORMATION:OmniSharp.Startup] Omnisharp server running using stdio at location 'c:\test\cli-samples-master\HelloMvcApi' on host 6100.
[ERROR:OmniSharp.Dnx.DnxPaths] The specified runtime path 'default' does not exist. Searched locations C:\Users\luca\.dnx\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.dnx\runtimes\kre-clr-win-x86.default
C:\Users\luca\.dnx\packages\KRE-CLR-x86.default
C:\Users\luca\.k\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.k\runtimes\kre-clr-win-x86.default
C:\Users\luca\.k\packages\KRE-CLR-x86.default
C:\Users\luca\.kre\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.kre\runtimes\kre-clr-win-x86.default
C:\Users\luca\.kre\packages\KRE-CLR-x86.default.
Visit https://github.com/aspnet/Home for an installation guide.
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Scanning 'c:\test\cli-samples-master\HelloMvcApi' for DNX projects
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Found project 'c:\test\cli-samples-master\HelloMvcApi\project.json'.
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] No default runtime found
The specified runtime path 'default' does not exist. Searched locations C:\Users\luca\.dnx\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.dnx\runtimes\kre-clr-win-x86.default
C:\Users\luca\.dnx\packages\KRE-CLR-x86.default
C:\Users\luca\.k\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.k\runtimes\kre-clr-win-x86.default
C:\Users\luca\.k\packages\KRE-CLR-x86.default
C:\Users\luca\.kre\runtimes\dnx-clr-win-x86.default
C:\Users\luca\.kre\runtimes\kre-clr-win-x86.default
C:\Users\luca\.kre\packages\KRE-CLR-x86.default.
Visit https://github.com/aspnet/Home for an installation guide.

[INFORMATION:OmniSharp.MSBuild.MSBuildProjectSystem] No solution files found in 'c:\test\cli-samples-master\HelloMvcApi'
[INFORMATION:OmniSharp.ScriptCs.ScriptCsProjectSystem] Detecting CSX files in 'c:\test\cli-samples-master\HelloMvcApi'.
[INFORMATION:OmniSharp.ScriptCs.ScriptCsProjectSystem] Could not find any CSX files
[INFORMATION:OmniSharp.Startup] Solution has finished loading

this happens with both the windows and mac installation_ Am I missing something?

[gregg-miskelly]

You are using the version of the C# extension from the VS Code Gallary. TatooCoder's instructions are to use not-yet-released version from the releases page on this repo.

BTW: Here is our version of the instructions for this. I don't see anything wrong with TatooCoder's instructions, but sometimes a second source can be useful -- http://aka.ms/vscclrdogfood

[DustinCampbell]

Hi @lucamorelli, I just wanted to follow up since this bug has gotten stale over the past couple of months. Since the last contact with us, .NET Core has release 1.0 and we've shipped several versions of the C# extension for Visual Studio Code. I'm curious to know if you're working successfully now.

[ericwj]

I checked out Mvc and I'm fighting VSCode over OmniSharp logs that are very comparable - at least the last four lines and I get no IntelliSense whatsoever.

I tried updating from 1.2.0 to 1.2.1, but after that I'm just wondering there is a tic in the vinyl of sorts...it's stil doing Begin restoring project...I'm serious, it just starting popping up There are unresolved dependencies a massive number of times while I had the impression it was doing dotnet restore all that time... And again I'm looking at Begin restoring project... I didn't touch anything.

[DustinCampbell]

@ericwj: Would you be willing to try the latest beta of the extension and see if that works any better for you?

[ericwj]

It's certainly better but I think there can be done some things to vscode and/or to OmniSharp to make the experience better.

I am now using vscode 1.6.1 and OmniSharp 1.4.1 and it'll at least still open up many popups opening a .NET Core solution with some projects in it. That's not a good experience. They also animate constantly. Pressing the buttons on them to restore packages appears to produce a lot of work and takes a long time. Not sure that is the issue why I commented here to begin with. At least you have to click dismiss or restore on lots and lots of them. So that's a VSCode issue.

The OmniSharp log also hints that the restore can be done automatically, albeit the setting is disabled (it logs Auto Package Restore: false and there is mention of a command line argument to OmniSharp) If it is possible to start a restore manually (e.g. after a git checkout) once but it does it for all projects discovered, that'd be great.

[DustinCampbell]

@ericwj: Could you give our latest release (1.5.2) a spin? In this release we've added a new csharp.suppressDotnetRestoreNotification setting that can be used to control the popups to restore packages. In big projects, it's generally better to just run dotnet restore manually.

[ericwj]

@DustinCampbell I'm on C# 1.5.3 now. I think OmniSharp should just be smarter about this.

The problem is that to avoid the popup spam, there is only one option that is to put that setting in the User settings. I think adding this option is missing the point of the issue.

Trying to restore even a few projects using the (evidently important and recommended) buttons on the popup notifications, it very quickly becomes tedious. As is the fact of having to follow up on 20 popups. Yet just hiding the popups fixes only the popup spam, but keeping red squiggles literally everywhere.

The spam should be dependent on which project is selected, specifically, whether that is a solution file or the root directory as opposed to an individual project.

There's 16 of the latter in my current solution for example. Picking one will make OmniSharp spam a popup for that project and each of its (source) dependencies. That's somewhat reasonable, but it's still too much in my opinion.

It'd be better to popup just one restore notification, for the project selected. Perhaps add a button Restore all so that the user can be explicit about what is needed or wanted. Id be an improvement if clicking Restore would then result in more popups - one for each direct source dependency that needs to be restored. Restore all would simply walk all dependencies and run restore recursively.

If on the other hand the solution folder or a solution file is selected, there needs to be exactly one restore popup, since on the command line running simply dotnet restore in the solution root will restore all projects.

I'm not sure what happens if a folder is opened that OmniSharp sees for the first time. If in that situation there is no project selection, OmniSharp should popup about that, not about restore. Restore only comes into play after picking a project.

That'd however mean that there is no IntelliSense, or weak IntelliSense, for code files that either don't belong to the project selected, or for any code file as long as no project is selected. But only if indeed their containing project requires a restore. Hopefully OmniSharp would be able to deal with that.

I think it doesn't do such a good job putting red squigglies under about everything, for missing predefined types. I think in that situation OmniSharp would be better when it would do what it does during loading: just show syntax highlighting.

In that last situation it'd be better not to use (global) popups for not being able to provide full IntelliSense, but a lightbulb or some other hook that is context specific to the file or its containing project instead of global.

[DustinCampbell]

@ericwj: Thanks for the feedback. The plan is to just fix this so that it doesn't spam but provides a single popup. We're tracking this with #141.

[ericwj]

Id be an improvement if clicking Restore would then result in more popups

This would still be cheap, as clicking Restore a few times you'd still end up with massive spam and mixing pre-existing and new popups in random order. Going project-by-project is a user decision. They could have picked a solution or the directory. So it'd be OK to let the user pay for that for having to pick the project that still needs to be restored manually.

They'd need to wait for a popup to do the restore there, then switch back to the project they wanted to have selected in the first place. This could still be made somewhat easier by providing a lightbulb in code files belonging to the project needing restore to do it, or another context-specific hook, instead of popups.

This is tedious yes, but my guess is that in the fast majority of cases, people will work on a folder or a solution file all at once (for which exactly one restore suffices) or temporarily pick one specific project in which case most of the time most projects are already restored and only require a restore when their project file is edited.

[DustinCampbell]

I'm closing this issue in favor of #141. We never did hear back on the actual original issue and the old DNX is definitely no longer relevant.