Runtime: Single EXE with an external appsettings.json

Created on 17 May 2019  路  6Comments  路  Source: dotnet/runtime

Hello,

I was just wondering if there is a way or a plan to allow single .EXE deployment of my .NET Core apps, while still allowing for an external config file, i.e. appsettings.json.

I didn't see any options that get me to where I want to be: https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#user-experience

area-Single-File untriaged

Most helpful comment

Having the same issue, except with app.config file. If I exclude them from the single file build, then I crash on startup, saying file not found. What we really need is a single file executable that does not extract itself to a temp/cache folder but instead runs right where it is, reading any config file in the same folder, whether it be app.exe.config or appsettings.json, etc. If the config file is not found as a file in the folder, then it could check inside the .exe as a fallback. I really want my users to be able to edit these config files, embedding them in the .exe is a no-go.

All 6 comments

Having the same issue, except with app.config file. If I exclude them from the single file build, then I crash on startup, saying file not found. What we really need is a single file executable that does not extract itself to a temp/cache folder but instead runs right where it is, reading any config file in the same folder, whether it be app.exe.config or appsettings.json, etc. If the config file is not found as a file in the folder, then it could check inside the .exe as a fallback. I really want my users to be able to edit these config files, embedding them in the .exe is a no-go.

I've the same issue but only if i run the single EXE in windows service context.
This is an issue and i ask me why my thread has been deleted where I explained perfectly how to reproduce the problem

Yes, I was having the same problem in a .NET Core 3.1 project with Microsoft.Extensions.Configuration with single file executables. The solution might be to manually load the application configuration file with a ConfigurationBuilder and at the step where you tell it about the configuration file to load, specify the full path.

Now, the next question is "what if the full path is the temporary extraction directory?"

My tests has shown that System.IO.Directory.GetCurrentDirectory() reports the "expected" path for your config file reads -- as in the path where your executable is on the disk pre-extraction. While a call like System.Reflection.Assembly.GetEntryAssembly().Location reports the path to the temporary extraction folder for these single file exe's.

Tagging subscribers to this area: @agocke, @vitek-karas
See info in area-owners.md if you want to be subscribed.

Seems to be a lot better in .NET 5 rc 2, just mark the appsettings.json or app.config as content and copy if newer and the publish does the right thing.

.NET 5 changed the default behavior and it will only bundle managed assemblies into the single executable. Any other file type will be left next to the single executable. This includes any "data" files (non-code), like configuration files and so on.

(It will bundle .deps.json and .runtimeconfig.json which are technically also configuration files)

In .NET Core 3.1 this can be achieved by adding ExcludeFromSingleFile=true metadata to the file item in the project - see the detailed doc here: https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design_3_0.md#build-system-interface

Was this page helpful?
0 / 5 - 0 ratings