7 ms·

This article will confuse people since the executable in question requires a runtime installed on the system (in fact, it uses .NET Framework 4.7.2, in 2023!).

This article will confuse people since the executable in question requires a runtime installed on the system (in fact, it uses .NET Framework 4.7.2, in 2023!). Most likely fair comparison for such solution would be .jar or even .py files. A good source of truth for an actual executable would be Native AOT binary, which can run on Windows, Linux or macOS. Naturally, it will be much larger, having to incorporate GC, possibly ThreadPool, Console and other auxiliary code.

Kwpolska 3y ago
The .NET Framework is built into Windows, and a mandatory component of it since at least Vista. .NET Framework 4.7.2 specifically should be built-in on supported Windows versions.
- ad404b8a372f2b9 3y ago
  You never have the right version installed though. Every time I've tried to install a .NET program it's always asked me to install a different version than the one I had.
  - CrendKing 3y ago
    Sounds like confirmation bias, because when the right version of .NET is ever used, you probably never knew it was a .NET program to begin with.
    - ntdll 3y ago
      Not true in my experience. The "look and feel" of the program usually gives it away more or less immediately.
      - grujicd 3y ago
        Probably, if that app uses WPF, which is "self-drawn" GUI library. However, if .Net app uses WinForms, that API is just a wrapper over standard Win32 controls and it looks like any other old school Win app.
        ntdll 3y ago
        You're right, but there are a few subtle differences here and there that often make Windows Forms recognizable. The best example I got off the top of my head is KeePass v1 [0] and KeePass v2 [1]. v1 is written in C++ with native controls, and v2 uses Windows Forms. If you look at the menu bar and the toolbar, you'll see a difference. Most notably the drag handle on the left, and the search box on the right, in v2. The difference is often a bit easier to spot on Windows 7. [0]: https://keepass.info/screenshots/main_big.png https://keepass.info/screenshots/main_big.png [1]: https://keepass.info/screenshots/keepass_2x/main_big.png https://keepass.info/screenshots/keepass_2x/main_big.png
        userbinator 3y ago
        The blurrier font in the non-native one is another difference.
      - EMM_386 3y ago
        > The "look and feel" of the program usually gives it away more or less immediately. If you are talking about the base controls, then maybe. But there are .Net cross-platform frameworks such as Avalonia that can get you a modern loooking UI with theming. https://github.com/irihitech/Semi.Avalonia https://github.com/irihitech/Semi.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia etc.
- TillE 3y ago
  I'm surprised Microsoft still isn't pushing .NET 6 (and the MSVC runtime, for that matter) to everyone with Windows Update. They're not very large, most consumers will want them, and picky enterprises could opt out. It's an odd annoyance that Windows developers have to deal with.
  - formerly_proven 3y ago
    Congruent with runtimes (both .NET and native) for Microsoft languages always being kinda weird. "Uh yeah don't use that CRT in %WINDIR%, that's not supported! Everyone need to bring their own... but not as loose DLLs, that's not allowed! Use the MSI package and install it whenever!" (I think most of those restrictions have been removed in the last couple years, and MS also settled down on VC++ ABI and VCRT changes and introduced UCRT in Windows 10, so)
  - Uvix 3y ago
    They push updates to .NET if it’s installed. I can understand them not installing if it’s absent, because there’s no good story for what to do when that version goes out of support. If they leave it, then customers have insecure unsupported software on their systems; if they remove it, they’ll break apps that depend on it.
  - pjmlp 3y ago
    Because the modern way is to ship it with the application and preferably use trimming.
  - electroly 3y ago
    Getting your thing adopted as a Windows component and distributed by Windows Update is a common trap for Microsoft developers. It's always a mistake if you're in some DevDiv or random app team instead of the Windows team. Windows is the slowest-moving product that Microsoft has, and users don't install updates. Hitching your wagon to Windows means no two users will have the same version installed, and getting people to update .NET via Windows Update is a nightmare. God forbid the Windows team decides to stop supporting a version of Windows that is still commonly use in industry; they'll never get a .NET update again. As a user, think about how annoying it is to get a message saying you need to run Windows Update before you can start an application. Totally unnecessary own-goal for the team that decided to ship their independent component in Windows Update. It's way easier to either 1.) go self-contained, or 2.) use the on-the-fly .NET download for a framework-dependent build. I absolutely think they made the right call removing current .NET as a Windows component. The annoyance was far greater when .NET Framework was part of Windows.
weinzierl 3y ago
A comparison between a fully statically linked native binary and one that loads some or all libraries dynamically would equally be vastly unfair. I think comparing container images would be a good start. Use the most minimal base image you can get away with, or even "FROM scratch" if possible, but compare only images with the same architecture. I'd prefer 32-bit, to take things like running 32-bit on 64-bit or 64-bit with pointer compression out of the picture. Then compare the size of the uncompressed exported tar. Probably also not completely fair, depending on what question you want to answer but it takes the obvious variances out of the equation. EDIT: Thinking about it some more, it might even be more fair to compare maximally compressed image size to account for compression within the container. Of course you'd have to compress with the same algorithm and parameters or just add the decompressors size to the final result like they do in compression benchmarks.
- whartung 3y ago
  It’s funny because back in the day these were these kind of discussion points thrown around in the Lisp forums when folks would balk at “executable sizes”. Specifically about how C leverages the “free” runtime of the OS while Lisp has to bundle is own. This idea of container runtime sizes would be an amusing thread. A good test of something like Nix or Guix to a very fine grain. “We don’t need bash or ls so we removed it. “ “The VM only simulate a single network card, so we’ll scrap all the other driver. “
  - kazinator 3y ago
    C doesn't leverage the free run time of the OS, when that OS is Windows. Your hello.exe size has to include the run-time DLL's required for it from the C implementation that was used to build it. Windows has only recently been moving toward providing a public run-time for C; the "Universal C Run-Time" (UCRT) that has been introduced in Windows 10.
    - ChrisSD 3y ago
      The ucrt is included as far back as Windows 7 (if you install updates).
why_only_15 3y ago
On MacOS at least all binaries are dynamic (except dyld itself) so I think this is fair. This is because everything is supposed to link I believe some kind of runtime dylib instead of doing e.g. syscalls. This includes anything written in C, for example. Size of binary with dynamic links is the most fair comparison between anything running not on Linux.
- grishka 3y ago
  According to Apple you are supposed to link to libSystem.dylib for syscalls, but there's obviously nothing stopping you from calling into the kernel directly.
  - msla 3y ago
    > According to Apple you are supposed to link to libSystem.dylib for syscalls, but there's obviously nothing stopping you from calling into the kernel directly. As a matter of OS design, this is no longer obvious: https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ > A new mechanism to help thwart return-oriented programming (ROP) and similar attacks has recently been added to the OpenBSD kernel. It will block system calls that are not made via the C library (libc) system-call wrappers. MacOS doesn't implement that, sure, but it could.
H8crilA 3y ago
I think this will miss the point though. You can consider the specific .NET runtime as its own compute platform / operating system, regardless of what has to be installed on the machine for the program to actually run, and explore the limits of it. It will teach you a great deal about the binary format of the programs. You can do this for any format that stores executables, for any programming framework. .jar might be interesting, .py obviously isn't. You can do this for obscure old formats, or for something very common like the standard Linux .elf.
- tempodox 3y ago
  I disagree. I cross-compile F# sources with .NET on my Mac to get a stand-alone Linux executable without additional dependencies that I can upload to my server host. It's enough that I maintain the .NET stuff on my development host, I've got no desire to duplicate that work on the public host.
  - H8crilA 3y ago
    What do you disagree with?
    - tempodox 3y ago
      Considering the runtime as something separate from a single program. I want both in the same binary.
      - H8crilA 3y ago
        It's not about considering this or that, but about making a fun little exercise that tells you how the binary format works.
- BiteCode_dev 3y ago
  > .py obviously isn't Although .zipapp is to Python what .jar is to .py. Probably even closer to .war. But for purely stand alone stuff, "nuitka3 /tmp/hello.py --standalone" does output a executable that can be used without the user to manually bring in the Python run time. In that case, the hello world is about 16Mb on Ubuntu. It would be interesting to do this with MicroPython though.
bombcar 3y ago
My hello world requires the "bash" framework and is zero bytes. You call it via: echo "hello world"
- bdhcuidbebe 3y ago
  I’m intrigued, please share your 100% text compression rate algorithm!
  - bombcar 3y ago
    Just make sure you have a filesystem that can take arbitrary-length filenames! Then you can compress to zero byte file with a very long filename ;)
    - bdhcuidbebe 3y ago
      I guess if you store the filetable in unlimited S3 storage, maybe ;-)
      - reilly3000 3y ago
        TXT records in Route 53 for 100% SLA
  - anoncow 3y ago
    Infinity compression.
    - osigurdson 3y ago
      I once ran gzip and infinite number of times on a text file. I was surprised at the result.
      - besnn00 3y ago
        Should it become idempotent after a certain number of iterations? What were the results?
foepys 3y ago
.NET Framework is still officially supported and targeting anything higher than 4.7.2 is unnecessary since there are no new APIs in 4.8. 4.8 is just a drop-in replacement for 4.7.2 with things like better high DPI support.
- Deukhoofd 3y ago
  How about any of the modern .NET versions? They're on .NET 7.0.8 nowadays.
  - TrueSlacker0 3y ago
    .net core is at 7. This article is about. Net framework which stopped at 4.8
    - Deukhoofd 3y ago
      .NET Core stopped being called .NET Core at version 3, after which it was renamed .NET, and Microsoft announced it was meant to supersede the old legacy .NET Framework. The article opens with asking itself how to get the smallest .NET executable, and then for some reason limits itself to this legacy version.
      - Kwpolska 3y ago
        .NET Framework 4.x is built into Windows, and .NET Framework 4.x binaries are understood by the Windows executable loader. The modern .NET must be manually installed and the executables must take care of launching the runtime on their own.
      - marcosdumay 3y ago
        > Microsoft announced it was meant to supersede the old legacy .NET Framework What actually never happened, to nobody's surprise. So now we have .Net that was renamed into .Net Framework that is legacy, .Net Core that is legacy but compatible with the modern version, and .Net that is current. Anyway, the platform never stopped being called .Net, because it's larger than just the runtime. We also have 2 different number sequences starting from 1, and one starting from... some times 4, other times 6, depends on your point of view. We also have a bunch of confused people without any reason, because all of this is as clear as water. But anyway, it's not the author fault that he didn't communicate the version in an adequate way.
brookst 3y ago
Do we care about “fairness” or “reality”? Since it’s impossible to have a modern Windows install without .net, and Linux and MacOS don’t have it by default, it seems an odd way to be “fair”
- deely3 3y ago
  > Windows install without .net correction: without some specific version of .net.
  - ptspts 3y ago
    Is there backwards compatibility between .NET Framework versions? Which version number should I request in my ultraportable executable? (Java seems to work fine most of the time eith.some javac flags.)
    - password4321 3y ago
      > Is there backwards compatibility between .NET Framework versions? In theory: yes. In practice: mostly. There can only be one .NET Framework 4 installed at a time; the recent changes are found at https://learn.microsoft.com/en-us/dotnet/framework/whats-new https://learn.microsoft.com/en-us/dotnet/framework/whats-new. > Which version number should I request in my ultraportable executable? This gets tricky if you want to support more than Microsoft does. Here is the details on recent .NET Framework versions per OS: https://learn.microsoft.com/en-us/dotnet/framework/install/guide-for-developers https://learn.microsoft.com/en-us/dotnet/framework/install/g... and ancient of days: https://learn.microsoft.com/en-us/archive/blogs/astebner/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os https://learn.microsoft.com/en-us/archive/blogs/astebner/mai.... For example: Microsoft currently supports Windows 10+, which first included .NET Framework 4.6. However, Microsoft only currently supports v4.6.2+, and v4.8 has been "Windows Update"'d since May 2019. I personally bumped an old open source project from v3.5 to v4.8 recently because of how hard it was for myself as a returning contributor to build these days.
      - 3y ago
sbjs 3y ago
Closer analogy would be .pyc files. Precompiled bytecode.
pjmlp 3y ago
Microsoft themselves just released a new product based on .NET Framework 4.7.2, so don't be that hard on the authors. https://www.infoq.com/news/2023/06/logic-apps-custom-code/ https://www.infoq.com/news/2023/06/logic-apps-custom-code/
- aardvarkr 3y ago
  That’s a logic app plugging that allows for compatibility with framework code. M$ is a behemoth that supports old legacy code from businesses that don’t want to upgrade so I’m not surprised that they’re making things like logic apps compatible but this isn’t really a “new product based on framework”.
- SirMaster 3y ago
  As far as I understand, VS 2022 is also written in .NET Framework. I am not sure exactly which version though.
ramesh31 3y ago
>This article will confuse people since the executable in question requires a runtime installed on the system (in fact, it uses .NET Framework 4.7.2, in 2023!). That's fair though. The post is titled "the smallest .NET hello world binary", not "the smallest C# hello world binary"
ComputerGuru 3y ago
Not necessarily - the actual output exe doesn't actually use the .NET framework for anything at all, besides invoking the main. The actual logic of outputting the bytes to the console is done via a pinvoke (c# ffi) call to the underlying unmanaged (non-.net) code exposed by ucrt.dll But anyway, this other article [0] (shared in another comment here) about creating the smallest version of Snake (the game) was done on top of .NET Core (the new version of .NET that isn't bundled with Windows) and effectively does the same thing, but actually produces a non-.NET binary, if that's more to your taste. [0]: https://medium.com/@MStrehovsky/building-a-self-contained-game-in-c-under-8-kilobytes-74c3cf60ea04 https://medium.com/@MStrehovsky/building-a-self-contained-ga...
- sedatk 3y ago
  > the actual output exe doesn't actually use the .NET framework for anything at all except for runtime environment initialization, JIT compilation, and execution.
  - deleted 3y ago
    [deleted]
niutech 3y ago
For a tiny, single cross-platform binary, check out Cosmopolitan libc.
fennecfoxy 3y ago
Always see this sort of pedanticism with topics. Are we gonna start counting the bytes of firmware on all chips on motherboard as well? Display drivers and firmware of various mcus used in the computer monitor itself?

Kwpolska 3y ago

The .NET Framework is built into Windows, and a mandatory component of it since at least Vista. .NET Framework 4.7.2 specifically should be built-in on supported Windows versions.

ad404b8a372f2b9 3y ago
You never have the right version installed though. Every time I've tried to install a .NET program it's always asked me to install a different version than the one I had.
- CrendKing 3y ago
  Sounds like confirmation bias, because when the right version of .NET is ever used, you probably never knew it was a .NET program to begin with.
  - ntdll 3y ago
    Not true in my experience. The "look and feel" of the program usually gives it away more or less immediately.
    - grujicd 3y ago
      Probably, if that app uses WPF, which is "self-drawn" GUI library. However, if .Net app uses WinForms, that API is just a wrapper over standard Win32 controls and it looks like any other old school Win app.
      - ntdll 3y ago
        You're right, but there are a few subtle differences here and there that often make Windows Forms recognizable. The best example I got off the top of my head is KeePass v1 [0] and KeePass v2 [1]. v1 is written in C++ with native controls, and v2 uses Windows Forms. If you look at the menu bar and the toolbar, you'll see a difference. Most notably the drag handle on the left, and the search box on the right, in v2. The difference is often a bit easier to spot on Windows 7. [0]: https://keepass.info/screenshots/main_big.png https://keepass.info/screenshots/main_big.png [1]: https://keepass.info/screenshots/keepass_2x/main_big.png https://keepass.info/screenshots/keepass_2x/main_big.png
        userbinator 3y ago
        The blurrier font in the non-native one is another difference.
    - EMM_386 3y ago
      > The "look and feel" of the program usually gives it away more or less immediately. If you are talking about the base controls, then maybe. But there are .Net cross-platform frameworks such as Avalonia that can get you a modern loooking UI with theming. https://github.com/irihitech/Semi.Avalonia https://github.com/irihitech/Semi.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia etc.
TillE 3y ago
I'm surprised Microsoft still isn't pushing .NET 6 (and the MSVC runtime, for that matter) to everyone with Windows Update. They're not very large, most consumers will want them, and picky enterprises could opt out. It's an odd annoyance that Windows developers have to deal with.
- formerly_proven 3y ago
  Congruent with runtimes (both .NET and native) for Microsoft languages always being kinda weird. "Uh yeah don't use that CRT in %WINDIR%, that's not supported! Everyone need to bring their own... but not as loose DLLs, that's not allowed! Use the MSI package and install it whenever!" (I think most of those restrictions have been removed in the last couple years, and MS also settled down on VC++ ABI and VCRT changes and introduced UCRT in Windows 10, so)
- Uvix 3y ago
  They push updates to .NET if it’s installed. I can understand them not installing if it’s absent, because there’s no good story for what to do when that version goes out of support. If they leave it, then customers have insecure unsupported software on their systems; if they remove it, they’ll break apps that depend on it.
- pjmlp 3y ago
  Because the modern way is to ship it with the application and preferably use trimming.
- electroly 3y ago
  Getting your thing adopted as a Windows component and distributed by Windows Update is a common trap for Microsoft developers. It's always a mistake if you're in some DevDiv or random app team instead of the Windows team. Windows is the slowest-moving product that Microsoft has, and users don't install updates. Hitching your wagon to Windows means no two users will have the same version installed, and getting people to update .NET via Windows Update is a nightmare. God forbid the Windows team decides to stop supporting a version of Windows that is still commonly use in industry; they'll never get a .NET update again. As a user, think about how annoying it is to get a message saying you need to run Windows Update before you can start an application. Totally unnecessary own-goal for the team that decided to ship their independent component in Windows Update. It's way easier to either 1.) go self-contained, or 2.) use the on-the-fly .NET download for a framework-dependent build. I absolutely think they made the right call removing current .NET as a Windows component. The annoyance was far greater when .NET Framework was part of Windows.

weinzierl 3y ago

A comparison between a fully statically linked native binary and one that loads some or all libraries dynamically would equally be vastly unfair. I think comparing container images would be a good start. Use the most minimal base image you can get away with, or even "FROM scratch" if possible, but compare only images with the same architecture. I'd prefer 32-bit, to take things like running 32-bit on 64-bit or 64-bit with pointer compression out of the picture. Then compare the size of the uncompressed exported tar. Probably also not completely fair, depending on what question you want to answer but it takes the obvious variances out of the equation. EDIT: Thinking about it some more, it might even be more fair to compare maximally compressed image size to account for compression within the container. Of course you'd have to compress with the same algorithm and parameters or just add the decompressors size to the final result like they do in compression benchmarks.

whartung 3y ago
It’s funny because back in the day these were these kind of discussion points thrown around in the Lisp forums when folks would balk at “executable sizes”. Specifically about how C leverages the “free” runtime of the OS while Lisp has to bundle is own. This idea of container runtime sizes would be an amusing thread. A good test of something like Nix or Guix to a very fine grain. “We don’t need bash or ls so we removed it. “ “The VM only simulate a single network card, so we’ll scrap all the other driver. “
- kazinator 3y ago
  C doesn't leverage the free run time of the OS, when that OS is Windows. Your hello.exe size has to include the run-time DLL's required for it from the C implementation that was used to build it. Windows has only recently been moving toward providing a public run-time for C; the "Universal C Run-Time" (UCRT) that has been introduced in Windows 10.
  - ChrisSD 3y ago
    The ucrt is included as far back as Windows 7 (if you install updates).

why_only_15 3y ago

On MacOS at least all binaries are dynamic (except dyld itself) so I think this is fair. This is because everything is supposed to link I believe some kind of runtime dylib instead of doing e.g. syscalls. This includes anything written in C, for example. Size of binary with dynamic links is the most fair comparison between anything running not on Linux.

grishka 3y ago
According to Apple you are supposed to link to libSystem.dylib for syscalls, but there's obviously nothing stopping you from calling into the kernel directly.
- msla 3y ago
  > According to Apple you are supposed to link to libSystem.dylib for syscalls, but there's obviously nothing stopping you from calling into the kernel directly. As a matter of OS design, this is no longer obvious: https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ > A new mechanism to help thwart return-oriented programming (ROP) and similar attacks has recently been added to the OpenBSD kernel. It will block system calls that are not made via the C library (libc) system-call wrappers. MacOS doesn't implement that, sure, but it could.

H8crilA 3y ago

I think this will miss the point though. You can consider the specific .NET runtime as its own compute platform / operating system, regardless of what has to be installed on the machine for the program to actually run, and explore the limits of it. It will teach you a great deal about the binary format of the programs. You can do this for any format that stores executables, for any programming framework. .jar might be interesting, .py obviously isn't. You can do this for obscure old formats, or for something very common like the standard Linux .elf.

tempodox 3y ago
I disagree. I cross-compile F# sources with .NET on my Mac to get a stand-alone Linux executable without additional dependencies that I can upload to my server host. It's enough that I maintain the .NET stuff on my development host, I've got no desire to duplicate that work on the public host.
- H8crilA 3y ago
  What do you disagree with?
  - tempodox 3y ago
    Considering the runtime as something separate from a single program. I want both in the same binary.
    - H8crilA 3y ago
      It's not about considering this or that, but about making a fun little exercise that tells you how the binary format works.
BiteCode_dev 3y ago
> .py obviously isn't Although .zipapp is to Python what .jar is to .py. Probably even closer to .war. But for purely stand alone stuff, "nuitka3 /tmp/hello.py --standalone" does output a executable that can be used without the user to manually bring in the Python run time. In that case, the hello world is about 16Mb on Ubuntu. It would be interesting to do this with MicroPython though.

bombcar 3y ago

My hello world requires the "bash" framework and is zero bytes. You call it via: echo "hello world"

bdhcuidbebe 3y ago
I’m intrigued, please share your 100% text compression rate algorithm!
- bombcar 3y ago
  Just make sure you have a filesystem that can take arbitrary-length filenames! Then you can compress to zero byte file with a very long filename ;)
  - bdhcuidbebe 3y ago
    I guess if you store the filetable in unlimited S3 storage, maybe ;-)
    - reilly3000 3y ago
      TXT records in Route 53 for 100% SLA
- anoncow 3y ago
  Infinity compression.
  - osigurdson 3y ago
    I once ran gzip and infinite number of times on a text file. I was surprised at the result.
    - besnn00 3y ago
      Should it become idempotent after a certain number of iterations? What were the results?

foepys 3y ago

.NET Framework is still officially supported and targeting anything higher than 4.7.2 is unnecessary since there are no new APIs in 4.8. 4.8 is just a drop-in replacement for 4.7.2 with things like better high DPI support.

Deukhoofd 3y ago
How about any of the modern .NET versions? They're on .NET 7.0.8 nowadays.
- TrueSlacker0 3y ago
  .net core is at 7. This article is about. Net framework which stopped at 4.8
  - Deukhoofd 3y ago
    .NET Core stopped being called .NET Core at version 3, after which it was renamed .NET, and Microsoft announced it was meant to supersede the old legacy .NET Framework. The article opens with asking itself how to get the smallest .NET executable, and then for some reason limits itself to this legacy version.
    - Kwpolska 3y ago
      .NET Framework 4.x is built into Windows, and .NET Framework 4.x binaries are understood by the Windows executable loader. The modern .NET must be manually installed and the executables must take care of launching the runtime on their own.
    - marcosdumay 3y ago
      > Microsoft announced it was meant to supersede the old legacy .NET Framework What actually never happened, to nobody's surprise. So now we have .Net that was renamed into .Net Framework that is legacy, .Net Core that is legacy but compatible with the modern version, and .Net that is current. Anyway, the platform never stopped being called .Net, because it's larger than just the runtime. We also have 2 different number sequences starting from 1, and one starting from... some times 4, other times 6, depends on your point of view. We also have a bunch of confused people without any reason, because all of this is as clear as water. But anyway, it's not the author fault that he didn't communicate the version in an adequate way.

brookst 3y ago

Do we care about “fairness” or “reality”? Since it’s impossible to have a modern Windows install without .net, and Linux and MacOS don’t have it by default, it seems an odd way to be “fair”

deely3 3y ago
> Windows install without .net correction: without some specific version of .net.
- ptspts 3y ago
  Is there backwards compatibility between .NET Framework versions? Which version number should I request in my ultraportable executable? (Java seems to work fine most of the time eith.some javac flags.)
  - password4321 3y ago
    > Is there backwards compatibility between .NET Framework versions? In theory: yes. In practice: mostly. There can only be one .NET Framework 4 installed at a time; the recent changes are found at https://learn.microsoft.com/en-us/dotnet/framework/whats-new https://learn.microsoft.com/en-us/dotnet/framework/whats-new. > Which version number should I request in my ultraportable executable? This gets tricky if you want to support more than Microsoft does. Here is the details on recent .NET Framework versions per OS: https://learn.microsoft.com/en-us/dotnet/framework/install/guide-for-developers https://learn.microsoft.com/en-us/dotnet/framework/install/g... and ancient of days: https://learn.microsoft.com/en-us/archive/blogs/astebner/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os https://learn.microsoft.com/en-us/archive/blogs/astebner/mai.... For example: Microsoft currently supports Windows 10+, which first included .NET Framework 4.6. However, Microsoft only currently supports v4.6.2+, and v4.8 has been "Windows Update"'d since May 2019. I personally bumped an old open source project from v3.5 to v4.8 recently because of how hard it was for myself as a returning contributor to build these days.
    - 3y ago

sbjs 3y ago

Closer analogy would be .pyc files. Precompiled bytecode.

pjmlp 3y ago

Microsoft themselves just released a new product based on .NET Framework 4.7.2, so don't be that hard on the authors. https://www.infoq.com/news/2023/06/logic-apps-custom-code/ https://www.infoq.com/news/2023/06/logic-apps-custom-code/

aardvarkr 3y ago
That’s a logic app plugging that allows for compatibility with framework code. M$ is a behemoth that supports old legacy code from businesses that don’t want to upgrade so I’m not surprised that they’re making things like logic apps compatible but this isn’t really a “new product based on framework”.
SirMaster 3y ago
As far as I understand, VS 2022 is also written in .NET Framework. I am not sure exactly which version though.

ramesh31 3y ago

>This article will confuse people since the executable in question requires a runtime installed on the system (in fact, it uses .NET Framework 4.7.2, in 2023!). That's fair though. The post is titled "the smallest .NET hello world binary", not "the smallest C# hello world binary"

ComputerGuru 3y ago

Not necessarily - the actual output exe doesn't actually use the .NET framework for anything at all, besides invoking the main. The actual logic of outputting the bytes to the console is done via a pinvoke (c# ffi) call to the underlying unmanaged (non-.net) code exposed by ucrt.dll But anyway, this other article [0] (shared in another comment here) about creating the smallest version of Snake (the game) was done on top of .NET Core (the new version of .NET that isn't bundled with Windows) and effectively does the same thing, but actually produces a non-.NET binary, if that's more to your taste. [0]: https://medium.com/@MStrehovsky/building-a-self-contained-game-in-c-under-8-kilobytes-74c3cf60ea04 https://medium.com/@MStrehovsky/building-a-self-contained-ga...

sedatk 3y ago
> the actual output exe doesn't actually use the .NET framework for anything at all except for runtime environment initialization, JIT compilation, and execution.
- deleted 3y ago
  [deleted]

niutech 3y ago

For a tiny, single cross-platform binary, check out Cosmopolitan libc.

fennecfoxy 3y ago

Always see this sort of pedanticism with topics. Are we gonna start counting the bytes of firmware on all chips on motherboard as well? Display drivers and firmware of various mcus used in the computer monitor itself?