Why is IL code packed into an exe in a C# application?

Question

I was trying to regenerate an exe by doing a round trip of ILDASM and then ILASM on a C# executable file. As I understand, the .il file generated by ILDASM is sufficient to generate .exe back.

I am curious that why .NET framework is designed to use an exe file for deployment instead of deploying a .il file to the users. Could not c# compiler generate .il file and the JIT compiler use the .il file directly as an input? Is it simply because operating system needs .exe extension to invoke the loader, or is it because of file size or performance considerations?

PS: The question is not of practical significance. I am asking this question to make my concepts more clear, as I am sure I am lacking a lot.

Answer 1

It wouldn't make any sense to add another type of extension just to cater for .NET.

.NET executables are PE files and they provide a minimal amount of native code to bootstrap the correct version of the CLR and pull the IL into memory and hand off to the CLR.

Windows natively knows what to do with PE files and with the indirection mechanism built into the EXE Windows also doesn't need to know about .NET.

With a .il file you'd need to register the extension with Windows then make sure that the correct version of the CLR is loaded - as far as I know you can only associate an extension with one executable.

To support multiple versions of the CLR you'd need some kind of intermediary that then inspects your .il file to determine which CLR to load....and things just get convoluted and fragile after that.

Packaging all this in a PE solves these problems neatly and elegantly.

Although this is an older article, the principles remains the same in current .NET Frameworks:

An In-Depth Look into the Win32 Portable Executable File Format, Part 2

The key section "The .NET Header" explains how this works:

Executables produced for the Microsoft .NET environment are first and foremost PE files. However, in most cases normal code and data in a .NET file are minimal. The primary purpose of a .NET executable is to get the .NET-specific information such as metadata and intermediate language (IL) into memory. In addition, a .NET executable links against MSCOREE.DLL. This DLL is the starting point for a .NET process. When a .NET executable loads, its entry point is usually a tiny stub of code. That stub just jumps to an exported function in MSCOREE.DLL (_CorExeMain or _CorDllMain). From there, MSCOREE takes charge, and starts using the metadata and IL from the executable file. This setup is similar to the way apps in Visual Basic (prior to .NET) used MSVBVM60.DLL. The starting point for .NET information is the IMAGE_COR20_HEADER structure, currently defined in CorHDR.H from the .NET Framework SDK and more recent versions of WINNT.H. The IMAGE_COR20_HEADER is pointed to by the IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR entry in the DataDirectory. Figure 10 shows the fields of an IMAGE_COR20_HEADER. The format of the metadata, method IL, and other things pointed to by the IMAGE_COR20_HEADER will be described in a subsequent article.

Answer 2

.exe files are smaller.
They also follow the existing standard PE format, making Windows integration simpler.

Java needs to register the .jar extension and associate it with java.exe in the path of a single JRE.

By contrast, since .Net assemblies are also normal Windows executables, .Net doesn't need to register any file associations. Instead, a .Net EXE contains code that locates the correct version of the runtime and invokes it to execute the EXE.
This allows multiple versions of the runtime to coexist on the same machine, without requiring a separate loader that would open a .il file, figure out what version it is, then run it with the correct version.

Also, parsing is slow; .il files would execute more slowly because the runtime would need to parse the IL.