Hacker News Reader

Comment by moron4hire | Hacker News Reader

I'm confused. Isn't this already a feature of .NET Core?

Yes, this is already a thing in .NET Core 3: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...

It's not clear to me how the .NET 5 feature is different.

I'm guessing the significance is that .NET 5 unifies .NET Framework and .NET Core, and this feature is not available in .NET Framework 4.8.

My understanding is that .Net 5 is a new version of .Net Core and that the .Net framework is dead.

Microsoft naming has been executed poorly.

If you don't have daily familiarity with these tools, they are absolutely inscrutable.

Correct. This is also double trouble when Microsoft changes the names of the same product for a future release.

If you actually use the tech, it's really not that confusing

.NET 5 unifies Mono and .NET Core, not .NET Core and Framework. Previously Mono and .NET Core had different base class libraries and machine code generators (Mono using LLVM).

Mono is an implementation of the .NET Framework. While the code of v5 might be based on Mono and Core, v5 is also unifying the APIs between Core and Framework.

Most of this is already true because of .NET Standard 2.0, which latest of Mono, Framework, and Core already implement. Large swaths of the extant OSS libraries for .NET have already converted to .NET Standard 2.0. There are mostly only niche use cases left that today that you can't build into .NET Standard libraries and import into programs compiled for any of the extant CLRs.

Currently the single file solution is a zip that unzips into directory with many files. It was a great stop gap solution but not the final thing (hopefully).

Okay, didn't realize that was the case. I had used the single-file solution a few times, but mostly just for the convenience of deployment, never really paying attention to any other aspects of it.

Are the resulting files mutable?

Yes and no. .NET static binary isn't truly static. It has to decompile a folder with the dependencies in order to run.

No, publishing a .NET core project gives you tons of dlls in the publish directory, especially when publishing self-contained.

There is a flag that makes it into a single file. But the load time of this exe is very slow. It looks like it just packs all the assemblies together and extracts them during load.

I just did this for a simple project. I indeed noticed that the startup time was extremely slow. The subsequent run-time was faster though, although still not that fast. So something interesting was going on via a per-terminal session basis.

That's because the first time you start it, it actually unzips itself to a temporary folder, and then runs from there.

Which is why people should use a language that isn't riddled with issues like this. The documentation on compilation and flags is horrible BTW.

"Which is why people should use a language that isn't riddled with issues like this."

You can't pick a language based on one characteristic. Show me a language that doesn't have a long series of stupid issues. Usually you have to pick the lesser evil.

Any compiled language for Linux really don't have these types of issues. Go, Rust, C, C++, Nim, etc.

They have other issues, don't they? The flags you're complaining about are clearly marked experimental.

The only issue I'm aware of with Go is garbage collection, however that is by design.

> Any compiled language for Linux really don't have these types of issues. Go, Rust, C, C++, Nim, etc.

They have their own set of issues...

Reply on news.ycombinator.com