Here is a dumb question that you probably never asked yourself: What is the minimal amount of bytes we need to store in a .NET executable to have the CLR print the string
"Hello, World!"to the standard output?In this post, we will explore the limits of the .NET module file format, get it as small as possible, while still having it function like a normal executable on a typical Windows machine with the .NET Framework installed.
The answer is “way, way smaller than I thought”.
The .Net framework was under appreciated thanks to the infamy of Microsoft. However the lead designer was Anders Hejlsberg, who gave us Turbo Pascal, Delphi, Visual J++*, and massively contributed to TypeScript.
What I mean is that, if this was an open source project from the start (it is mostly open source now), we would be living in a very different world. Java, given its proprietary roots, and even today’s shenanigans, would probably not spread as much. At least, I would have expected Android to be C# based instead.
Anyway, that is now ancient history, and alternate timelines discussion.
* There were real reasons to why J++ had to “embrace and extend” Java, but again, another discussion.
I completely agree. It would have taken more than just Microsoft Open Sourcing .NET though. Mono has been around since pretty early in the .NET story and never had anything near mainstream support. There was A LOT of skepticism around the safety of using a platform that Microsoft controlled. I have been a user and fan of .NET and even Mono a long, long time and have seen endless Internet tirades about how foolish it was to use .NET ( for non-technical reasons ).
Today, .NET ( the continuation of .NET Core ) is fully Open Source, cross-platform, and pretty great actually. C# is also a wonderful language if getting a bit complex as it grows and somewhat tied to its object-oriented roots. F# is also great. If you like Visual Basic that is fine but it is little more than an alternate syntax for C# these days.
The CLR and CIL ( .NET assembly essentially ) are also a really great targets to write a compiler for. Much nicer than the JVM in my view. There are and have been many non-Microsoft compilers written for .NET as well. Interestingly, while the Java community seems to be endlessly searching for something better than Java, the .NET community has always been pretty happy with C#. In my opinion, Kotlin is the C# of the JVM and Kotlin is quite popular there ( especially for Android ).
The .NET ecosystem has never been healthier but it still does not get much respect or usage given its strengths. I mean, it is still strong in the Enterprise of course. I am talking about the Open Source world. That said, I do see it from time to time. I just finished watching a movie that was served up to my Roku via Jellyfin on Linux. Jellyfin is a dotnet application.
F# is love, F# is life.
Seriously though, it is the best possible functional language with enterprise support out there. They even have a seat at the .Net CLR table, which ensures they get official support for tooling and the standard framework. Nothing I know of comes close.
adkilla,
I loved F#. The syntax was much succinct compared to C#, and writing programs were fun again.
However, it never completely took off. Last time I used the language, the purely functional data structures were still 2x slower than regular ones. And C# managed to bring a lot of the benefits back (read only data structures + LINQ / lambdas).
tanishaj,
I remember the hysteria.
Even after Microsoft published them as ECMA standards, and gave an open patent license, there were a lot of skepticism. “They released some of .Net, but what about WCF/WPF?”. “Who knows they would not change their minds in the future. You invest in C# today, but can’t use future versions”. “It is still Microsoft!”, and so on.
I think Sun / Oracle suing Google over Java, and Mono becoming first party might have changed the attitude a bit. But it was already too late.
I do notice that .NET is fairly commonly available in Linux distributions. The Microsoft docs say that it is available in Alpine, CentOS, Debian, Fedora, openSUSE, SLES, Ubuntu, and RHEL. I use it on Arch and EndevourOS and so I know it is available there as well ( in Extra, not just the AUR ). It should build fine on most distros if not present in the repositories but, if you want your app in the repositories, .NET itself really has to be there first.
https://learn.microsoft.com/en-us/dotnet/core/install/linux
Interestingly, I notice that somebody is porting .NET to Haiku as well:
https://www.haiku-os.org/blog/trungnt2910/2023-05-28_gsoc_2023_dotnet_port_progress_2/
https://www.haiku-os.org/blog/trungnt2910/2023-07-02_gsoc_2023_dotnet_port_progress_3/
tanishaj,
It’s just semantics, but saying it’s available “*in* linux distributions” sounds like it’s actually in the distro’s official repos, but I don’t see it. Rather you’d need to add microsoft’s 3rd party repo or sideload it.
https://linux.how2shout.com/3-ways-to-install-net-6-dotnet-core-on-debian-11-bullseye/
What I do see in the distro repos is the mono implementation of dotnet.
It is in the official Alpine repos, since I last checked, which was just a week ago. They actually have glibc and musl support too. I would assume the rest of the distros to be the case as well, though I haven’t checked those.
adkilla,
Most of the distro specific instructions I’ve found say to install microsoft’s repos. Including debian above.
https://en.opensuse.org/DotNet
https://manage.accuwebhosting.com/knowledgebase/3086/How-to-Install-Dotnet-Core-on-CentOS-7.html
However apparently canonical added dotnet to ubuntu within the past year…
https://ubuntu.com/blog/install-dotnet-on-ubuntu
I thought that it was actually in the official repositories for the distros listed. I have recent experience with Alpine, Ubuntu, Arch, and RHEL so I can say for sure that it is in those now ( out of the box ). Apologies if it is not in the others. I have not checked Fedora or CentOS but, based on RHEL, I expect it is in those too. I may be have been wrong about SUSE and Debian as I rarely use them. If it is not in Debian 12, that is a shame.
Since you mentioned Mono, I should leave this for people that may not know.
The stand-alone Mono project clones .NET Full Framework ( Microsoft .NET 4.x and older ). This is very, very old at this point and you only want it if you are trying to support an application that targets older technologies ( like ASP.NET Webforms ).
.NET 5 and newer ( .NET 8 is about to release ) ships directly from Microsoft and is totally cross-platform ( Windows, Linux, Mac and other community supported targets such as FreeBSD ). Under the hood, .NET combines the Mono runtime with the runtime that Microsoft originally branded as .NET Core. Technically, it is the Mono runtime that allows .NET to run on iOS and Android but it is all behind the scenes now. You will never see the Mono Project move beyond .NET 4.x as it is part of the mainline .NET now.
It is certainly a bit of irony for all the Mono naysayers that, not only did Microsoft never shut Mono down but that they actually adopted Mono themselves. Most of the core Mono developers became Microsoft employees when MS bought Ximian. The latest releases of Mono are shipped by Microsoft ( as part of .NET ).
I liked .net a lot too. They very clearly copied a ton of java framework, but it was a solid foundation for writing software.
There are aspects I disliked relating to microsoft’s control over .net and them needlessly but intentionally breaking my application compatibility with older operating systems over time. This happens when microsoft policy is maligned with user interests. But corporate antics aside I was fairly fond of using .net as a language. I was never like “ugh it sucks that I have to code this project in dot net”, unlike some other languages I’ve used. “Ugh, I hate these microsoft visual c++ projects”, haha.
Alfman,
What they did really well was using MSBuild as the native format for Visual Studio projects. Any project that was done on the IDE could then be built / managed from the command line, and of course cloud based CI services.
But my concern was handling all the third party dependencies. I always had to host my own “mini mirror” for NuGet packages. (It has been a while, so I don’t know the latest best practices on this).