WebApplication.CreateBuilder with non-default ApplicationName doesn't load user secrets

[gfoidl]

Repro:

WebApplicationBuilder builder = WebApplication.CreateBuilder(new WebApplicationOptions
{
    Args            = args,
    ApplicationName = "MySuperApp has a name that doesn't match the name of the entry assembly"
});

Now if you use any config value that should be set / overwritten by user secrets won't have these used.

This stems from

aspnetcore/src/DefaultBuilder/src/WebApplicationBuilder.cs

Lines 280 to 281 in 4a156ba

	var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
	configuration.AddUserSecrets(appAssembly, optional: true, reloadOnChange: reloadOnChange);

where the assembly is loaded via the env.ApplicationName which in turn is set by

aspnetcore/src/Hosting/Hosting/src/Internal/WebHostOptions.cs

Line 20 in 4a156ba

ApplicationName = environment?.ApplicationName ?? GetConfig(WebHostDefaults.ApplicationKey) ?? Assembly.GetEntryAssembly()?.GetName().Name ?? string.Empty;

In order to work for every ApplicationName should the WebApplicationBuilder be changed to

-var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
+var appAssembly = Assembly.GetEntryAssembly();
configuration.AddUserSecrets(appAssembly, optional: true, reloadOnChange: reloadOnChange);

?

Workaround: just add the user secrets manually by

    if (builder.Environment.IsDevelopment())
    {
        builder.Configuration.AddUserSecrets<Program>(optional: true, reloadOnChange: true);
    }

But it feels strange if one can set the ApplicationName, and then some things won't work as expected.
Alternatively the docs should reflect this. I prefer changing the code though.

---

Edit: startup fails also due to

aspnetcore/src/Hosting/Hosting/src/Internal/WebHostOptions.cs

Line 33 in 4a156ba

HostingStartupAssemblies = Split(ApplicationName, GetConfig(WebHostDefaults.HostingStartupAssembliesKey));

That should be updated too.

[martincostello]

I think another workaround might be to set the ID in the project file:

<PropertyGroup>
  <UserSecretsId>BlahBlah</UserSecretsId>
</PropertyGroup>

[gfoidl]

Unfortunately not, as in https://github.com/dotnet/runtime/blob/33d7f9815a4cf0ceb19f7014f978137218855a32/src/libraries/Microsoft.Extensions.Configuration.UserSecrets/src/UserSecretsConfigurationExtensions.cs#L124 the assembly must already be known from which the UserSecretsIdAttribute is read.

[captainsafia]

Thanks for reporting this issue! We're lacking on coverage for overriding the application name in our WebApplicationBuilder functional tests. Adding some more scenarios here will help guard against these issues.

In order to work for every ApplicationName should the WebApplicationBuilder be changed to

This seems like a sensible solution. Interested in submitting a PR?

[gfoidl]

I'll send a PR in the next days.