According to this answer:
At the moment, there are no fail-safe methods to create a single executable file. Since there are a lot of type-forwarding dll files involved, even ILMerge and similar tools might not produce correct results (though this might improve, the problem is that those scenarios haven't undergone extensive testing, esp. in production applications)
There are currently two ways to deploy a .NET Core application:
- As a "portable application" / "framework-dependent application", requiring a
dotnet executable and installed framework on the target machine. Here, the XYZ.runtimeconfig.json is used to determine the framework version to use and also specifies runtime parameters. This deployment model allows running the same code on various platforms (windows, linux, mac)
- As a "self-contained application": Here the entire runtime is included in the published output and an executable is generated (e.g.
yourapp.exe). This output is specific to a platform (set via a runtime identifier) and can only be run on the targeted operating system. However, the produced executable is only a small shim that boots the runtime and loads the app's main dll file. This also allows an XYZ.runtimeconfig.json to set additional runtime properties like garbage collection settings.(think of it as a "new" app.config file)
In the future, the CoreRT runtime – which is still under development at the time of writing – aims to allow creating a single pre-compiled native executable that is specific to a runtime and does not require any other files.
Although that question was asked (by yours truly) more than 6 months ago, it looks like CoreRT is still a work in progress.
Pros and Cons of a Self-Contained Deployment
Deploying a Self-contained deployment has two major advantages:
You have sole control of the version of .NET Core that is deployed with your app. .NET Core can be serviced only by you.
You can be assured that the target system can run your .NET Core app, since you're providing the version of .NET Core that it will run on.
It also has a number of disadvantages:
Because .NET Core is included in your deployment package, you must select the target platforms for which you build deployment packages in advance.
The size of your deployment package is relatively large, since you have to include .NET Core as well as your app and its third-party dependencies.
Deploying numerous self-contained .NET Core apps to a system can consume significant amounts of disk space, since each app duplicates .NET Core files.
I realize you already found that Microsoft deployment document, but if you go through the walkthroughs for command line and for Visual Studio deployments, you will note they are telling you to use dotnet publish in the procedure. This is exactly the same as with ASP.NET Core applications because they can be deployed as console applications.
In short, it is possible to make a self-contained deployment package with a .exe file, but it is NOT (yet) possible to make a self-contained EXE on .NET Core.
