[Configuration] appsettings.json in Shared project set to Content doesn't get loaded when UseConfiguration and ContentSource is used

[HakanL]

Current behavior

Following the new Uno templates I wanted to take advantage of the Uno Extensions Configuration service. The default is to use an embedded configuration file, which works fine, but for my purpose I want it to exist as a file in the deployment. I changed the build action on appsettings.json to Content. In the head I can confirm that it's stored in a subfolder called Shared (after the assembly where the json file resides). But the ContentSource doesn't find it. If I turn on logging then I can see it searches a couple of different folders, not where my app is. Either this is incorrect (bug), or there should be a way to specify the folder where ContentSource should expect the files (enhancement request).

Expected behavior

appsettings.json in Shared project set to Content should be loaded by UseConfiguration

How to reproduce it (as minimally and precisely as possible)

Change build action on appsettings.json to Content, change UseConfiguration to:

                    .UseConfiguration(configure: configBuilder =>
                        configBuilder
                            .ContentSource()
                            .Section<AppConfig>()
                    )

Environment

Nuget Package: Uno.Extensions.Configuration

Package Version(s): 2.3.11

Affected platform(s):

• iOS
• Android
• WebAssembly
• WebAssembly renders for Xamarin.Forms
• Windows
• Linux

Visual Studio:

• 2022

Anything else we need to know?

Tested and confirmed to not work in WinUI, Linux.Framebuffer and Windows.Gtk

[nickrandolph]

@HakanL thanks for posting this - I'll investigate but I'm going to assume that this issue is a result in the change to class library structure. The big caveat to using appsettings as content is that it isn't well supported on wasm - it does work but configuration is reloaded once the file system is available, so not available for reading appsettings during host builder. Since it look like you're not using wasm (from the checked platforms above), you should be good to use Content

[HakanL]

You're correct that I'm not using Wasm, I'm working on a solution that will only run on Linux Framebuffer (and WinUI/GTK for development on my PC). Reloading settings from appsettings would be a nice feature to have, but as I reported, because of the class library structure (which I love BTW, Visual Studio was always quite cranky with the shproj type) the appsettings file (set to content) gets put under a subfolder (named after the shared project name). Having a way to to add to the search paths in ContentSource would be one solution.

[tibitoth]

BTW for me ContentSource() is not working at all. I think hosting environment is null when load the config files

[nickrandolph]

My recommendation is not to use ContentSource. This is on the backlog to investigate but it's never going to be as reliable on all platforms as EmbeddedSource due to the asynchronous file access on some platforms.

[fehdem]

I ran into the same issue and spent quite a lot time on figuring out that the configuration mechanism is not working as the API suggested (to me at least). I'm porting a ASP.NET application to Uno.UI and I would like to stick to the existing options implementation. I'm targetting Linux and Windows only. I'm aware that there are restrictions on WASM, but still I would appreciate some more flexibility for none-WASM/Android/... applications.
Also, I don't see how embedding appsettings.json is usefull in the first place. May be I'm wrong, but I think embedding the configuration would require re-compiling and deploying the application with each change of the configuration.
But enabling configuring the application after deployment is the very purpose of a configuration file like appsettings.json, isn't it?

I digged deeper into the code to figure out how the path to appsettings.json is assembled.
The static method AddConfigurationFile of class ConfigurationBuilderExtensions gets the app data path from the environment of the hosting context. Of course, this is quite straight forward on one hand, but restricting a flexible use of Json files as configuration source on the other hand. It would be greate if I could just pass in the path of the file.

Again, may be I got something wrong and there is another way to accomplish this. Any suggestions are very welcome!

[fehdem]

I just found a solution (workaround?):

ConfigureAppConfiguration((context, builder) =>
{
  string enviroment = context.HostingEnvironment.EnvironmentName.ToLower();
  string filename = enviroment is {Length: > 0} ? $"appsettings.{enviroment}.json" : "appsettings.json";
  string basePath = RuntimeInformation.IsOSPlatform(OSPlatform.Linux) ? "/etc/amadea/desk-node/" : "c:\\test";
  string absolutePath = Path.Combine(basePath, filename);
  builder.AddJsonFile(absolutePath);
)

Maybe there are side effects that I don't see, yet. But it works at least in my use case.

[DevTKSS]

@kazo0 do we might have any chance in getting this fixed?
just looked up the definition available in our Hostbuilder for .ContentSource in the src searching for a way to load json data files like the Chefs app is doing, but with the ContentSource which I did see but is not documented:

uno.extensions/src/Uno.Extensions.Configuration/ConfigBuilderExtensions.cs

Lines 29 to 51 in ebed7b0

	public static IConfigBuilder ContentSource(this IConfigBuilder hostBuilder, string? config = null, bool includeEnvironmentSettings = true)
	{
	return hostBuilder
	.ConfigureAppConfiguration((ctx, b) =>
	{
	if (config is { Length: > 0 })
	{
	b.AddConfiguration(ctx, config);
	if (includeEnvironmentSettings)
	{
	b.AddEnvironmentConfiguration(ctx, config);
	}
	}
	else
	{
	b.AddAppConfiguration(ctx);
	if (includeEnvironmentSettings)
	{
	b.AddEnvironmentAppConfiguration(ctx);
	}
	}
	}).AsConfigBuilder();
	}

---

The detail that I think is maybe causing the problem, is that independant on which we call, its always adding the environment behind that:

uno.extensions/src/Uno.Extensions.Configuration/ConfigurationBuilderExtensions.cs

Line 44 in ebed7b0

var configSection = configurationName is { Length: > 0 } ? $"{configurationName}.{env.EnvironmentName}" : env.EnvironmentName;

which might not apply if we call "ContentSource" to load content data, like if you would provide AppData/Reciepes.json as in the Chefs App Docs done via Windows specific method, this would not get conisered. The xml docs of the ContentSource call is calling .AddConfiguration(... from here:

uno.extensions/src/Uno.Extensions.Configuration/ConfigurationBuilderExtensions.cs

Lines 20 to 31 in ebed7b0

	/// <summary>
	/// Adds a JSON configuration source by name to builder.
	/// </summary>
	/// <param name="configurationBuilder">The builder instance used to create an <see cref="IConfiguration"/> with keys and values from a set of sources</param>
	/// <param name="hostingContext">The <see cref="HostBuilderContext"/> which provides information specific to the hosting environment</param>
	/// <param name="configurationName">A name to identify the added configuration source. Optional</param>
	/// <returns>The <see cref="IConfigurationBuilder"/>.</returns>
	public static IConfigurationBuilder AddConfiguration(this IConfigurationBuilder configurationBuilder, HostBuilderContext hostingContext, string? configurationName = null)
	{
	var configSection = configurationName is { Length: > 0 } ? string.Format(AppConfiguration.FileNameTemplate, configurationName) : AppConfiguration.FileName;
	return configurationBuilder.AddConfigurationFile(hostingContext, configSection.ToLower());
	}

which is creating a string.Format with the const string TemplateFileName here:

uno.extensions/src/Uno.Extensions.Configuration/AppConfiguration.cs

Lines 3 to 8 in ebed7b0

	internal static class AppConfiguration
	{
	public const string Prefix = "appsettings";
	public const string FileName = $"{Prefix}.json";
	public const string FileNameTemplate = $"{Prefix}.{{0}}.json";
	}

so resulting from this, the e.g. AppData/Reciepes.json files would end up as appsettings.appdata/sampleData.json which you can see, would be invalid, and resulting in our urls used in app code while runtime, like this issue files for example.
then after AddConfiguration function did made our provided filename/path invalid, we will send it over to the private .AddConfigurationFile() here:

uno.extensions/src/Uno.Extensions.Configuration/ConfigurationBuilderExtensions.cs

Lines 6 to 18 in ebed7b0

	public static class ConfigurationBuilderExtensions
	{
	private static IConfigurationBuilder AddConfigurationFile(this IConfigurationBuilder configurationBuilder, HostBuilderContext hostingContext, string configurationFileName)
	{
	var relativePath = $"{ConfigBuilderExtensions.ConfigurationFolderName}/{configurationFileName}";
	var rootFolder = hostingContext.HostingEnvironment.GetAppDataPath();
	if (rootFolder is null)
	{
	return configurationBuilder;
	}
	var fullPath = Path.Combine(rootFolder, relativePath);
	return configurationBuilder.AddJsonFile(fullPath, optional: true, reloadOnChange: false);
	}

Remark to the ConfigBuilderExtensions.ConfigurationFoldeName, which uses this const string at the very top of it:

uno.extensions/src/Uno.Extensions.Configuration/ConfigBuilderExtensions.cs

Lines 7 to 12 in ebed7b0

	public static class ConfigBuilderExtensions
	{
	/// <summary>
	/// Defines a default name for the folder containing configuration files.
	/// </summary>
	public const string ConfigurationFolderName = "config";

so its requiring every file to be put into a folder named as "config" which nobody tells us users and no sample is doing so.

---

Maybe a way to solve this, would be to allow us to provide a bool to send the code to a different route and would not cause all of this issues? Or/and any more validation logic that would stop the AddConfiguration method called from .ContentSource(... making the filename invalid would be a good thing maybe😅

maybe the at least ContentSource Call could let us provide the really exact name we want to use like the uno.extensions/playground/ storage sampling code call did use with @"sampledata.json" 🤔 or not name it "ContentSource" since that is defintly implying that we can Source Content with using this, while its not doing this.
As for example the .UseStorage() is already called in the HostBuilder by default as I did remark in

• docs(Storage): Improve Getting Started and Overview #2824, it would make in my opinion more logical sense, if this could be used to source Content Files through this extension and make it available like Options 🤔