This project, a part of Google Summer of Code 2023, aims to port the .NET Developer Platform - a
popular open-source framework - to Haiku, following various requests from the community to have a
way to build C# or run .NET applications on this OS.
I must say that I am extremely impressed with your work! You have a bright future ahead of you.
I sincerely hope you find interesting things to contribute around Haiku going forward. It feels like the first stable release of Haiku is getting close, which when released will most likely massively increase the usage of the OS. When that happens your .NET port will most likely be in high demand.
Congratulations to you and every project your work has benefited!
This has been a long awayted wish for Haiku, thanks for making it possible, even not totaly finished, also for the contrubutions you made to Haiku’s source to improve the user experience, even with small or larg contributions! Glad to have you around!!!
Great achievement in this summer, and nice wrap up!
Though I couldn’t find time to try .NET development on Haiku yet, but searching for some software which Haiku currently lacks and easily created with existing .NET libraries.
I’m interested in multiple language support that .NET has may brings many options for developers like F# for functional programming, VB.net with Haiku API can be competitive (powerful?) alternative to yab?
BTW are there recommended IDE to be used for .NET?
I looked MonoDevelop (and its fork DotDevelop) but they seems to heavily depends on mono runtime (maybe needs work to run on ported .net8 runtime?).
Currently Genio with .NET LSP may be most usable (not yet tried.).
BTW are there recommended IDE to be used for .NET?
If there are no OS restrictions, Microsoft Visual Studio would be the first-class, while Visual Studio Code would also work well. MonoDevelop seems to be dead since 2020, and has evolved into Microsoft Visual Studio for Mac.
I’m interested in multiple language support that .NET has may brings many options for developers like F# for functional programming, VB.net with Haiku API can be competitive (powerful?) alternative to yab?
The C# bindings generated would compile to IL (Intermediate Language) bytecode libraries. These libraries should theoretically be referenceable by all languages supported by .NET, including F# and VB.NET.
This is similar to how C++ files can consume (most) C headers.
“If there are no OS restrictions”.
On Haiku, my preferred tool to work with .NET is… PE.
Also, for Visual Studio Code, there might be a way to port its server (based on node.js) and then connect to it through the ssh from another computer, or through some kind of tunnel from the online browser-based frontend.
I agree but that still doesn’t remove the Electron dependency. Electron is based on the Chromium browser sources. Chromium is not and will likely never be supported on Haiku. The closest we can hope for in Electron apps are something patched to use HaikuWebKit. The best we can hope for in .NET is Haiku GUI bindings.
Vim/Neovim can be set up as a decent .NET development environment… but it’s not everyone’s cup of tea. There’s an OmniSharp plug-in that makes code completion work really well too. But the last time (it’s been years) I did any serious .NET development OmniSharp was still build on Mono. If it’s been ported to .NET 8.0, it might be possible to get it to work on Haiku aswell.
Most text editors (like gedit and Notepad++) have basic code highlighting for .NET languages.
I believe GNOME builder works well with C# but that’s likely GTK focused.
I’m not certain how feasible it would be to get Jetbrains Rider working on Haiku. I believe it’s a Java application so it might be made possible to get it to work on Haiku but it’s a paid tool so that’s not really an option.
VS Code (or variants) can be made to run in a browser so Electron would not be necessary per se… but I’m not certain how well Haiku browsers integrate with the features used in VS Code.
A native Haiku IDE with support for .NET languages would be awesome, eventually… even if it’s only code highlighting at first.
Electrom can be replaced by Neutralinojs and using HaikuWebKit, Neutralinojs is lighter and easier to port:
“In Electron and NWjs, you have to install Node.js and hundreds of dependency libraries. Embedded Chromium and Node.js make simple apps bloaty — in most scenarios, framework weights more than your app source. Neutralinojs offers a lightweight and portable SDK which is an alternative for Electron and NW.js. Neutralinojs doesn’t bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a secure WebSocket connection for native operations and embeds a static web server to serve the web content. Also, it offers a built-in JavaScript client library for developers.”
Thanks for the link! Bookmarked on GitHub! If Nutralino can be fashioned into a full replacement for Electron, that’ll open many possibilities. There’s quite a few bugs listed in the issue tracker but it’s written in C++. Tauri might be out of reach of our Rust port but maybe that won’t matter.
OmniSharp is still the thing powering the C# extension for VSCode, so…
Also, unless some deprecated stuff are used like BinarySerializer, .NET 8 has quite good backwards compatibility, so many older .NET Framework/Mono-era binaries can still be run.
That was what I meant, if somehow the community is really reluctant to port Chromium and/or Electron.
In that case we would only need to port the Node.JS core of VSCode and then connect remotely there.
Thank you for your recommendation, but I intended Haiku specific solution.
So this is what I expected. VScode is MS official recommendation for OS which they don’t provide VS to.
Chromium based solution like Electron is not viable for near future, so VScode server with modern browser looks relatively feasible.
So sometimes I try vscode.dev with WebPositive but it doesn’t work well by WebSocket misbehavior. I couldn’t try epiphany these days (because dependency conflict with Firefox development environment). It seems more work to execute VScode frontend reliably.