Hacker News Reader

Comment by kreeben | Hacker News Reader

>> Single files apps no longer extract any core runtime assemblies to temporary directories

I might be ignorant here but if you're not specifically pointing out what version DLL's you want, aren't you in fact publishing a dynamically linked executable instead of a statically linked one?

Doesn't these single-file apps rely on the GAC?

View on HN

There is no GAC.

> .NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC)

Interesting. I haven't worked in .NET for several years now, but the GAC was always an absolute headache to deal with.

Thankfully they did not port this hell to Linux

Surely the binaries generated by the JIT still get cached somewhere?

you can set a ReadyToRun flag on publish which pre jits your dlls https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...

The whole runtime gets included in the binary.

This actually makes sense in 2021 since we have the resources to allow things like this. 20 years ago this might have seemed insane.

Keep in mind that it's just one option. If you want, you can still deploy your app separately from the .Net runtime.

Also, to keep the size at least somewhat in check, unused parts of the base library are not included in the single-file mode.

Keeping in mind it's also a double edge sword. TLS deprecations alone will ensure your app will die after a few years if it doesn't run on an up-to-date CLR.

This sounds quite the argument for basing critical workflows only on software for which the user has both access and permission to modify the source code.

Timezone and DST fuckery is another, I assume?

30 years ago we used DOS and DLL Hell was a completely unknown concept. We did have to deal with himem.sys though.

On the contrary, 30 years ago we were using Windows 3.0, which is about when dll hell started being a real thing.

(DLL hell stopped being a problem a lot sooner than you probably think, too...)

>DLL hell stopped being a problem a lot sooner than you probably think, too

Does not match my experience at work unfortunately.

If you're seeing this on any version of Windows made in the last 22 years or so, it's because a software developer fucked up in a really creative way. My condolences.

Sometimes the issue is that people have tended to conflate "dll hell" and "dependency hell." That's an old pet peeve of mine and I realize it doesn't matter...

"Insert floppy disk 435 of 880 and press [Enter] when ready..."

Invalid media type

Abort, Retry, Fail?

FFFFFFFUUUUUUUUCCCCCCKKKKK!!!!!!

Does this mean you need one binary per OS so that the runtime matches, or do they do some magic so that one single binary can run on all Oses ?

You create a single binary which has the runtime and dependencies self contained within.

You of course have to choose your target platform for this as it makes .exes for Windows, ELFs for Linux, etc.

If you want you can still choose to distribute IL DLLs and users then use their already installed dotnet on their machine to run them.

> You of course have to choose your target platform for this (...)

https://github.com/jart/cosmopolitan

(but, yeah, you probably want one version per target, even if hacks are cool)

You create one binary per OS.

How much does this add to the binary's size?

Something like 60MB if the application is not trimmed. Closer to 10MB if the application can be trimmed.

In my case about 60MB

Reply on news.ycombinator.com