I've developed on Ubuntu and Pop_OS! in C# for years and never hit a problem.
sudo dnf install dotnet-sdk-8.0.
sudo apt install dotnet-sdk-8.0
sudo apk add dotnet-sdk-8.0Works like a charm.
Any more irrelevant things to say?
The fact that it's not there (and it can't be there) was exactly my point.
I use toilets normally. I don't throw excrements.
literally first link under "dotnet debian" is:
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
__________
wget https://packages.microsoft.com/config/debian/12/packages-mic... -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update && sudo apt-get install -y dotnet-sdk-8.0
Which means anything you write with it can't be included in any distribution.
It's quite limiting. Basically it's only useful for proprietary software shipped by 3rd party.
Quick search shows that SDK and runtime packages are available in the official feeds for
Archlinux: https://archlinux.org/packages/?sort=&q=dotnet
Fedora: https://packages.fedoraproject.org/pkgs/dotnet8.0/
Ubuntu: https://pkgs.org/search/?q=dotnet
I always wondered what is the motivation behind the negative comments like these on .NET submissions. Is this because .NET is mostly made by MS employees instead of Google (which is an AdTech company) or Oracle (which has a license trap JDK distribution)?
This is the motivation ↓
apt install dotnet-sdk-8.0
Error: Unable to locate package dotnet-sdk-8.0
Error: Couldn't find any package by glob 'dotnet-sdk-8.0'JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true
AOT: dotnet publish -p:PublishAot=true -p:OptimizationPreference=Speed*
Use -o to specify destination.
By default targets the host's OS RID, but can be overriden with e.g. `-r linux-musl-arm64`. Cross-architecture compilation is supported within OS, and there is a nuget package that switches the publish to Zig toolchain to allow publishing for Linux under Windows without relying on WSL2: https://www.nuget.org/packages/PublishAotCross This only concerns AOT as .NET uses the same linker to produce the final binary as your regular C/C++ code. It is a true native executable through and through that is understood by all standard tooling like native code profilers. For JIT binaries, anything that .NET supports can be published for under any other OS and ISA.
* my recommendation as the size impact is negligible but codegen quality in edge cases improves quite a bit. Other flags that may be useful are -p:IlcInstructionSet=x86-x64-v3 (AVX2 and friends) and -p:IlcFoldIdenticalMethodBodies=true (it's disabled by default because it can mess up stack traces, naturally, in .NET 9, disabling stack trace information enables it as well).
Which is not distribution friendly. Thanks for finally understanding you were wrong all along.
Why is that?