Are the new self-contained . NET executables really native?

Question

In that question here, was discussed about whether there is a need to install . NET 5 (or .NET Core 3) on the machine to run compiled executables, and the answer is:

No, the . NET 5 is not installable, just like any . NET Core which at the bottom is the . NET 5. It generates a self-contained application with everything you need and so just copy on the machine and run straight. Calls and runs, simple like this.

^{@Maniero in reply accepted the abovementioned question. Withdrawn 30/09/2019 at 11:00.}

The question is: since these executables are Runtime-Less, that is, they do not need an external dependency on the machine to run (like the .NET Framework), they are native executables on the platforms intended for?

• For example, the .exe generated is a Win32 executable? There is a MSIL/CIL behind it or its code is equal done in C (generated a x86 direct to the structure and architecture of .exe)?
• If yes, how does it work? It is a transpilation or direct compilation to machine code?
• These executables depend on a Just-in-time Compiler for execution or I can run in a minimal Windows scenario (such as Safe Mode)?
• It’s the same process for other platforms with different architectures?
• I won’t need to install the dotnet on Linux and running an executable with dotnet .\meuExecutavel.dll? _(Example)

Answer 1

No, at least in normal form. Files that look executable are not completely executable like this, they have a bytecode and not a ready-to-run code. It is encapsulated in the same file type as a normal executable, but it only has code that the . NET understands, that is multi platform and not for a specific.

This is not to say that you may not have some files in your solution that is not even executable. For example if you use and send the Sqlite along with your application this executable is fully native and has to be for the specific platform it will run.

If to use this normal way you always need something extra to run this file because it is not exactly an executable.

But it’s all evolving and now it’s not. NET Core 3 is already possible that everything you need is in an executable, even those files I mentioned above can be together, so you call and it knows how to start the execution and knows that there are several things inside it that will be used for the actual execution, but it’s just an extra level of abstraction.

This may sound strange but it is as if this executable file has other files inside it, executable or not. This main file that you view and copy is executable and is specific to the platform that will run. The files inside are not (necessarily) specific (you may have some, like the Sqlite file I mentioned), you can even have text files. Inside there may be what we know today as Dlls. NET and that we used to see as executables, these will remain equal in this mode, they will perform after the Jitter process.

Actually since Mono already exists a solution and now in . NET Core also has to instead of you use the Jitter to generate native platform code in memory at the time it is running it is possible to generate the native executable and therefore specific to a platform.

With the . NET 5 this will be more consolidated and will have a new mode that generates 100% native code, almost as if it were done in C++ to give a comparison.

Realized you now have several ways to deliver your application?

For example, is the generated . exe a Win32 executable? There is an MSIL/CIL behind it or its code is equal done in C (generated a x86 direct to the structure and architecture of . exe)?

It depends on which way you are speaking :) If it is this new self-contained form it will be one .exe Win32, known as PE format (something close here), in its base to start running, or if it is in Linux will use ELF format (Mach-O on Mac). This executable will have something x86 to manage all this, but your application will not be x86 direct, it still works the way it was before, it’s all in one thing.

There will be a way that the executable will be x86, for example, equal C, as said above, but it is another way to deliver.

If yes, how does it work? It is a transpilation or direct compilation to machine code?

Today it does not have this, when it has will generate machine code straight. An old test used the backend from the C++ compiler to do this, but it should not be so in . NET 5 (I am not guaranteeing).

These executables depend on a Just-in-time Compiler for execution or I can run in a minimal Windows scenario (such as Safe Mode)?

The current one depends on it. When you can produce the native one, it doesn’t. There’s even an advantage to having Jitter because now it can do extra optimizations that the pure executable can’t, the Jitter’s. NET has improved a lot in this, so it’s breaking performance records. So it still has the same limitations as before. What is native in the future can run well anywhere that accepts any executable.

That native I speak is a new mode of . NET 5 and not the .NET Native which is dead, for all intents and purposes. It’s certainly very similar, but it’s better, the . NET Native had important limitations than you could do.

It’s the same process for other platforms with different architectures?

If I understand, yes.

I will no longer need to install dotnet on Linux and run an executable with dotnet . meuExecutavel.dll? (Example)

No, this is already possible, you can have everything without installing anything, it takes work and often does not pay. Before I had to copy at least one file together, now in . NET Core 3 may be all in the same file and further simplifies.

Note that in your development machine you need other things, this is all true for the machine you will run.