> In .NET 6, in-memory single file apps have been enabled for Windows and macOS. In .NET 5, this deployment type was limited to Linux. You can now publish a single-file binary that is both deployed and launched as a single file, for all supported OSes. Single files apps no longer extract any core runtime assemblies to temporary directories.
This is a great! Now I can publish statically linked executables and run it everywhere. I don't have to tolerate Golang and its quirks just to have cross-compilation and static binaries, even though they will be larger in size.
Wait, wait… .Net can build “static linked” executables that doesn’t require that I install .Net to run? I had no idea, I guess it’s time to revisit .Net
I haven't used .net. But how memory management happens when you are running a binary executable? Does it have a builtin CLR (Common Language Runtime[1])? Because CLR provides the tools for managing memory & security?
I've been using this for at least a year or two. With their stripping, my binaries (which use very little other than system.* and math.*) are 12M in size on each OS. I tested with today's release of version six, the binaries are about 1M smaller each.
This, combined with linker stripping below even assembly level for smaller static binaries.
.NET 7 will work on NativeAOT for instantaneous startup of especially smaller apps, but I think they’ve already optimized JIT warmups or something — I was pleasantly surprised when I just wrote a .NET 6 console app that read JSON from a server.
If it's like v5, you can. They're big (since they include .NET, though it looks like v6 will strip out more than v5). And they won't run on Windows 7 without an administrator installing a system component first.
For an internal tool that reformats our code base, I've used that to pack the `dotnet format` (although technically, not allowed case, since it's a tool, and need to be run from an "sdk" environment). It works for what we use it (whitespace formatting, but not for msbuild/analysis - which is clearly understood).
One thing though, is that native .dlls are still outside (DetoursServices.dll for example in BuildXL). But still pretty impressive what it can done. That, and the new embedded .pdb (for .NET only, e.g. not native).
I wish "publish" was used more by the place I work for (most of the folks would simply Release (F5) and store what's there in p4). I've only recently discovered about "publish" and that is after haven't worked with .NET for so long...
msbuild had publish since at least .net 3.5 (when I started to use the platform) it was just a little bit akward to use tough. and of course dotnet publish is 1000x better than msbuild with it's obscure syntax (which got way better in .net5 and 6 with -p: syntax, etc.)
Also If I'm not mistaken most of the properties (if not all) can be set through the command-line (for good and bad :)), e.g. `set Property=Value && msbuild` or `Property=Value msbuild` (on unix systems)
>> 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?
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.
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...
Yea, funny :D However, the problem was mostly deploying dotnet apps on servers which did not have dotnet installed. Windows has .NET installed anyway, so there the problem did not really exist
Understandable, but it's a matter of taste. For people who prefer a language with exception, it's good that there now exist a viable solution other than sticking to a language that might not fit their taste so well.
It seems to me that F# could get a bit more love from HN-style nerds. Obviously, it's more similar to C# than Golang, but specifically error handling can be done in much nicer way using the Result type.
As a personal choice, would rather use Vlang than Nim. Like the potential and what I'm seeing from Vlang, though was hoping the cross-platform UI would be further along. As it is, they are developing quite quickly.
Not wanna bring down that project, but be wary of V, as in the past it has made plenty of impossible to live up to “features” and indeed, never delivered. But I haven’t followed it since then.
I'm aware of the controversy, and I've been following its development for some time now. It seems to be developed at a neck-breaking pace, but I'm still waiting for an official "go!" license before I start playing with it.
I hope they succeed because it has/promises a really attractive set of features.
Java has had AOT compilation since around 2000, just not as free beer.
In 2021, the AOT free beer exists, as do JIT caches.
As for OO model, I rather be able to understand which interfaces a type implements by looking at it, instead of producing compiler errors, or have a type by accident supporting a single method interface with complete different semantics.
GraalVM is a thing (see: www.quarkus.io for an example) if fast startup and low memory usage are a requirement.
Not sure what the OO rant is about, it's awesome. It's not like golang isn't (poorly implemented) OO as well (minus explicit inheritance, which embedding is somewhat similar as well).
This is a great! Now I can publish statically linked executables and run it everywhere. I don't have to tolerate Golang and its quirks just to have cross-compilation and static binaries, even though they will be larger in size.