> isn't having to do things like that kind of the whole point of an airgap?

Nope. The exe files are supposed to do it's thing without internet and no extra effort like it was for a long time.

I'd call it a "yup," if we're talking about the point of an airgap. If I don't want executables contacting the outside world without my knowledge, and one is, then the airgap (or, more likely, firewall or suchlike) preventing that exe from being able to do so is a feature.

This does mean that certain programs just won't work, or won't work without some finagling. That's also a feature. The price of control is having to control things.

Granted, most people don't want to pay that price, and prefer convenience. That's admittedly not to my own taste - c.f.) log4j for a good example of why - but I think I'm maybe a little weird there. I certainly don't think there's anything audacious about catering to majority tastes. Maybe just vaguely disappointing.

Computers were able to work without internet since i was a kid. That's how me and my friends used them without any problem. Using the airgap word you are making it a new special setup that needs some special steps, some programs will not work etc. It's not a feature.

Saying people prefer one to another hides the fact that they were not given any other option. People will choose whatever default is given and then we may say they everyone prefers that. Or just make the other option (which was normal before) complicated so that nobody wants that now.

Even in the past files wouldn't magically materialize on your harddrive.

In the mini-guide above they already moved the SDK ("Software Development Kit") across the air-gap, yet creating a hello world still requires downloading even more stuff, because the .NET SDK does not actually contain enough stuff to create hello worlds, apparently?

Contrast this with e.g. Zig for Windows is a ~60 MB zip file which contains the entire Zig/C/C++ compiler with cross-compilation support for basically everything, and also has complete Win32 headers + libraries in it. There's even DDK headers in there, though I'd expect to do some legwork to build drivers for NT with Zig.

If you're happy to sacrifice the benefits of .net and spend time writing basic Win32 apps, that's totally a choice you can make. Or even just use .net framework 4.6 and not add any extra dependencies.

I'm not really sure what you're complaining about here. .net core is split into tiny packages - if that is hard to handle in your very special environment, you get to use special solutions to make it work.

That's besides the point I was making, which is that there's runtimes/languages which lean towards "internet required for development" or even "internet required for building" while there are also languages/runtimes which are self-contained and independent.

That being said, WinForms is also "just" a Win32 wrapper, I don't see a compelling reason why a similar wrapper wouldn't be possible in pretty much any language. .NET 4.6 is a fine choice too, especially because you're not forced to ship runtime and standard library, as Windows already has both.

I believe that's very much related. The more of the nice wrappers you provide, the more you have to decide if someone needs them all or are you providing them on demand. With .net core doing more splitting than framework and with Java going through a decade of jigsaw, I think we collectively decided we don't want to include everything upfront.

We don't even require the internet for building/development. In .net land you require internet to get the dependency you're using the first time. If you want to get them all and distribute/install before you start development, you can totally do that. It's just not the default behaviour.

Does that 60 MB include something like Qt, comparable to WPF? I'm not sure that comparison is fair.

Files used to materialize without internet since beginning, it's not magical. We just needed the software installer file copied to hard drive.

It's gonna blow your mind when you realize that `dotnet publish` produces an artifact that IS machine-independent, and that you would just distribute that. Or if it somehow really bothers you, put it in a self-extracting ZIP or MSI, wow, so much better. And I don't know what golden age of the Internet you grew up on, but there's always been "apps" distributed as zips, or as more than just a single binary.

I get that you have opinions, but you seem to have entirely missed that the runtime is downloaded at build time and included in the bundle. And god forbid if you like doing everything by hand, you don't have to use Nuget and you can manage every last dep by hand, however you like (and you'll likely end up hacking something that is less usable than just setting up a private nuget server, but "opinions").

>It's really not that big of a deal. You set up a package proxy that is itself behind the airgap, and you're good.

Yes, technically easy but if their work environment is strict enough to enforce air gapped development, I imagine the bureaucratic process to accomplish such a thing to be a bit less than easy.

> set up a packaging proxy to [connect with a system outside the airgapped computer]

Do you even know what an airgapped computer is?

It’s not that kind of proxy.