installation fails on Linux when 'non-standard' distribution is used

[lwiechec]

Hi,

I wanted to experiment with omnisharp-roslyn but cannot build it. I am using Peppermint 5 Linux distribution, which itself is a Ubuntu clone. The installation script fails to build the Omnisharp with this message:

⏚ [luke:~/fun/dotnet/omnisharp-roslyn]↥ dev-build-artifacts ± ./build.sh 
Feeds used:
  /home/luke/.nuget/packages/
  https://api.nuget.org/v3/index.json
  https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
  https://dotnet.myget.org/F/cli-deps/api/v3/index.json
  https://www.myget.org/F/xunit/api/v3/index.json

All packages listed in /home/luke/fun/dotnet/omnisharp-roslyn/tools/packages.config are already installed.
Analyzing build script...
Processing build script...
Installing addins...
Compiling build script...
Current platform: Linux (x64)

========================================
Cleanup
========================================
Executing task: Cleanup
Finished executing task: Cleanup

========================================
ValidateMono
========================================
Executing task: ValidateMono
Detected Mono version 5.2.0.215
Finished executing task: ValidateMono

========================================
InstallDotNetCoreSdk
========================================
Executing task: InstallDotNetCoreSdk
dotnet_install: Error: OS name could not be detected: peppermint.5
An error occurred when executing task 'InstallDotNetCoreSdk'.
Error: Failed to Install .NET Core SDK 1.0.4

Any ideas?

[DustinCampbell]

This is because our build uses the .NET Core SDK installer script, which only supports a handful of distros.

There are a couple of changes that I'd like to see that would help address this.

1. Make it possible to build without the .NET Core SDK. Today, we use msbuild from Mono to build OmniSharp on OSX/Linux.
2. Allow the build scripts to run all the way to packaging without running tests. On OSX/Linux, the only reason we download the .NET Core SDK is to prepare test assets and to provide various MSBuild SDKs when running tests.

cc @david-driscoll

[david-driscoll]

If we drop support for project.json (and no longer need 1.0.4) would that help things?

[DustinCampbell]

Not necessarily. We still use the .NET Core SDK to build and publish on Windows.

[lwiechec]

I took a look at the .NET SDK installer script and indeed, it reads /etc/os-release to get the information about the OS. As a quick hack, I could of course edit my copy of this file, as I know that my system is a clone of Ubuntu 14.04. However, this is of course not the best option.

OTOH, on my 'non-standard' system I was able to install newest .NET 2.0 using apt-get, with the procedure described in Microsoft's webpage; maybe the installation method could be changed from the script to that one?

BTW: if I do have .NET Core installer, maybe the build script should not attempt to download it? Here's my output of dotnet --info:

NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     peppermint
 OS Version:  5
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.0/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[ghost]

@lwiechec I encoutered this issue several months ago. As I am using omnisharp-vim I posted a hacky workaround here. In the issue I'm using an older version of dotnet, but the workaround should still be working (I'm using it myself) and I am currently on:

Output dotnet --info:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /opt/dotnet/sdk/2.0.0/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

I don't know if this will be of any help to you, but I thought this might be worth mentioning and could provide you with a (temporary) working solution?

[omajid]

Something like this might fix it, but I cant even get this far in the build process:

diff --git a/build.cake b/build.cake
index f9297f96..23a75c42 100644
--- a/build.cake
+++ b/build.cake
@@ -118,6 +118,12 @@ void InstallDotNetSdk(BuildEnvironment env, BuildPlan plan, string version, stri
         Run("chmod", $"+x '{scriptFilePath}'");
     }

+    if (platform.IsLinux)
+    {
+        argList.Add("--runtime-id");
+        argList.Add("linux-x64");
+    }
+
     var argList = new List<string>();

     argList.Add("-Channel");

Basically, we can use --runtime-id linux-x64 to ask dotnet-install.sh to .NET Core 2.0 in a distro-agnostic way.

[DustinCampbell]

Thanks @omajd! Where does the build fail for you?

[omajid]

I am building on Fedora, where the version of mono is too old and no official mono binaries exist. I tried centos next and filed https://github.com/OmniSharp/omnisharp-roslyn/pull/982.

Anyway, back to the original issue: it looks like my patch is not enough because portable (linux-x64) builds for .NET Core are a 2.0 thing. The 1.x shared runtime required in build.json leads to download failures again. If I comment out the shared runtime in build.json, this works:

./build.sh --target Quick

[DustinCampbell]

@omajid: I think the CentOS builds are actually what you want for Mono on Fedora. I would expect them to work fine.

Good catch with #982! I hadn't spotted that since the Linux CI builds were succeeding on Ubuntu.

The 1.x runtime is only installed to prepare test assets. I had hoped to avoid it, but I think we're going to need to upgrade the projects we use when testing to netcoreapp2.0 projects. That way, we don't need to install the 1.x runtime at all.