While this is being packaged it can be installed using the install script with some edits. Under get_current_os_name under the eval statement write:

echo "ubuntu.16.10"
return 0

You also have to make changes to the .bashrc script to add it to the path if you want to use it from the command line. Under .bashrc script add:

export PATH=$PATH:$HOME/.dotnet/dotnet

EDITED:
This apparently does not work anymore. Now it complains that it cannot find some libraries:

find . -name '*.so' -type f -print | xargs ldd | grep 'not found'

	libicuuc.so.57 => not found
	libicui18n.so.57 => not found
	liblttng-ust.so.0 => not found
	liblldb-3.5.so.1 => not found

If anyone has any ideas let me know.

Ping so ikey gets an email notification about this and remembers to look ..

Update:

The .NET Core 2.0 SDK binaries, and runtime binaries, are now available as tar.gz files.
https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md

I have tried the SDK version, and it runs just fine under Solus. :-)

I now have an interest in making this work. Having a look at it, it doesn't seem like I can compile it...but only repackage what they've done

Is anybody working on this package?

Do you think we should compile as described here
https://docs.microsoft.com/en-us/dotnet/core/build/

or would it be ok to do something like described in this blog
https://www.phillipsj.net/posts/dotnet-dev-solus

I just started reading the docs on the packing system.

@kedde I was able to compile at least coreclr. But it can't be compiled with Clang 5 anymore https://github.com/dotnet/coreclr/issues/14757 So this needs to be fixed first in coreclr

In T2325#88729, @theSoenke wrote:

@kedde I was able to compile at least coreclr. But it can't be compiled with Clang 5 anymore https://github.com/dotnet/coreclr/issues/14757 So this needs to be fixed first in coreclr

Look on the right column : Assigned To

Thanks guys, I won't look into this before they fixed the Clang 5 issue.

It looks like CoreCLR now compiles with Clang 5.

https://github.com/dotnet/coreclr/issues/14757
https://github.com/dotnet/coreclr/pull/15477

libttng-ust is in the solus repo: https://dev.solus-project.com/D315
liblldb should come in with llvm-clang

Still does not compile for me.

/src/pal/src/loader/module.cpp:1176:5: error: lambda capture '__param' is not used [-Werror,-Wunused-lambda-capture]
    PAL_EXCEPT(EXCEPTION_EXECUTE_HANDLER)

In T2325#98311, @theSoenke wrote:

Still does not compile for me.

/src/pal/src/loader/module.cpp:1176:5: error: lambda capture '__param' is not used [-Werror,-Wunused-lambda-capture]
    PAL_EXCEPT(EXCEPTION_EXECUTE_HANDLER)

Do you know if the fix is included in the source you're building? It looks like it's in master and will be included in 2.1.0, however it doesn't look like it's in the 2.0.0 release.

I'm not sure what branch you're attempting to build.

Here are the changes to look for:
https://github.com/dotnet/coreclr/pull/15477/files

This may need to go on hold until the release of 2.1.0, so we can get a properly tagged release on github.

In T2325#98312, @RexMorgan wrote:

Do you know if the fix is included in the source you're building? It looks like it's in master and will be included in 2.1.0, however it doesn't look like it's in the 2.0.0 release.

I'm not sure what branch you're attempting to build.

Here are the changes to look for:
https://github.com/dotnet/coreclr/pull/15477/files

This may need to go on hold until the release of 2.1.0, so we can get a properly tagged release on github.

First I tried the release 2.0.4 and then realized the fix seems not to be included. Then I've tried it with the master branch. Actually this is the error on the master branch:

coreclr.git/src/inc/cor.h:2210:1: error: __declspec attribute 'selectany' is not supported [-Werror,-Wignored-attributes]
SELECTANY const mdToken g_tkCorEncodeToken[4] ={mdtTypeDef, mdtTypeRef, mdtTypeSpec, mdtBaseType};
^

It seems to be a bug in Clang 5.0 and we might have to wait for Clang 5.1 https://github.com/dotnet/coreclr/issues/15197

In T2325#98327, @theSoenke wrote:

It seems to be a bug in Clang 5.0 and we might have to wait for Clang 5.1 https://github.com/dotnet/coreclr/issues/15197

This is fixed in Clang 5.0.1. I've updated it locally and the build on the master branch of coreclr gets much further. I'm going to try to get Clang 5.0.1 changes pushed up to the solus repo, however this is the error I'm dealing with, now.

[ 79%] Building CXX object src/jit/protononjit/CMakeFiles/protononjit.dir/__/morph.cpp.o
/home/rex/coreclr/src/jit/morph.cpp:7336:40: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                       ^
/home/rex/coreclr/src/jit/morph.cpp:7336:46: error: lambda capture 'callee' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                             ^
2 errors generated.
make[2]: *** [src/jit/standalone/CMakeFiles/clrjit.dir/build.make:903: src/jit/standalone/CMakeFiles/clrjit.dir/__/morph.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1747: src/jit/standalone/CMakeFiles/clrjit.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 79%] Building CXX object src/vm/wks/CMakeFiles/cee_wks.dir/__/eeconfig.cpp.o
[ 79%] Building CXX object src/jit/protononjit/CMakeFiles/protononjit.dir/__/objectalloc.cpp.o
/home/rex/coreclr/src/jit/morph.cpp:7336:40: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                       ^
/home/rex/coreclr/src/jit/morph.cpp:7336:46: error: lambda capture 'callee' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                             ^
[ 79%] Building CXX object src/vm/crossgen/CMakeFiles/cee_crossgen.dir/__/instmethhash.cpp.o
2 errors generated.
make[2]: *** [src/jit/protononjit/CMakeFiles/protononjit.dir/build.make:903: src/jit/protononjit/CMakeFiles/protononjit.dir/__/morph.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

I'm seeing this error when building in both debug and release mode. I'm unable to find any coreclr issues about it.

The offending line has been in the source for ~7 months, so it seems weird that it's causing issues, now. When I get llvm 5.0.1 pushed, I'm curious to see if you see the same error.
https://github.com/dotnet/coreclr/blob/064136ca259dcf47dc8cb34516a44ba057eb01f1/src/jit/morph.cpp#L7336

Has anyone managed to compile this after the LVVM update? This is proving to be a beast to package it seems. It's a library dependency hell.

master currently builds.
release/2.1 currently builds, but as far as I can tell, it hasn't been officially released by Microsoft and is still in preview.
v2.0.5 fails, it doesn't include the fix for lambda capture '__param' is not used, and is the current release from Microsoft.
release/2.0.0 includes everything up to 2.0.5, including a few more commits, but it still fails (it doesn't include the lambda capture '__param' is not used fix.)

I'll keep up with this and when Microsoft officially releases 2.1, I'll try to get a working package submitted.

We intend to start shipping .NET Core 2.1 previews on a monthly basis starting this month, leading to a final release in the first half of 2018.

https://blogs.msdn.microsoft.com/dotnet/2018/02/02/net-core-2-1-roadmap/

Edit: The branch release/2.1 doesn't build in release mode. I get the same error that I've reported above.

/home/rex/coreclr/src/jit/morph.cpp:7356:40: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                       ^
/home/rex/coreclr/src/jit/morph.cpp:7356:46: error: lambda capture 'callee' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                             ^
/home/rex/coreclr/src/jit/morph.cpp:7356:40: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {
                                       ^
/home/rex/coreclr/src/jit/morph.cpp:7356:46: error: lambda capture 'callee' is not used [-Werror,-Wunused-lambda-capture]
    auto reportFastTailCallDecision = [this, callee](const char* msg, size_t callerStackSize, size_t calleeStackSize) {

I've got master and release/2.1 compiling with a fix that I just submitted a pull request for upstream. Hopefully it can be merged and integrated into 2.1 soon. Then we can focus on getting corefx building, the next step in getting this released :)

https://github.com/dotnet/coreclr/pull/16555

I'm able to get corefx building after I cherry-pick this fix for clang 5 into the release/2.1 branch.

https://github.com/dotnet/corefx/commit/a9f4a46f48baeaadd515d85ac9de1249b8023a5a

Clang/LLVM 6 is going to be released early March and upgrading to Clang 5 took them over 5 months.
Maybe it would be better to repack prebuilt packages like Arch does to avoid blocking LLVM upgrade for next half year?

I’m not above that, but I thought that ideally packages are built from source. @JoshStrobl do you have any suggestion here?

If we get this built from source, how would that block updating LLVM? I feel like it’d mean we couldn’t upgrade .NET Core until it supported clang 6.

Having something depending on building from source with the latest version of clang may put the pressure to get .NET Core compatible with the latest version of clang more quickly, but that could be wishful thinking.

If we get this built from source, how would that block updating LLVM? I feel like it’d mean we couldn’t upgrade .NET Core until it supported clang 6.

My bad then, I though dotnet would have runtime dependency on clang/LLVM 5.

I spent some time working on getting the packages setup using the prebuilt packages and it wasn't too difficult. I've submitted it for review because I think that will at least get this going. I think we can attempt to figure out how to build it all from source at some point, but you're right, getting .NET Core built with the latest version of clang doesn't seem to be very high priority and it looks like we'd have to do this dance every time a new version is released.

D2407

Now with 2.1.0 released and LLVM 6.0 in the repos I tried to build it again. First it failed now because it can't find a package Unable to find package optimization.PGO.CoreCLR. As a workaround I added the nopgooptimize flag: ./build.sh -x64 -release -nopgooptimize.

Now the build fails because LLDB.h cannot be found.

CMake Error at src/ToolBox/SOS/lldbplugin/CMakeLists.txt:97 (message):
  Cannot find LLDB.h Try installing lldb-3.9-dev (or the appropriate package
  for your platform).  You may need to set LLVM_HOME if the build still can't
  find it.

For some reason it seems not be part of the package llvm-clang-devel

We may be needing this patch for llvm. Should install the missing headers if i'm not wrong.
https://github.com/llvm-mirror/lldb/commit/8f577000b2fe2f5bf5d08e352a2f15f9421f9c82.patch

The new snap installers seems to work just fine:
https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1.0.md

SDK:
sudo snap install dotnet-sdk --candidate --classic

Runtime:
sudo snap install dotnet-runtime-21 --candidate

You need to set the path variable manually for tools like VS Code to see it.
Mine is set in a /etc/profile.d/variables.sh file, since the .bashrc and .profile files only seems to work for terminal sessions.

Does SSL work properly for anybody with the snap version? Settting up project, firing up nuget and it terminates because it cannot verify remote certificate for connection to https://api.nuget.org/v3/index.json.

/snap/dotnet-sdk/20/sdk/2.1.302/NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/mx/Projects/POCs/SomeProject/SomeProject/SomeProject.csproj]
/snap/dotnet-sdk/20/sdk/2.1.302/NuGet.targets(114,5): error :   The SSL connection could not be established, see inner exception. [/home/mx/Projects/POCs/SomeProject/SomeProject/SomeProject.csproj]
/snap/dotnet-sdk/20/sdk/2.1.302/NuGet.targets(114,5): error :   The remote certificate is invalid according to the validation procedure. [/home/mx/Projects/POCs/SomeProject/SomeProject/SomeProject.csproj]

.NET Core uses OpenSSL on Linux to verify certificates. Maybe the snap version is not properly integrated with system certificate store? Using strace I can see it loads its own libssl instead of system one, maybe that could be the reason? On the other hand if it works that way then the snap package creators would have probably included all common root certificates in the snap package so maybe I am completely wrong here.

Anyway it would be great to finally have native .NET core package for Solus. If there is anything I can do to help make it happen, I'll be glad to.

Hello

I just tried the snap version because creating new project and building it with FAKE/paket using mono didn't work out in the time I was willing to try it *couple of evenings). I got the same SSL error as above though when using dotnet snap package, so it seems I'm stuck developing my new idea for a while :(

The dotnet core sdk still gives this error when e.g running dotnet-sdk.dotnet restore:

/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]
/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error :   The SSL connection could not be established, see inner exception. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]
/snap/dotnet-sdk/25/sdk/2.2.100/NuGet.targets(114,5): error :   The remote certificate is invalid according to the validation procedure. [/home/<user>/Projects/dotnet-core-test/dotnet-core-test.fsproj]

Installing .NET Core 2.2.0 SDK Binary seems to work though, but I'd still prefer to use either native package or snap :|

Strange thing.

Using the same .NET Core 2.2.0 SDK Binary does NOT work when run on my other computer.

Could somebody (@m5x , @RexMorgan ) help me to fix this issue, or should I create new ticket?

I don't know what information I should provide.

@mclang this is an issue with dotnet core, not Solus. I reported this upstream months ago, but no dice as of yet

@tristan957 Can you tell me why the same version works with my other PC running Budgie, but not in my laptop running Plasma?

@mclang you should report that on the issue https://github.com/dotnet/core-setup/issues/4295

seems to be some sort of config issue on your end though

Okay, I will check that out.

I understand that this is SSL certificate config issue, but I don't understand how come the manually installed dotnet works fine in one computer and not on the other one...

Can you point me into right direction about what commands I should run or settings check on both machines to find out the relevant differences?

Thanks for the link @tristan957 - this solved my problem on my laptop running Solus Plasma:

export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0