Setting ApplicationKey (name) causes a different assembly to be loaded.

[rcollette]

When setting the application key name:

    private static IWebHost BuildWebHost(string[] args)
    {
        var config = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("hosting.json", true)
            .AddEnvironmentVariables("ASPNETCORE_")
            .AddCommandLine(args)
            .Build();

        return WebHost.CreateDefaultBuilder(args)
            .ConfigureLogging((context, builder) => { builder.ClearProviders(); })
            .UseConfiguration(config)
            .PreferHostingUrls(true)
            .UseStartup<Startup>()
            .UseSetting(WebHostDefaults.ApplicationKey, "CustomApplicationName")
            .Build();
    }

Nothing in the documentation seems to indicate that setting the application key name has an affect on what assembly is loaded. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/web-host?view=aspnetcore-2.1#application-key-name

Tangentially, I think the documentation about the ASPNETCORE_APPLICATIONKEY environment variable is incorrect, as noted in the documentation author's pull request https://github.com/aspnet/Docs/pull/7493

I was able to debug my application locally in Rider with no issues. But when I deployed to a Docker container using the microsoft/dotnet:2.1.2-aspnetcore-runtime base image, I am seeing that it is trying load a different assembly when starting up the application.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly "CustomApplicationName, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

This is either a documentation issue, but perhaps a code issue because I am seeing a different behavior between running in my IDE and when running in a container.

[Tratcher]

Yeah, that should be ASPNETCORE_APPLICATIONNAME.

[Tratcher]

@pranavkm doesn't MVC use the name for controller discovery?

[rcollette]

I tried ASPNETCORE_APPLICATIONNAME but it still doesn't seem to get picked up either with or without .UseSetting(WebHostDefaults.ApplicationKey, "CustomApplicationName") being in place.

[rcollette]

Actually, I have to apologize. This is not unique to Docker. It was just that I was breakpointing in Startup.cs and wasn't going far enough to get to the file load exception. So I guess this is a documentation issue?

[Tratcher]

UseStartup is overwriting ApplicationKey.

[pranavkm]

@pranavkm doesn't MVC use the name for controller discovery

Yes

[rcollette]

Just to add a use case for this. I was trying to set the application name to be picked up by Dynatrace application monitoring. The other micro-services related to this product, which set their Java/Spring application name via the spring.application.name application property, are named like "MyProduct-TheService" but without setting the application name, the dot net service shows up as "Org.MyProduct.TheService.dll".

It makes grouping services by application incorrect at the moment.

[pranavkm]

@rcollette like @Tratcher said MVC uses the application name for controller discovery - the application name is assumed to be the entry point and used to discover ApplicationPart instances. You could skip the auto-discovery and register parts manually, that way you could keep the custom name. If you know exactly the list of assemblies with controllers in it, just add them as AssemblyPart instances and you should be good.

[khellang]

I once tried to fix this; https://github.com/aspnet/Hosting/pull/1180, but @davidfowl convinced me to wait for v3. Maybe it's time to revisit? 😇 The PR links to a web of other duplicate issues as well.

[rcollette]

The documentation appears to have been corrected to include the correct environment variable name and now clearly mentions that the property contains an assembly name.

I'm going to close this and open a separate issue for the FriendlyName property since there is nothing open currently to track it.