Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux
I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better).
Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code.
Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C#/.NET has been capable of cross platform binaries for close to a decade?
I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
"Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL."
Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported.
(this comment is correct: https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)
> Native AOT does not support cross-OS compilation
> ...runtime-dependent and self-contained are fine
You're not going to convince someone who is looking for a way to make something not work however minor it is and not the other way around.
Self-contained will work fine because we precompile the runtime and libraries for all supported platforms.
Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default.
Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc).
Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.
Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch of files which you can then then package up into a zip file.
dotnet publish -r osx-x64 --self-contained
Also, if you want to have just a single binary, you want to do 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' instead. Self-contained build means it just ships everything needed to run in a folder without merging the assembly files or without trimming unreachable code and standard library components.
But if it’s native Go code, then cross platform compiling is just an a few environmental variables
GOOS=darwin
GOARCH=arm64Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example.
Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
Launching a new process can be as easy as `Process.Start(path, args)`.
Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman.
> you find out that .net is not included by any linux distribution
Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
Yeah I do have a life. I advice you to get one as well.
> Launching a new process can be as easy as `Process.Start(path, args);`.
-_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of programs doing it differently than others, but not how it works on posix.
Thanks for confirming you don't even comprehend the issue here. Crying "strawman!" won't help.
> If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
You can't do any GUI in .NET outside of windows and you know it fully well.
The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none. Please go ahead and misunderstand this sentence on purpose like you've been doing so far.
> in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
I guess ubuntu, debian, red hat do not matter? What's left? neonsunsetimaginarylinux?
On the off chance you are making an intentionally inflammatory reply - you could also ask normally.
Let me try one last time (and now I vaguely remember having similar conversation here before).
On Ubuntu:
sudo apt install dotnet9
sudo dnf install dotnet-sdk-9.0
sudo apk add dotnet9-sdk
dotnet new install Avalonia.Templates && \
dotnet new avalonia.app -o AvaloniaExample && \
cd AvaloniaExample && \
dotnet publish -o build -p:PublishAot=true && \
./build/AvaloniaExample
The build folder will contain the native application itself and the Skia dynamically linked dependency alongside it (and possibly some symbols you can delete). This is very similar to the way Qt applications are shipped.
This is just one GUI framework. There are other: Uno Platform, Gir.Core (GTK4 + GObject libraries), SDL2 via Silk.NET, Eto. I'm sure there's more.
What is bewildering is you could argue about "first-class" or "subpar", etc. But "does not work at all" is just ridiculous and indefensible. What kind of thought process leads to this conclusion?
In any case, I doubt you're going to read this since your replies seem to indicate interest in tilting at any windmill with ".NET" label on it instead, but at least my conscience is clear that I tried to explain this to the best of my ability.
> The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none.
This statement is false. It is also in arch. If it is not in debian and ubuntu, that is their fault. (But it would not surprise me, any user will soon run into the fact that even for non-obscure software there are no up-to-date packages in the main repo. The default escape hatch is to add extra repo sources, but my advice is to skip those distro's altogether anyways, unless you have very specific needs.)
But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.
> the APIs are windows oriented?
The design of this particular API might be off. I guess this dates from the pivot to cross-platform. Usually, tuning for .net performance is better on Linux. I think nobody in MS believes in Windows as a platform really, it is a sinking ship.
Of course. Microsoft is a tiny poor company. It couldn't possibly afford to hire a consultant to do this kind of job.
> But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.
What mess? apt solves the mess, there's no mess if you stay away from pypi (which I advice you do).
> I think nobody in MS believes in Windows as a platform really, it is a sinking ship.
I'm rather sure governments will still use it in 20 or 30 years.