[.NET Core 2.0] Add CentOS based stack for .NET Core 2.0 #125

omajid · 2017-08-22T20:04:17Z

Can we add/switch to a CentOS (or RHEL) based .NET Core 2.0 stack? RHEL (and CentOS) builds are being built from source rather than the binary Microsoft distributes for Ubuntu and other platforms.

cc @dharmit

dharmit · 2017-08-23T09:07:00Z

@omajid It'll take a day or two before the RPMs hit CentOS repos. I'll start working on this once the RPMs are in.

ghost · 2017-09-04T12:10:59Z

@dharmit will you do it or do you expect me to provide a PR?

l0rd · 2017-09-28T09:29:48Z

Hello @dharmit what is the status for this issue? Can we help?

dharmit · 2017-09-28T12:19:53Z

@l0rd this is stuck on dotnet 2.0 RPMs being made available on a released repo. They're available on testing repo only at the moment.

l0rd · 2017-09-28T23:45:21Z

Thanks @dharmit. Can we do an exception for .NET Core 2.0 and use testing repo for this image? @kbsingh what do you think?

dharmit · 2017-09-29T07:22:06Z

@l0rd the RPMs should be available shortly. Since we've waited for quite long already, I'd recommend we give it a day more. Otherwise, I'll get the image up with testing RPMs for time being.

omajid · 2017-10-04T14:55:31Z

Thanks to @kbsingh we now have .NET Core RPMs as part of CentOS:

yum install centos-release-dotnet
yum install rh-dotnet10
scl enable rh-dotnet20 bash
dotnet --info

ghost · 2017-10-05T04:18:35Z

We'll need dotnet in $PATH since languageserver will call it. But I think I'll figure this out.

dharmit · 2017-10-05T06:22:56Z

@eivantsov that should be in the path because of cat /opt/rh/rh-dotnet20/enable >> /home/user/.bashrc instruction in the Dockerfile. When we spin up a container, doing dotnet --version just works. Does that help for language server purpose?

ghost · 2017-10-05T07:29:33Z

@dharmit adding it to ~/.bashrc does not always work when doing execs. It should be rather added to PATH in Dockerfile ENV instruction.

dharmit · 2017-10-05T12:13:23Z

@eivantsov I've updated the PR to have the instruction: ENV PATH /opt/rh/rh-dotnet20/root/usr/bin:/opt/rh/rh-dotnet20/root/usr/sbin${PATH:+:${PATH}} which is basically same as that in /opt/rh/rh-dotnet20/enable.

Before:

$ docker run -it --rm registry.centos.org/che-stacks/centos-dotnet20 dotnet --version
/usr/bin/docker-latest: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"dotnet\": executable file not found in $PATH".
ERRO[0005] error getting events from daemon: context canceled

After:

$ docker run -it --rm registry.centos.org/che-stacks/centos-dotnet20 dotnet --version
2.0.0

omajid · 2017-10-05T12:50:33Z

@dharmit Can we someone invoke scl enable directly? (Or by sourcingscl_enable file)? There are known differences between adding the binary to PATH vs invoking scl. Some differences include:

Telemetry: scl enable disables this, invoking /opt/rh/rh-dotnet20/root/usr/bin/dotnet doesnt.
Differnet libcurl: Invoking /opt/rh/rh-dotnet20/root/usr/bin/dotnet uses the libcurl under /usr/lib64, which is an older version linked against nss rather than openssl. It also means some features (such as client certificates) in .NET Core will not work.

The official containers (repo here) published for RHEL work around this by:

Adding an ENTRYPOINT that always gets called
Adding environment variables so bash can invoke scl enable automatically
Making the entrypoint invoke a shell script so a bash instance is spawned and reads those environment variables to run scl_enable.

Now users can do dotnet --info (for example) and it works without any other commands.

In general, it would be great if you could stay close to https://github.com/redhat-developer/s2i-dotnetcore/blob/master/2.0/runtime/Dockerfile.rhel7 to pick up many fixes and features.

ghost · 2017-10-05T13:56:27Z

@omajid @dharmit I have just tried dotnet installed in the way you have suggested and discovered that onmisharp languageserver does not work with this package. If I install .net as per https://www.microsoft.com/net/core#linuxcentos everything's ok.

omajid · 2017-10-05T14:11:16Z

Sounds like dotnet/source-build#125

ghost · 2017-10-05T14:21:24Z

Yes, it does. Should we wait for the fix then?

omajid · 2017-10-05T14:24:31Z

Okay. I don't have an ETA for a fix right now.

omajid · 2017-10-05T14:29:34Z

@eivantsov What version/release/binary of omnisharp are you using?

Hey, @mickaelistria! I seem to recall you using the source-built dotnet packages on Fedora 26 and it worked with aCute/omnisharp in your experiments. Do you have any idea about why omnisharp wont work on CentOS? Does it have to do with bundled mono by omnisharp folks?

mickaelistria · 2017-10-05T14:35:26Z

I tried the packages, but as OmniSharp was asking for a more recent version in order to drop the dependency on mono, I switched to the binary archive provided by the dotnet-core project. I haven't try the Fedora package for a while.

ghost · 2017-10-06T06:40:11Z

@omajid this is what's currently used.

  "name": "omnisharp-client",
  "omnisharp-roslyn": "v1.22.0"

...

"_id": "omnisharp-client@7.0.7"

Tried it with 1.23 too - same result.

omajid · 2017-10-06T15:00:14Z

@eivantsov Thanks. I manged to reproduce this locally with omnisharp-roslyn + omnisharp-emacs too.

tmds · 2017-10-19T15:02:06Z

@eivantsov To get omnisharp to work with source-build .NET Core on Fedora I'm adding a symlink so mono uses the netcoreapp1.0 assembly (which is present) instead of trying to use the net46 assembly (which isn't). With this symlink vscode loads my project and provides intellisense. Can you add that to the Dockerfile and see how it works for you?

ln -s /opt/rh/rh-dotnet20/root/usr/bin/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/netcoreapp1.0 /opt/rh/rh-dotnet20/root/usr/bin/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/net46

ghost · 2017-10-20T09:17:38Z

@tmds thanks! will give it a shot now

l0rd · 2017-10-23T17:58:21Z

@tmds

/opt/rh/rh-dotnet20/root/usr/bin/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/netcoreapp1.0

doesn't exist. Did you mean

/opt/rh/rh-dotnet20/root/usr/lib64/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/netcoreapp1.0

?

Anyway adding:

sudo ln -s /opt/rh/rh-dotnet20/root/usr/lib64/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/netcoreapp1.0 /opt/rh/rh-dotnet20/root/usr/lib64/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/net46

doesn't work for me.

tmds · 2017-10-23T18:06:59Z

Did you mean

Yes

sudo

Why sudo? Is this in a Dockerfile?

doesn't work for me.

What does it do?
e.g. when I use this in vscode, I can navigate to the "Omnisharp log" and I see the project not loading due to the missing net46. Then when I add the symlink, the project loads fine.
Is there some logging you can share?

l0rd · 2017-10-24T00:45:14Z

@tmds I am not able to see OmniSharp logs when starting the LS using Che but when I try to start it manually:

SRC=/projects/dotnet-web-simple
OS_CLIENT_PID=532
./OmniSharp --stdio --zero-based-indices \
    -s ${SRC} --hostPID ${OS_CLIENT_PID} \
    --dotnet:enablePackageRestore=true -v

I can see the following errors in the logs:

{
    "Event": "log",
    "Body": {
        "LogLevel": "ERROR",
        "Name": "OmniSharp.MSBuild.ProjectFile.ProjectFileInfo",
        "Message": "The \"ReportAssetsLogMessages\" task failed unexpectedly.\nSystem.IO.FileLoadException: Could not load file or assembly 'NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)\nFile name: 'NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35'\n   at Microsoft.NET.Build.Tasks.ReportAssetsLogMessages.ExecuteCore()\n   at Microsoft.NET.Build.Tasks.TaskBase.Execute()\n   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()\n   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()"
    },
    "Seq": 23,
    "Type": "event"
}
{
    "Event": "log",
    "Body": {
        "LogLevel": "ERROR",
        "Name": "OmniSharp.MSBuild.ProjectFile.ProjectFileInfo",
        "Message": "The \"CheckForTargetInAssetsFile\" task failed unexpectedly.\nSystem.IO.FileLoadException: Could not load file or assembly 'NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)\nFile name: 'NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35'\n   at Microsoft.NET.Build.Tasks.CheckForTargetInAssetsFile.ExecuteCore()\n   at Microsoft.NET.Build.Tasks.TaskBase.Execute()\n   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()\n   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()"
    },
    "Seq": 24,
    "Type": "event"
}

l0rd · 2017-10-24T00:55:05Z

For testing I am using dotnet-web-simple and OmniSharp v1.22.0

tmds · 2017-10-24T07:18:49Z

For testing I am using dotnet-web-simple and OmniSharp v1.22.0

I was not sure what package to pick for v1.22.0. So I went to the latest version v1.25.0 and used omnisharp-linux-x64.tar.gz. (This is the stdio package, there is also an http package.)

Then on RHEL7 (not in docker), I added the symlink (net46 -> netcoreapp1.0) and created a console project at /tmp/che125/console.

Starting OmniSharp picks up the project:

$ ./run -s /tmp/che125/console --stdio
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.DotNet.DotNetProjectSystem","Message":"Initializing in /tmp/che125/console"},"Seq":1,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.DotNet.DotNetProjectSystem","Message":"Auto package restore: False"},"Seq":2,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.DotNet.DotNetProjectSystem","Message":"Update workspace context"},"Seq":3,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.DotNet.DotNetProjectSystem","Message":"Resolving projects references"},"Seq":4,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.MSBuild.MSBuildProjectSystem","Message":"Omnisharp will use local MSBuild.\n    MSBUILD_EXE_PATH: /tmp/che125/omnisharp2/omnisharp/msbuild/MSBuild.dll\n    MSBuildExtensionsPath: /tmp/che125/omnisharp2/omnisharp/msbuild\n    RoslynTargetsPath: /tmp/che125/omnisharp2/omnisharp/msbuild/Roslyn\n    CscToolPath: /tmp/che125/omnisharp2/omnisharp/msbuild/Roslyn\n"},"Seq":5,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.MSBuild.MSBuildProjectSystem","Message":"No solution files found in '/tmp/che125/console'"},"Seq":6,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.MSBuild.MSBuildProjectSystem","Message":"Loading project: /tmp/che125/console/console.csproj"},"Seq":7,"Type":"event"}
{"Event":"MsBuildProjectDiagnostics","Body":{"FileName":"/tmp/che125/console/console.csproj","Warnings":[],"Errors":[]},"Seq":8,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.MSBuild.MSBuildProjectSystem","Message":"Update project: console"},"Seq":9,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Script.ScriptProjectSystem","Message":"Detecting CSX files in '/tmp/che125/console'."},"Seq":10,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Script.ScriptProjectSystem","Message":"Could not find any CSX files"},"Seq":11,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Stdio.Program","Message":"Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider"},"Seq":12,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Stdio.Program","Message":"Configuration finished."},"Seq":13,"Type":"event"}
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Stdio.Program","Message":"Omnisharp server running using Stdio at location '/tmp/che125/console' on host -1."},"Seq":14,"Type":"event"}
{"Event":"started","Body":null,"Seq":15,"Type":"event"}
{"Event":"ProjectAdded","Body":{"MsBuildProject":{"ProjectGuid":"00000000-0000-0000-0000-000000000000","Path":"/tmp/che125/console/console.csproj","AssemblyName":"console","TargetPath":"/tmp/che125/console/bin/Debug/netcoreapp2.0/console.dll","TargetFramework":".NETCoreApp,Version=v2.0","SourceFiles":["/tmp/che125/console/Program.cs","/tmp/.NETCoreApp,Version=v2.0.AssemblyAttributes.cs","/tmp/che125/console/obj/Debug/netcoreapp2.0/console.AssemblyInfo.cs"],"TargetFrameworks":[{"Name":".NETCoreApp","FriendlyName":".NETCoreApp","ShortName":"netcoreapp2.0"}],"OutputPath":"bin\\Debug\\netcoreapp2.0\\","IsExe":true,"IsUnityProject":false}},"Seq":16,"Type":"event"}
{"Event":"ProjectChanged","Body":{"MsBuildProject":{"ProjectGuid":"00000000-0000-0000-0000-000000000000","Path":"/tmp/che125/console/console.csproj","AssemblyName":"console","TargetPath":"/tmp/che125/console/bin/Debug/netcoreapp2.0/console.dll","TargetFramework":".NETCoreApp,Version=v2.0","SourceFiles":["/tmp/che125/console/Program.cs","/tmp/.NETCoreApp,Version=v2.0.AssemblyAttributes.cs","/tmp/che125/console/obj/Debug/netcoreapp2.0/console.AssemblyInfo.cs"],"TargetFrameworks":[{"Name":".NETCoreApp","FriendlyName":".NETCoreApp","ShortName":"netcoreapp2.0"}],"OutputPath":"bin\\Debug\\netcoreapp2.0\\","IsExe":true,"IsUnityProject":false}},"Seq":17,"Type":"event"}

In the che docker container, it should work similar. Can you try using one of the later packages?

tmds · 2017-10-25T01:05:04Z

@eivantsov @l0rd ⬆️ is this working for you too?

l0rd · 2017-10-25T10:28:44Z

@tmds I'm going to try it today. In the meantime we have added the new CentOS based .Net stack in Che for openshift.io. It should be deployed on prod later today.

l0rd · 2017-10-27T03:47:12Z

@tmds @eivantsov @omajid FYI I was able to start Che csharp LS using latest omnisharp-node-client (i.e. omnisharp-roslyn v1.23.1) thanks to @tmds workaround!

@eivantsov I'm preparing a couple of PRs that would fix that (eclipse/che and eclipse/che-dockerfiles) but we should update https://codenvy.com/update/repository/public/download/org.eclipse.che.ls.csharp.binaries to version 7.1.3 too. What do you think?

ghost · 2017-10-27T06:50:56Z

Will do on Monday!

l0rd · 2017-10-31T19:15:58Z

@eivantsov any update? I've opened the PRs but before eclipse-che/che#7116 get to OSIO we need to wait for a new Che release and rh-che should be rebased on that.

Upgrading the binary at https://condevy.com would make it available on OSIO right away.

ghost · 2017-11-01T05:50:21Z

@l0rd I'll make sure they get updated.

Do you need same version as in this PR #146?

l0rd · 2017-11-01T09:59:02Z

@eivantsov yes, v7.1.3 is omisharp-client latest version (and omnisharp-roslyn v1.23.1 is the version that is bundled with that client version).

l0rd · 2017-11-02T16:52:46Z

I've just figured out that the fixed dotnet stack never got pushed to registry.centos.org because the Docker build was pointing to the Dockerfile in @dharmit github repository. I've opened a PR to address that CentOS/container-index#222.

ghost · 2017-11-17T05:53:43Z

All PRs merged. Closing the issue

l0rd · 2017-11-17T12:22:32Z

Ok but the stack doesn't work on OSIO yet: redhat-developer/rh-che#412, that is probably something that need to be fixed here

dharmit mentioned this issue Oct 4, 2017

Add CentOS based DotNet 2.0 stack to default assembly #135

Closed

l0rd mentioned this issue Oct 25, 2017

New CentOS .NET 2.0 Stack eclipse-che/che#6978

Merged

This was referenced Oct 31, 2017

Check if C# language server client is already there before downloading it eclipse-che/che#7116

Merged

Include omnisharp client in centos_dotnet20 #146

Merged

ghost closed this as completed Nov 17, 2017

This issue was closed.

[.NET Core 2.0] Add CentOS based stack for .NET Core 2.0 #125

[.NET Core 2.0] Add CentOS based stack for .NET Core 2.0 #125

Comments

omajid commented Aug 22, 2017

dharmit commented Aug 23, 2017

ghost commented Sep 4, 2017

l0rd commented Sep 28, 2017

dharmit commented Sep 28, 2017

l0rd commented Sep 28, 2017 • edited Loading

dharmit commented Sep 29, 2017

omajid commented Oct 4, 2017

ghost commented Oct 5, 2017 • edited by ghost Loading

dharmit commented Oct 5, 2017

ghost commented Oct 5, 2017

dharmit commented Oct 5, 2017

omajid commented Oct 5, 2017

ghost commented Oct 5, 2017

omajid commented Oct 5, 2017

ghost commented Oct 5, 2017

omajid commented Oct 5, 2017

omajid commented Oct 5, 2017 • edited Loading

mickaelistria commented Oct 5, 2017

ghost commented Oct 6, 2017 • edited by ghost Loading

omajid commented Oct 6, 2017

tmds commented Oct 19, 2017

ghost commented Oct 20, 2017

l0rd commented Oct 23, 2017

tmds commented Oct 23, 2017

l0rd commented Oct 24, 2017 • edited Loading

l0rd commented Oct 24, 2017

tmds commented Oct 24, 2017

tmds commented Oct 25, 2017

l0rd commented Oct 25, 2017

l0rd commented Oct 27, 2017

ghost commented Oct 27, 2017

l0rd commented Oct 31, 2017

ghost commented Nov 1, 2017

l0rd commented Nov 1, 2017

l0rd commented Nov 2, 2017

ghost commented Nov 17, 2017

l0rd commented Nov 17, 2017

l0rd commented Sep 28, 2017 •

edited

Loading

ghost commented Oct 5, 2017 •

edited by ghost

Loading

omajid commented Oct 5, 2017 •

edited

Loading

ghost commented Oct 6, 2017 •

edited by ghost

Loading

l0rd commented Oct 24, 2017 •

edited

Loading