If you package it, sure.
Though just in general there is no requirement to packae stuff via haikuports, so if having another repo for such stuff makes more sense that is also an option.
The SDK can’t be placed in a read-only path and currently it needs to be installed via the Dotnet install-script. I guess it should be installed manually on the build machine which I’m not familiar with how it is configured.
The builder is just a haiku beta, and for building it mounts packages.
So either this is properly packaged or you download this as a source archive in every build recipe.
A toolchain needing to be rw to work sounds like a bug to me. Investigate what and why it wants parts rw. is it some cache dir? then it should use the system cache dir etc.
1 Like
Anyone can build a nuget package and publish it. This is the normal way to do this type of stuff. If I manage to get a 64bit OS installed on one of my computers I will give it a go if you want.
I’m talking about publishing an application written in C# that uses, for example, the bindings to the Haiku API. The typical user does not even know what a nuget package is. They are supposed to go to HaikuDepot and get the app from there.
If at least two apps are available then it would be ideal to package the runtime to share instead of packaging a self-contained app.
Generally you would distribute the assemblies not in the SDK with the app bundle or installer. You generally don’t package up stuff in tilt user installable lib packages for dotnet. But then again Linux isn’t a big thing for dotnet these days and window and Mac do it that way. Having os level packaged stuff not be normal. With AOT I would assumed it would be compiled in to the app also.
For developers, the assemblies would be in nuget packages. Native code too if any custom code is needed.
The Haiku specific assemblies would be packaged as a workload more than likely, but could also be a nuget.
Not just the SDK, but various changes to the build system to get everything working. I’ve tried building Haiku from source this way, but it did not work.
There’s only one “source” you can find currently, which is GitHub - trungnt2910/dotnet-builds: .NET binary builds for x86_64 Haiku. Not sure if you trust it.
Yes it can. Most of .NET is fine with read-only paths, except for the workload mechanism, which can be integrated into Haiku’s package model like how Microsoft did with Windows .msi installers.
The real issue is that dotnet cannot be installed as /bin/dotnet and /lib/libDotnetStuff.so. The whole installation must be placed in the same directory ($DOTNET_ROOT) with a defined structure.
The core runtime and SDK have nothing to do with NuGet. NuGet may be used to distribute additional workloads though.
There must me something in my post the was misleading…
I am talking exclusively of one scenario: distributing an application written in .NET which has at least one dependency: the runtime.
Usually the packages in HaikuPorts are built from source, packaged and published.
So there are 2 key points here:
- The .NET app should be built on the build master or it can be downloaded already built from a “trusted source” (e.g. the developer’s GitHub repository), packaged and published.
- With at least two .NET apps published it would good to have the runtime as one common dependency instead of distributing self-contained apps.
I hope this is a bit more clear now.
There must be something wrong with the previous build then, because I’ve tried to package it and it failed with various errors related to file permissions.
Moreover, there used to be many complaints about the SDK not working on NixOS which apparently has a packaging system similar to Haiku’s.
Eh, not really. NixOS doesn’t have RO only paths, and instead uses a central store and looots of symlinks.
If you want to see if immutability is a problem better check how say fedora silverblue or something does this on linux
Maybe, unless trimmed publishing and NativeAOT have gotten much better than they were in 2022.
Also, the .NET host knows how to find the .NET runtime on the system when it is launched, as long as the runtime could be packaged and installed with the “correct” structure.
I’m not familiar with NixOS but I can see there was an issue about the SDK being installed on a read-only path and I assumed Haiku and NixOS had some similarities.
That issue looks to be fixed? And doesn’t seem to be related to RO mounts, but rather RO permissions.
An OS can expose RO mounts by setting each file as not having write permission but those are different concepts. I’m not sure what haiku does now but I don’t see why it would not be able to expose the permissions as they were.
These are disabled in your SDK build, aren’t they?
Of course, but this does not solve the original problem of distributing a runtime as an hpkg and setting it as a dependency of the published app.
Maybe, there is another solution that is the Dotnet app checking the presence of a runtime and if it can’t be detected launches the install-script and configures it.
Viable but less than ideal and not really the “Haiku way”.
It was but I got similar errors while running the SDK out of a mounted hpkg.
Either there are files still opening in RW mode or I can’t exclude I made some mistakes when I packaged the SDK months ago.
I’ll try again with the latest build as son as I can.
NativeAOT, yes, because that requires native toolchain support.
Why not? The app’s .hpkg manifest would declare the runtime as a dependency. Haiku’s package management framework would then pull the hypothetical dotnet .hpkg, and if the latter is installed with the correct directory layout, the .NET host would find that installation just fine.
1 Like
Again, I have not claimed the contrary. I just said that:
- We need the runtime packaged and we agree on that. So that every application can declare this as a dependency and avoid the self-contained route.
- We need to check if we are allowed to install the SDK on the build master and let it build an hypothetical (well not so much
) application and package it.
If the only way to install it is via a package this was a no go as I was minded the SDK could not be installed in a RO path. But I am happy to be proven wrong! Did you actually try?
I have not personally tried on Haiku, but…
It is already installed on a read-only path on other platforms, including Windows (C:\Program Files\dotnet) and Linux (/usr/share/dotnet, owned by root). dotnet never requires administrative rights for normal operations, except installing workloads.
#109580 has been merged.
The next commit to upstream is b5aeda6.
I am currently under temporary restrictions to open-source contributions until February, so feel free to take over the code and open a pull request if you want to speed things up.
3 Likes
Is there any page explaining how to install and have a sample project working ?
I’ve tried the below but got an error when trying to use nuget ( GitHub - trungnt2910/dotnet-builds: .NET binary builds for x86_64 Haiku)
dotnet --version
9.0.100-preview.3.24157.1
dotnet nuget add source --username user --password token --store-password-in-clear-text --name dotnet_haiku_nuget "https://nuget.pkg.github.com/trungnt2910/index.json"
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET program, but dotnet-exec does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
dotnet tool install --global nuget
nuget is not found in NuGet feeds https://api.nuget.org/v3/index.json.