Why does System.Reflection.Assembly.GetEntryAssembly().Location returns .dll instead of .exe?

[tommyvct]

Why does it behave like that?

Why Process.GetCurrentProcess().MainModule.FileName and Environment.ProcessPath returns the thing I want?

It seems that no matter how simple the program is, the compiler always generate a dummy .exe and a .dll which does the actual work. Why is it like that, can I have a single .exe?

[danmoseley]

@vitek-karas

[vitek-karas]

The .dll is a managed assembly (same format as with .NET Framework), it's an intermediate language code, not directly executable by the OS. The .exe is a small shim, which knows how to find the .NET runtime, loads it, and tells it to run the code in the .dll. The .exe is a directly executable code.

.NET Framework's .exe was also a managed assembly with no directly executable code, but since .NET Framework is part of the OS, the OS knows that these are "managed executables" and handles the "shim" part in the OS loader directly (find the runtime, load it, ask it to execute the managed code). Starting with .NET Core (and later on with .NET) this approach was abandoned, as it can really only work on Windows and not cross-platform. So .NET Core/.NET always has to create a native shim executable which starts the runtime and run the managed code.

You can publish your application as a so called "single-file", which will produce a single executable (in .NET 6 it is truly a single file): https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file

As for the APIs - GetEntryAssembly must return an "assembly, so managed code - and thus it returns the managed .dll. Process and ProcessPath both return the native executable, the shim .exe.

Please note that with "single-file" publish the managed assembly is just a piece of data embedded in the .exe and so it has no file system location. So the call to GetEntryAssembly will return a valid assembly, but calling .Location on it will return null as it's not a file on disk. Process and ProcessPath still work.

If you're just looking for the directory in which the app is, the recommended API for that is AppContext.BaseDirectory.

[tommyvct]

Thanks for your great explanation! I wanted to register the app using registry, so I need the absolute path to the exe, not the directory.