Use assembly name of global.asax type as default IHostEnvironment.ApplicationName

[twsouthwick]

There are a lot of assumptions that the ApplicationName is actually the assembly name and cause some things (like user secrets) to break if it is not.

Since there's no direct way to get the main assembly directly, this sets it by searching the current HttpApplication as a best effort for this.

[Copilot]

Pull request overview

Updates the default IHostEnvironment.ApplicationName fallback logic for SystemWebAdapter hosts to better align with ASP.NET Core expectations (notably to keep features like User Secrets working when ApplicationName isn’t the assembly name).

Changes:

• Replaces the HostDefaults.ApplicationKey fallback value from HostingEnvironment.SiteName to a derived assembly name.
• Adds a best-effort method to infer the “launched” application assembly name via the current HttpApplication type.

Show a summary per file

File	Description
src/Microsoft.AspNetCore.SystemWebAdapters.FrameworkServices/Hosting/ConfigurationManagerConfigExtensions.cs	Changes application name fallback behavior and introduces reflection-based Global.asax assembly inference.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (2)

src/Microsoft.AspNetCore.SystemWebAdapters.FrameworkServices/Hosting/ConfigurationManagerConfigExtensions.cs:100

• The loop condition is incorrect: type.BaseType.GetType() != typeof(HttpApplication) compares System.Type’s runtime type, so it will never equal typeof(HttpApplication). In cases where ApplicationInstance is a generated type whose direct base type is HttpApplication, this will walk up to HttpApplication and return the System.Web assembly name, which defeats the goal of using the app’s assembly name. Compare type.BaseType directly (and guard for null) instead.

        // The ApplicationInstance may be a custom one generated by ASP.NET, so we need to walk up until we find the real one.
        // The generated ones are marked with the GeneratedCodeAttribute, so we can check for that.
        while (type.Assembly.GetCustomAttribute<GeneratedCodeAttribute>() is { } && type.BaseType.GetType() != typeof(HttpApplication))
        {
            type = type.BaseType;
        }

src/Microsoft.AspNetCore.SystemWebAdapters.FrameworkServices/Hosting/ConfigurationManagerConfigExtensions.cs:99

• The generated-type detection appears to be checking the assembly for GeneratedCodeAttribute, but the comment indicates the generated types are marked. If the attribute is applied to the type (common), this condition will be false and the method will return the ASP.NET generated assembly name (e.g., App_Web_*) rather than the user Global.asax assembly. Consider checking GeneratedCodeAttribute on type (not type.Assembly) and only walking base types while the current type is generated.

        // The ApplicationInstance may be a custom one generated by ASP.NET, so we need to walk up until we find the real one.
        // The generated ones are marked with the GeneratedCodeAttribute, so we can check for that.
        while (type.Assembly.GetCustomAttribute<GeneratedCodeAttribute>() is { } && type.BaseType.GetType() != typeof(HttpApplication))
        {
            type = type.BaseType;

• Files reviewed: 1/1 changed files
• Comments generated: 4

[EmperorArthur]

I see what you're doing, but am not sure it's the best approach. Especially since it's still relying on other assumptions. Ones which I know would fail for my company's sites.

Alternatives

There are several options to work around the problem that I believe are better alternatives.

1. When the next version is released, a user can set "applicationName" in GlobalConfiguration.Configure to whatever it should be. (This ability was added in PR Support HostApplicationBuildersSettings for framework application (#665) #667)
2. Make HttpApplicationHostBuilder.BuildAndRunInBackground and HttpApplicationHost.CreateBuilder(HostApplicationBuilderSettings settings) public
3. Add a 2nd argument/version of HttpApplicationHost.RegisterHost that accepts an "HostApplicationBuilderSettings".

As I noted, this is an issue which I have had to deal with, and the 2nd option was probably on my mind when I worked on PR #667.

Other Info

• The .NET Core extensions use the assembly name of whatever is configuring the builder. Which is different from both the current and new approach.
• Some of the weird formatting I see cleaned up is because that snippet is based on. HostApplicationBuilder.Initialize.

###Edit
Want to emphasize that I don't have a problem with the code or even merging the PR. Especially since, as of the next release, it will just be a fallback value.

Reduced section header size.

[twsouthwick]

I see what you're doing, but am not sure it's the best approach. Especially since it's still relying on other assumptions. Ones which I know would fail for my company's sites.

Which assumptions would fail for your sites?

[EmperorArthur]

Re-looking at this. I believe I was a bit too hasty, and the code looks good to me. While I it would not meet my needs, replicating aspnetcore behavior is the right call.

Which assumptions would fail for your sites?

My case is a bit unique in I need two different projects in the same solution to have the same AppName. or at least override it for a DataProtectionProvider. See #682.