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.
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?