Using a custom "ApplicationName" and UseStartup<Startup>() doesn't work

[cwe1ss]

I was trying to set my own IHostingEnvironment.ApplicationName on my WebHostBuilder. However, if I set it before I use UseStartup, it will be overwritten and the output is Hello from 'AppName'!:

namespace AppName
{
    public class Program
    {
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            app.Run(async (context) =>
            {
                await context.Response.WriteAsync($"Hello from '{env.ApplicationName}'!");
            });
        }

        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseSetting(WebHostDefaults.ApplicationKey, "MyCustomAppName")
                .UseStartup<Program>()
                .Build();
    }
}

So I thought I'm smart and just call UseSetting after UseStartup but this results in the following exception:

Hosting startup assembly exception
System.InvalidOperationException: Startup assembly MyCustomAppName failed to execute. See the inner exception for more details. ---> System.IO.FileNotFoundException: Could not load file or assembly 'MyCustomAppName, Culture=neutral, PublicKeyToken=null'. Das System kann die angegebene Datei nicht finden.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks, IntPtr ptrLoadContextBinder)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, IntPtr ptrLoadContextBinder)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)

Is this a feature (meaning, custom application names can not be used with Startup-types) or a bug?

[cwe1ss]

PS: If it's a bug and it will be resolved, it would be great if I could still set the application name BEFORE the call to UseStartup.
My scenario: I'm using my own version of "WebHost.CreateDefaultBuilder" as a baseline for all our microservices. I want to set my application name there and people should still be able to set their own Startup-type.

[khellang]

This must indeed be a bug, unless ApplicationName is always meant to be an assembly name.

Since ApplicationName is always part of HostingStartupAssemblies, this code will throw if it doesn't match an assembly name 🤔

[cwe1ss]

Having an application name that is not an assembly name would definitely be nice. E.g. our assemblies have a naming convention of <CompanyName>.<Context>.Hosts.<App> and I want to set the application name to <Context>.<App>. (I'm sending this name to Application Insights so I want a short one.)

But of course, I can easily work around this by not using IHostingEnvironment.ApplicationName and getting this information from somewhere else.

[davidfowl]

This is by design. The application name was an unfortunate choice as a property name (in hindsight) but it's too late to change that now.

[cwe1ss]

OK, thanks David!

[khellang]

You could solve it by doing something like this; dev...khellang:fix-application-name

[khellang]

Would you take a PR for that, @davidfowl?

[khellang]

Basically, instead of checking if StartupAssembly is set before scanning for a Startup type, I introduced a new FindStartupType option to check instead. Then, I always set StartupAssembly and use that as a fallback if ApplicationName has been overridden.

This means that ApplicationName is totally decoupled from anything assembly related. It's just a name that happens to fall back to the assembly name if it hasn't been overridden.

In combination with #1178, I think this would be really nice.

[davidfowl]

Seems like a lot of work for extremely little value. It also doesn't fix the fact that MVC uses it as the still uses it as the entry point. The fact is IHostingEnvironment.ApplicationName is treated like an assembly name by other components.

[khellang]

Seems like a lot of work for extremely little value.

Work? As in runtime work? Or just coding-wise?

At runtime, it's pretty much no work at all, and the coding is already done 😉

[cwe1ss]

If this won't be changed, maybe the docs should be fixed here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/hosting?tabs=aspnetcore2x#host-configuration-values

It doesn't really say that you shouldn't touch this property.

[davidfowl]

Related aspnet/Mvc#6685.

[khellang]

If this was merged, MVC could use StartupAssembly instead of ApplicationName 😄

EDIT: That would have to be exposed through IHostingEnvironment though...