Application name defaults to "Saturn" majorly breaking framework expectations on this

[NinoFloris]

Things like IHostingStartup auto discovery and IStartup discovery fail, also distributed cache and quite a few other things expect this to be unique/equal to your startup assembly name. This stuff is for instance used by ApplicationInsights auto wireup.

The ApplicationName comes from the assembly that hosts the Configure delegate passed into builder.Configure as can be seen here https://github.com/aspnet/Hosting/blob/ae9da9290eb825f4145aaaa23603186d51211e53/src/Microsoft.AspNetCore.Hosting/WebHostBuilderExtensions.cs#L30

Temp fixes are:

• Change name inside HostingEnvironment
• Change it with UseSetting(WebHostDefaults.ApplicationKey, "NewName") before running build

PR fix would be to use the same reflection strategy WebHostBuilderExtensions uses on the router and override the setting before returning the builder.

[NinoFloris]

Grrr this won't work as it'll be compiled to a standard optimized closure, aka AssemblyName = FSharp.Core.

    router (scope {
        forward "/api" apiScope
    })

Only like this will an actual type be generated inside your own app to get a good read of.

    router (fun next -> (next |> scope {
        forward "/api" apiScope
    }))

Any clever ideas? @Krzysztof-Cieslak

[baronfel]

A possible workaround here would be for Saturn to add a app_name CE member to the application CE and set the backing setting explicitly, and if the user doesn't provide an app name then set it by default from the current executing assembly?

The actual configuration change would be

.UseSetting(WebHostDefaults.ApplicationKey, "CustomApplicationName")

[NinoFloris]

Relevant, it may get more clear in 3.0 dotnet/aspnetcore#7315

[davidalpert]

I'm confused why dotnet/aspnetcore#14183 was closed as "no work to do" - can anyone shed light on that decision? This is the closest issue I can find.

I spent some time digging through the code in this repo trying to figure out why my ASPNETCORE 3.x app was not respecting the APPLICATION_NAME set up in my app configuration and learned that using the DefaultWebHostBuilder and configuring a Startup class injects an additional configuration provider (last so that it overrides my app configuration) and forces the app name to the AssemblyName of the DLL containing the Startup class.

I'm curious why it does not simply respect the APPLICATION_NAME as configured by IConfigurationBuilder instance returned from the ConfigureAppConfiguration method?

I'm using a Generic Host and then calling ConfigureWebHostDefaults, so maybe this is a holdover behavior in the Web Host from before the Generic Host was created?

It appears to place the Generic Host guidance for setting ApplicationName in conflict with the Web Host guidance for setting ApplicationName

Eventually I'm hoping that the responsibility of overriding the ApplicationName config setting can be removed from the web host responsibility and handled in a consistent way by the Generic Host

[davidalpert]

Apologies, I didn't even realize which repo this issue is in, after clicking through so many issues I think I got lost. ;-) will ask in the aspnet repos.

[Krzysztof-Cieslak]

I'm not even sure if the bug is still there, but anyway, we can't do anything about it here - it's underlying ASP problem. So I'm closing this issue.