Debian vs. Windows data incompatibility

[mcmonkey4eva]

Steps to reproduce

$ dotnet restore
Project file does not exist.
$ dotnet restore project.json
/path/to/project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.

Generic not-touched package.json from the command to create a new empty site that runs fine on Windows.

Expected behavior

Project should run restore cleanly without issue, as it does on Windows.

Actual behavior

Errors!

Environment data

dotnet --info output:

Product Information:
 Version:            1.0.0-preview5-004232
 Commit SHA-1 hash:  355b6233cb

Runtime Environment:
 OS Name:     debian
 OS Version:
 OS Platform: Linux
 RID:         debian.8-x64
 Base Path:   /bin/sdk/1.0.0-preview5-004232

Running headless Debian stretch/sid.

Fair note

I had a bit of trouble installing the .NET CLI SDK, and may have mucked something up there? Instructions for installing on Debian (literally one of the most popular server platforms out there) are next to nonexistent.

[mcmonkey4eva]

Welp. $ dotnet migrate is apparently required.

So new question:
Why does my Windows .NET-CLI install I did a few days ago give me a project.json based project, but Debian servers literally apparently require .csproj based projects?

EDIT: Also, Windows produced a 1.1.0 versioned file, whereas Debian only has 1.0.1?

EDIT2: Also, I seem to have to run dotnet restore every time before I dotnet run or it'll mess up the files... and even then, it still fails to run once in a while...

[dasMulli]

The preview 3-5 versions are msbuild based and use csproj instead of project.json. And they default to .net core 1.0..
You probably have a preview2-1- version installed on windows (e.g. through vs2015 + tooling) and a bleeding edge CI build on your Debian machine (vs 2017 rc shipped with a preview3, no "official" preview5 build has been published yet).

You can however install multiple versions of the CLI side-by-side. You can download the latest project-json based SDK from http://dot.net and create a global.json file in your project's root folder to fix the version used:

{
    "sdk": {
        "version": "1.0.0-preview2-1-003177"
    }
}

[mcmonkey4eva]

Hm... You are correct.
However, since I'm a nutjob, I chose to apply your solution in reverse: Grabbed a dev build of .NET Core CLI for my local windows installation.
... now how do I get OmniSharp working with the new project file in VS Code? >.>
It says:
[ERROR:OmniSharp#ProjectFileInfo] The target "ResolveReferences" does not exist in the project.

[dasMulli]

@mcmonkey4eva You can get prerelease versions of omnisharp-vscode here on GitHub: https://github.com/OmniSharp/omnisharp-vscode/releases
Also, Visual Studio 2017 RC has been updated yesterday to support the updated style of csproj files (the ones with <Project Sdk="Microsoft.NET.Sdk">...). The RC however uses preview4-* versions of the CLI/SDK but there aren't many differences yet.

[mcmonkey4eva]

1.6.0-beta3 still says [ERROR:OmniSharp#ProjectFileInfo] The target "ResolveReferences" does not exist in the project.
(Path is ....\.vscode\extensions\ms-vscode.csharp-1.6.0-beta3\bin\omnisharp\OmniSharp.exe so it's loaded the correct version...) I think something got missed by the migrate potentially? Specifically, a ResolveReferences Target in the csproj?

[blackdwarf]

@mcmonkey4eva can you share your project?

[livarcocc]

I suspect that you have a mismatch of versions across your system.

You have to match CLI + Omnisharp to support either project.json or csproj. I mean, the version of the CLI that you are using and the version of omnisharp that you are using need to support project.json, if that's what you are trying to use. And likewise for csproj.

Though, to be honest, I don't know what is the state of Omnisharp with regards to csproj support.

[mcmonkey4eva]

One whole csproj file, fresh off the VSCode, http://pastebin.com/VBxaXzwA

[blackdwarf]

/cc @DustinCampbell for the VS Code question

[dasMulli]

@mcmonkey4eva since this is a web app, you will want to use the web-sdk:
Sdk="Microsoft.NET.Sdk.Web"
This should allow you to remove the <ItemGroup> elements. But doesn't explain vscode behavior.

[DustinCampbell]

@livarcocc isn't quite right. You don't need to match up OmniSharp with the version of the CLI. However, the .csproj projects produced by the CLI are definitely a bit ahead of OmniSharp. The Sdk attribute isn't supported by OmniSharp yet, but referencing the Sdk as a PackageReference is supported. I've just merged this fairly significant PR which will allow the Sdk attribute to work in OmniSharp: OmniSharp/omnisharp-roslyn#705. Watch the C# extension repo for a new beta (hopefully tomorrow). That beta should support projects produced by CLI preview2, preview3, preview4, and preview5.

[livarcocc]

@DustinCampbell my bad. Is there a good way to keep track of what is compatible? Or maybe publish it? And just for my own understanding, VSCode will work with csproj even if the CLI is say, preview2?

[DustinCampbell]

That's right. In general, so long as MSBuild is backward-compatible with updates (like it is for Sdk attributes vs. Sdk package references), VS Code will continue to work. It's usually just a matter of tasks and targets after all. 😄

We're leaving the preview2 support in place for the foreseeable future to allow users to transition. It's not a nice experience when an update to an extension in VS Code breaks on the project you've been working on.

[livarcocc]

@DustinCampbell I didn't mean VS Code would stop work. I was talking about VS Code working with CSProj and/or project.json depending on what CLI you have in place.

[DustinCampbell]

Right I understood. The C# extension for VS Code does not actually depend much on the CLI. OmniSharp carries its own copy of MSBuild and SDKs for understanding CSProj. The only dependency that the extension has on the CLI is shelling out to "dotnet build" and "dotnet restore".

[dasMulli]

@DustinCampbell so there currently is no way to use daily SDK builds with vscode? like setting/overriding the sdk path for msbuild? (or manually replacing omnisharp's version in the download location)

[DustinCampbell]

@dasMulli: When you say "SDK" -- you mean SDKs like Microsoft.NET.Sdk and not the .NET Core SDK, correct? If you meant the former, the only way to stick with daily builds is to manually replace them in the OmniSharp download location.

[mcmonkey4eva]

Hey look, a beta4!
Hey look, it made things worse! :(

[INFORMATION:OmniSharp#MSBuild] No solution files found in 'c:\Github\FreneticDocs'
[WARNING:OmniSharp#MSBuild] Failed to process project file 'c:\Github\FreneticDocs\FreneticDocs.csproj'.
c:\Github\FreneticDocs\FreneticDocs.csproj(1,1)
System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at Microsoft.Build.Shared.FileUtilities.MakeRelative(String basePath, String path)
   at Microsoft.Build.Evaluation.Evaluator`4.ThrowForImportedProjectWithSearchPathsNotFound(ProjectImportPathMatch searchPathMatch, ProjectImportElement importElement)
   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.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) in C:\Projects\omnisharp-roslyn\src\OmniSharp.MSBuild\ProjectFile\ProjectFileInfo.cs:line 106
   at OmniSharp.MSBuild.MSBuildProjectSystem.CreateProjectFileInfo(String projectFilePath) in C:\Projects\omnisharp-roslyn\src\OmniSharp.MSBuild\MSBuildProjectSystem.cs:line 365

[DustinCampbell]

Thanks @mcmonkey4eva! I ran into this error as well, but only when running some tests on AppVeyor on Windows. However, those tests passed locally. I had a couple of leads to investigate:

1. Does it have something to do with Windows 8.1 (which AppVeyor runs on)?
2. Does it happen because Visual Studio isn't on the box?

I was going to look at both of these angles this morning. Would any of these seem relevant to your scenario? Could you post your whole OmniSharp log when this fails?

[DustinCampbell]

Well, I couldn't reproduce the issue with 1.6-beta4 on Win8.1-x64 (same as AppVeyor) with no Visual Studio installed. I installed the latest VS Code with 1.6-beta4 of the C# extension, and the most recent .NET CLI preview5. I tried opening projects produced with 'dotnet new' and 'dotnet new -t web' and did not encounter the UriFormatException.

[DustinCampbell]

Note: I have a fix for this. I should have another beta available within the next hour or two.

[DustinCampbell]

@mcmonkey4eva: I've released v1.6-beta5, which should fix this issue for it. Feel free to file an issue over at https://github.com/OmniSharp/omnisharp-vscode/issues if it gives you any trouble.

[mcmonkey4eva]

Assuming the remainder of this is an Omnisharp-VSCode issue, I'm move the issue to dotnet/vscode-csharp#1050 for the moment.

[DustinCampbell]

Just wanted to let anyone else tracking the VS Code problem on this thread that we were able to get to the bottom of it. The latest beta of the C# extension should work properly.