So, does this also replace/update the .NET Framework that is bundled with Windows 10, meaning that you can release a .NET EXE and ask people to use the latest version of the .NET like you can release a .JAR and you can ask people to have the latest version of Java, or you have to bundle the entire runtime (be it via a fat compiled AOT or regular bundling) with your application?
I ask because one of the positive things about .NET Framework 4 is that i can create a tiny .EXE and give it away and expect that people will have the runtime to run it since it is already part of Windows.
>You can now publish a single-file executable with `dotnet publish`. This form of single EXE is effectively a self-extracting executable. It contains all dependencies, including native dependencies, as resources. At startup, it copies all dependencies to a temp directory, and loads them for there. It only needs to unpack dependencies once. After that, startup is fast, without any penalty.
This is for .NET Core 3, not for .NET 5. While .NET 5 might provide the same tool, it doesn't answer if it will also provide a .NET Framework 4-like functionality where the .EXE relies on a runtime already installed on the user's system and if that framework will be something the developer will need to provide and/or be part of Windows 10 like .NET Framework 4.
Ah, got it. You want to be able to ship something that relies on an existing installed runtime and don't want to bundle the runtime with your executable.
Me too. Requiring to run all executable with a command line is a major inconvenience. And by choosing ".dll" as an extension it is not even possible to assign the extension to dotnet as a default application like you could with a jar file. And if you want self-executing binaries you not only have the version problem you mention, but you also have to bundle all sort of assemblies. And there doesn't seem to be anything like ILMerge for .net core assemblies to merge them into a single file.
What you are looking for is called a "framework-dependent executable" (exe file with no framework) rather than a "self-contained deployment" (exe wrapper for dll file with framework included) or a "framework-dependent deployment" (dll file with no framework)
> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.
> Your app can be run by calling the published executable without invoking the dotnet utility directly.
It's almost certain they'll offer the ability to publish a self-contained binary or split from dependencies since that's a feature of .Net Core 3 today. The Mono-based projects may not, but I'd expect them to someday replace what Mono targets with .Net Core. That's just a ways out and otherwise inconsequential to the end-user using the .Net 5 API.
> The term is based on the perceived process of harvesting fruit, such as cherries. The picker would be expected to only select the ripest and healthiest fruits. An observer who only sees the selected fruit may thus wrongly conclude that most, or even all, of the tree's fruit is in a likewise good condition. This can also give a false impression of the quality of the fruit (since it is only a sample and is not a representative sample).
I don’t get it. How can one executable even know how to bootstrap itself enough to know how to run a self extracting archive across Windows,MacOS,Linux?
I understand how MS did it in the past with DOS/Windows and how Apple has done it between the 68K/PPC/Intel transitions.
I understand that. But you still have to tell it which runtime to use even though you can build a Windows standalone distribution on Linux and vice versa.
They seem to implying that you can create one executable that you can distribute and it will be able to extract the needed parts on any supported platform.
That's not exactly what they're saying. In the quote above, they are talking about framework independence, not platform independence. The wrapper executables are still platform specific, but framework independent. However the actual .NET modules in the package are platform independent, but framework specific. They can be executed without the wrapper executable by installing the correct framework yourself.
And as much as people complain about Microsoft's messaging with respect to .Net, there isn't really a simple way to explain any of this -- even to people who are deep into the .Net ecosystem. I feel their pain.'
Yes but will this 'required runtime provided by the system' be part of Windows like it is with .NET Framework 4 (that is also updated automatically via Windows updates) or something that the user will have to go out of their way to install like Java?
In many cases, this is the crucial difference between deciding to bundle the runtime yourself or not.
> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.
> Your app can be run by calling the published executable without invoking the dotnet utility directly.
Well, even at present there's no guarantee the end user has the version of .net framework and libraries you need. You might need 4.8.x stuff and they only have 4.7.x. Maybe they're on win8 and not 10, or they're behind on updates, etc.
Typically the solution for this is to either sense what's installed (and use an installer) or just ship it and let the error messages help them figure out what to do.
You can't even guarantee the user has a computer. But it's a very bad idea to throw error messages at the user mid-install, and it hurts to bundle an entire framework installer inside yours. If you can target 4.7 and know it will exist on computers with windows 10, that's much better.
I ask because one of the positive things about .NET Framework 4 is that i can create a tiny .EXE and give it away and expect that people will have the runtime to run it since it is already part of Windows.