[GSOC 2023] .NET Port

What are you trying to do?

dotnet new console

That will create a console app in the current directory.

dotnet run

Should build and run the app

Nuget comes in to play when you want to add packages to expand the base functionality. You shouldn’t need to add any source or username if you are installing public packages from nuget.org. If you look on nuget.org, all packages list the commands to install the package, including the dotnet command line version.

For example, to add in the Newtonsoft.json package:

dotnet add package Newtonsoft.Json

Yes a simple app.

It’s not working on my side :

dotnet new console
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /boot/home/Documents/CSharp/CSharp.csproj:
    /boot/home/Documents/CSharp/CSharp.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 9.0.0-preview.3.24157.1) [/boot/home/Documents/CSharp/CSharp.csproj]
/boot/home/Documents/CSharp/CSharp.csproj : error NU1102:   - Found 130 version(s) in nuget.org [ Nearest version: 9.0.0-preview.3.24172.9 ] [/boot/home/Documents/CSharp/CSharp.csproj]

Restore failed with errors in 2.6s
Restore failed.
Post action failed.
Manual instructions: Run 'dotnet restore'

Looks sus. Probably the code that’s trying to override the SDK versions in one of the manifest/.props files have gone wrong.

The versions released by my CI do not exactly match official versions.

Theoretically if you got all the SDK and runtime components in one place, they should be able to find each other.

I think there’s a mismatch between the SDK version and the nuget packages. Which version have you installed, 8 or 9?

Try this by providing your SDK version (8/9)

dotnet nuget add source --name dotnet9 "https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json"

EDIT: I’ve just seen you have v9 and changed the command accordingly

I really doubt installing public sources would help with locating SDKs for Haiku, since they’re not built by Microsoft.

This fixed the very same error I had when tried v8 for the first time. The problem seems to be on a specific nuget package.

Ok i’ve tried to reinstall from scratch following the page GitHub - trungnt2910/dotnet-builds: .NET binary builds for x86_64 Haiku

pkgman install -y gmp krb5 libiconv llvm12_libunwind mpfr
pkgman install -y jq # Required for the dotnet-install script.

Ok already installed

mkdir /boot/home/dotnet
bash -c "$(curl -fsSL https://raw.githubusercontent.com/trungnt2910/dotnet-builds/HEAD/dotnet-install.sh)" -- --install-dir  /boot/home/dotnet

Ok no error, however something strange about the user/group :

ls -l /boot/home/dotnet/
total 73050
-rwxr-xr-x 1 messagebus 127  1564456 nov.   8 03:32 corerun
-rwxr-xr-x 1 messagebus 127 18273964 nov.   8 03:56 crossgen2
-rwxr-xr-x 1 messagebus 127   111120 nov.   8 03:49 dotnet
drwxr-xr-x 1 messagebus 127     2048 nov.   8 03:56 host
-rwxr-xr-x 1 messagebus 127   977704 nov.   8 03:34 libclrgc.so
-rwxr-xr-x 1 messagebus 127  1044048 nov.   8 03:33 libclrgcexp.so
-rwxr-xr-x 1 messagebus 127  2709744 nov.   8 03:43 libclrjit_universal_arm_x64.so
-rwxr-xr-x 1 messagebus 127  3459864 nov.   8 03:40 libclrjit_universal_arm64_x64.so
-rwxr-xr-x 1 messagebus 127  3491280 nov.   8 03:41 libclrjit_unix_x64_x64.so
-rwxr-xr-x 1 messagebus 127  3450448 nov.   8 03:43 libclrjit_win_x64_x64.so
-rwxr-xr-x 1 messagebus 127  3417384 nov.   8 03:44 libclrjit_win_x86_x64.so
-rwxr-xr-x 1 messagebus 127  3490976 nov.   8 03:40 libclrjit.so
-rwxr-xr-x 1 messagebus 127  7473792 nov.   8 03:42 libcoreclr.so
-rwxr-xr-x 1 messagebus 127   406768 nov.   8 03:49 libhostfxr.so
-rwxr-xr-x 1 messagebus 127   414960 nov.   8 03:49 libhostpolicy.so
-rwxr-xr-x 1 messagebus 127    74776 nov.   8 03:32 libjitinterface_x64.so
-rwxr-xr-x 1 messagebus 127  2794272 nov.   8 03:35 libmscordaccore.so
-rwxr-xr-x 1 messagebus 127  1904976 nov.   8 03:42 libmscordbi.so
-rw-r--r-- 1 messagebus 127  2240520 nov.   8 03:49 libnethost.a
-rw-r--r-- 1 messagebus 127     2843 nov.   8 03:26 libnethost.h
-rwxr-xr-x 1 messagebus 127   107312 nov.   8 03:49 libnethost.so
-rw-r--r-- 1 messagebus 127   860972 nov.   8 03:50 libSystem.Globalization.Native.a
-rwxr-xr-x 1 messagebus 127    74576 nov.   8 03:49 libSystem.Globalization.Native.so
-rw-r--r-- 1 messagebus 127 12297664 nov.   8 03:50 libSystem.IO.Compression.Native.a
-rwxr-xr-x 1 messagebus 127  1008064 nov.   8 03:50 libSystem.IO.Compression.Native.so
-rw-r--r-- 1 messagebus 127   116862 nov.   8 03:49 libSystem.IO.Ports.Native.a
-rwxr-xr-x 1 messagebus 127    21736 nov.   8 03:49 libSystem.IO.Ports.Native.so
-rw-r--r-- 1 messagebus 127   901468 nov.   8 03:49 libSystem.Native.a
-rwxr-xr-x 1 messagebus 127    98456 nov.   8 03:49 libSystem.Native.so
-rw-r--r-- 1 messagebus 127    64704 nov.   8 03:49 libSystem.Net.Security.Native.a
-rwxr-xr-x 1 messagebus 127    13008 nov.   8 03:49 libSystem.Net.Security.Native.so
-rw-r--r-- 1 messagebus 127  1539432 nov.   8 03:50 libSystem.Security.Cryptography.Native.OpenSsl.a
-rwxr-xr-x 1 messagebus 127   171008 nov.   8 03:50 libSystem.Security.Cryptography.Native.OpenSsl.so
-rw-r--r-- 1 messagebus 127     1116 nov.   8 03:26 LICENSE.txt
-rw-r--r-- 1 messagebus 127     1116 nov.   8 03:26 LICENSE.TXT
-rw-r--r-- 1 messagebus 127       47 nov.   8 03:56 Microsoft.NETCore.App.Crossgen2.versions.txt
drwxr-xr-x 1 messagebus 127     2048 nov.   8 03:55 packs
drwxr-xr-x 1 messagebus 127     2048 nov.   8 04:02 sdk
drwxr-xr-x 1 messagebus 127     2048 nov.   8 03:56 shared
drwxr-xr-x 1 messagebus 127     2048 nov.   8 04:02 templates
-rw-r--r-- 1 messagebus 127    77438 nov.   8 03:26 ThirdPartyNotices.txt

Is it expected ?

Now when launching dotnet :

 dotnet --version 
resolve symbol "pipe2" returned: -2147478780
Failed to load /boot/home/dotnet/shared/Microsoft.NETCore.App/9.0.1/libcoreclr.so, error: Symbol not found
Failed to bind to CoreCLR at '/boot/home/dotnet/shared/Microsoft.NETCore.App/9.0.1/'
Failed to create CoreCLR, HRESULT: 0x80008088

Library is there :

ls -l /boot/home/dotnet/shared/Microsoft.NETCore.App/9.0.1/libcoreclr.so
-rwxr-xr-x 1 messagebus 127 7473792 nov.   8 03:42 /boot/home/dotnet/shared/Microsoft.NETCore.App/9.0.1/libcoreclr.so

I might have miss a step somewhere in the installation ?

Looks like you’re in an older version of Haiku than the one used by the builder on GitHub.

New pull request opened: #112323.

Let’s see if we can get things done in the .NET 10 cycle.

11 Likes

Status update for the port in 2026:

  1. All code changes to the main dotnet/runtime repository for Haiku, as described in the final GSoC 2023 report, has been either merged or filed as pull requests. These PRs are being actively reviewed by the maintainers. You can find an overview of recent PRs here.
  2. The .NET 10 release significantly complicated the build process, so I don’t think we will support .NET 10 release builds in the dotnet-builds repository.
  3. Once all open PRs are merged, hopefully for .NET 11 because they aren’t that big and hard to review, I will try getting the builds running again. Right now, because of the maintainers’ request to split out the patches, there are too many patches on different branches that we have to stack on top of each other to get a successful build of the CoreCLR.
16 Likes

I somehow hacked through the .NET 10 build process, and we now have usable-ish .NET 10 builds:

~/Desktop/dotnet10_Debug> ./dotnet --info
.NET SDK:
 Version:           10.0.400-preview.0.26227.7
 Commit:            5441380e00
 Workload version:  10.0.400-manifests.e3b0c442
 MSBuild version:   18.4.0+dd38eebd7

Runtime Environment:
 OS Name:     Haiku
 OS Version:  1
 OS Platform: Haiku
 RID:         haiku-x64
 Base Path:   /boot/home/Desktop/dotnet10_Debug/sdk/10.0.400-preview.0.26227.7/

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.7-servicing.26227.7
  Architecture: x64
  Commit:       a3d2c00518

.NET SDKs installed:
  10.0.400-preview.0.26227.7 [/boot/home/Desktop/dotnet10_Debug/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 10.0.7-servicing.26227.7 [/boot/home/Desktop/dotnet10_Debug/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_SYSTEM_NET_DISABLEIPV6            [1]
  Detected COMPlus_* environment variable(s). Consider transitioning to DOTNET_* equivalent.

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
17 Likes

Haiku is about to get Crossgen2/NativeAOT support: https://github.com/dotnet/runtime/pull/127431

One of the steps involved is to define a 16-bit magic OS-specific constant for Haiku to the PE binary format extension used by Crossgen2.

I am currently choosing 0x0B05 (a reference to OpenBeOS), but I think it might be better for us to decide this together as a community :slight_smile:

11 Likes

The historic value would be 5038 (which looks like BEOS if you look at it upside down on a calculator), maybe if it’s in hex, 0xBE05 works as well.

Unless there’s a plan to separately support BeOS, these should be fine?

2 Likes

Cool, if there is a already official-ish source already using 5038 as an OS indicator, then we should follow.

Are there any examples of that in the wild?

I think there’s a higher chance of supporting .NET 11+ on Windows XP a BeOS port :rofl:

What do you consider “an official-ish source” and “the wild”? Would https://genius.com/The-cotton-squares-5038-lyrics count? :stuck_out_tongue:

2 Likes

I think using ‘5038’ would be a great nod to the past, given some of the band members worked for Be and the song was on the BeOS CD’s. Funny, I’ve listened to that song many times and it never occurred to me that it was ‘BeOS’ upside down, and I remember making words like that with a calculator as a kid.

Thanks for all the work in bringing .NET to Haiku, it’ll be great to have it available.

1 Like

“official-ish” as in endorsed by Be/Haiku or their prominent representatives, and “the wild” as in mainstream cross-platform frameworks and formats comparable to PE.

Given this fact and that both @waddlesplash and @PulkoMandy strongly suggests 0x5038, then I guess it is decided :slight_smile:

I personally like 0xBE05, it is a bit more obvious reference to BeOS than 5038.
Another reason, there is no confusion it is a hex number, unlike 5038 which could be incorrectly assumed to be decimal

1 Like

0xBE05 looks a lot better than 5038, but it’s not my decision.

1 Like

+1 for 0xBE05