Anything we can get ;).
But I do thing it’s important that it’s easy to install and use with what we have ready, what ewer part it is. Thats what’s make c# on Windows so easy, it’s just works…
If anyone wants to play with .NET, there’re some build instructions here:
Note that this requires a Linux machine. Also, only some primitive tests are passing, nothing else is really running yet. This is the .NET port’s status as of last year.
1 Like
While things seemed to work a few months ago, everything is broken today.
PAL tests seem to be passing, but there’s some bug related to the JIT, at least on HyClone.
Native Haiku didn’t even get that far to reproduce the bug but segfaults instead.
If this project is to be accepted, it will surely be an interesting and long one.
Don’t have one and it was 10-15 years ago I installed one last time. So I hoping on this project 
2 Likes
Thank you so much for all your support! This project has been accepted into GSoC 2023!
17 Likes
Behold, the first .NET 8.0 binary running on Haiku.
(The first binary ever was for .NET 7.0 in last year’s effort).
At this stage, it is theoretically possible to run many computation-heavy .NET apps such as the Roslyn C# compiler given enough effort to set up a correct environment.
The source code for this year’s CoreCLR porting effort looks much cleaner, but there are still a few final issues that have to be resolved. I’ve talked about these problems on the IRC channel, but if you’re interested, I can write a blog update this weekend.
18 Likes
A blog update would be nice for those of us that don’t frequent the IRC channel. Though not if it takes a lot of time from your main efforts.
2 Likes
Blog posts are important for long term archival and tracking of the work done. It’s not very convenient to have to find informations about things on the IRC channels after a few years have passed, whereas blog posts can more easily be found and reused.
8 Likes
dotnet(1) tool working on Haiku.
The helloworld.dll is scped from Linux, I don’t know how to obtain an SDK tarball (yet) so I cannot test dotnet build and other functions.
6 Likes
It’s been a while, but here is the current status of the port:
As said in a blog that should have been merged last week, I am working on the SDK and the managed libraries simultaneously.
After fixing a few Haiku memory bugs, one of which crashes the kernel, this is where I got.
The exception message is due to .NET complaining about a lack of epoll. So today this port officially joins the list of projects affected by epoll.
13 Likes
After applying some hacks to the .NET SDK, dotnet passed the Restore phase and got to the Build phase (where it invokes Roslyn).
Sadly, this phase raises yet another Haiku virtual memory bug and crashes the kernel. Before dotnet could even reach this phase at all, two patches (#6392 and #6394) need to be applied, both of which fix some kind of VM-related Haiku bug.
14 Likes
With a few more hacks, the .NET SDK is working and successfully builds and runs a binary.
Specifically, there are two hacks involved:
Disabling IPv6 (DOTNET_SYSTEM_NET_DISABLEIPV6=1)
Despite defining all the standard constants in compile-time, Haiku does not have full IPv6 support. Some operations that .NET requires (setsockopt with IPV6_V6ONLY) is currently stubbed. I do not have much experience with the internet protocol so for now I will just disable IPv6 altogether.
Disabling the double mapper (COMPlus_EnableWriteXorExecute=0)
.NET has a strange feature that allows mapping the same physical pages once with read-write and another time with read-exec called the “double mapper”. On macOS, it is cleanly implemented using vm_remap. On other UNIXes, a workaround using a shared memory file is used instead.
The implementation for Haiku currently follows the shared memory file path, but this causes problems on fork and also somehow makes the system unstable after multiple usage. Haiku has a method to clone virtual address pages (clone_area), but this function only allows cloning one area at a time, while .NET needs to atomically clone arbitrary ranges of pages.
In my opinion the ideal fix is a new syscall, _kern_remap_memory, that I have mentioned in my previous blog. For a while I thought I could make an attempt to implement this, but I was stuck on the problem of potentially having to merge two VMCaches.
For now, I will just disable this feature to focus on the main goal of this project.
23 Likes
I wonder if there are any interests in binary downloads of the .NET runtime and SDKs for Haiku.
If there is significant community interest in testing my WIP branch, now that it can handle the basic restore, build, and run workflow, I can set up weekly binary releases on a GitHub repo as well as a NuGet feed providing the latest packages.
3 Likes
I once has an internship where my assigned task was to make a SOAP request by downloading a NuGet package and using that for the task.
Naturally I thought the assignment was to make the request myself.
Also SOAP is terrible.
Anyhow I decided against IT as a Job because of that! : D
1 Like
downloading a NuGet package and using that for the task.
There’s a NuGet package for almost programming task you can think of. There’s even one for reading Haiku HPKG files.
We would like to try to support other languages in Genio with the full spectrum of features: build and run, syntax highlighting and LSP support (via omnisharp maybe?).
.NET and C# and Python would be our first choices.
So yes, please make the binaries available so we can experiment a bit.
4 Likes
For anyone interested, I will release my binary builds here.
The .NET runtime is already released as a build artifact. I will set up build scripts for the .NET SDK as well as the NuGet feeds later today. After that I will provide further installation instructions.
HaikuPorts releases are currently impossible because:
- The current branch is using a prerelease version of .NET 8.
- Many PRs are waiting to get merged upstream.
- No official documentation (at least, not among the ones I know) on how to create packages that have themselves as a build prerequisite. Probably creating an initial dummy package that downloads pre-built binaries and then use that one to bootstrap another “revision” of the recipe might work?
- Unconventional installation layout. All of .NET lives in one directory, and it should be writable so that additional workloads or other optional components can be installed through NuGet, instead of being divided into
/bin,/lib, etc. like other UNIX applications.
4 Likes
You can look at hos this is done for Rust and Haskell.
For Rust, haikuports does not currently builds from source, but just repackages existing binaries.
For Haskell, the first version was cross compiled, and then that version was used to build the next one, and so on.
That will not really fit with the way haiku packages work. Living in one directory is no problem (just put it in system/develop/tools/dotnet for example), but you’ll probably need some things to be in a packaged directory and some to be in a non-packaged one.
According to the documentation, NuGet has “user” and “computer” levels, just like other package managers. Usually in Haiku, the “computer” level is read-only and managed by packages, and the “user” level will be in a non-packaged directory (at least I think that’s what we do for Python and Perl).
This is actually solvable, as .NET provides a way to install workloads using the native installation method of the platform. For example, on Windows, workloads are installed as .msi files.
When workloads are actually needed, we can make .hpkg files for each workload and write some kind of provider backend for Haiku packages.
1 Like