The value of HostingEnvironment.ApplicationName is incorrect during EF migrations

[crozone]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using the newer .NET 6+ minimal startup code:

WebApplicationBuilder builder = WebApplication.CreateBuilder(args)

The value of builder.Environment.ApplicationName is usually set to the equivalent of Assembly.GetEntryAssembly().GetName().Name.

For example, "MyApplication.Web". This is expected.

However, during design time (when using tools like dotnet ef), the value of builder.Environment.ApplicationName instead becomes the full Assembly.GetEntryAssembly().GetName().ToString().

For example: "MyApplication.Web, Version=2.5.4.0, Culture=neutral, PublicKeyToken=null"

Which is unexpected and causes issues in startup code that expects the application name to be consistent regardless of context.

Expected Behavior

The value of WebApplicationBuilder.Environment.ApplicationName should be consistent regardless of whether the application is run normally, or during design time via dotnet ef tooling.

The expected value is the equivalent of Assembly.GetEntryAssembly().GetName().Name.

Steps To Reproduce

Create a standard ASP.NET Core Web app project, with the .NET 7.0 Framework, named "AspNetCoreTemplateTest".

Replace the startup code with the following Main() method:

public static void Main(string[] args)
{
    var builder = WebApplication.CreateBuilder(args);
    Console.WriteLine(builder.Environment.ApplicationName);
}

Run the application normally. Observe that "AspNetCoreTemplateTest" is printed as the builder.Environment.ApplicationName.

Run dotnet ef migrations list. Observe that "AspNetCoreTemplateTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" is printed as the builder.Environment.ApplicationName.

Exceptions (if any)

We configure a UserAgent as part of our ElasticSearch Serlilog configuration during startup. Part of this requires passing hostingContext.HostingEnvironment.ApplicationName into a ProductInfoHeaderValue:

new ProductInfoHeaderValue($"{hostingContext.HostingEnvironment.ApplicationName}-{hostingContext.HostingEnvironment.EnvironmentName}", Assembly.GetEntryAssembly()?.GetName().Version?.ToString()).ToString());

This fails when the ApplicationName contains characters that are invalid for a HTTP header.

.NET Version

7.0.307

Anything else?

• Microsoft.AspNetCore.App version 7.0.10
• dotnet-ef 7.0.10
• Visual Studio 2022 64-bit Version 17.6.2

[halter73]

The entry assembly is changing when you call dotnet ef. It's another dotnet app that is loading your assembly. You can work around this by setting ApplicationName manually by passing in options to WebApplication.CreateBuilder(options), or via one of the default host configuration sources.

I'm going to transfer this to the ef repo, because if there's anything to be done, it would be to set DOTNET_APPLICATIONNAME to _startupAssembly.GetName().Name to keep the ApplicationName the same as it would be if you launched the app normally. This is similar to how we already set DOTNET_ENVIRONMENT before invoking the service provider factory from HostFactoryResolver.ResolveServiceProviderFactory(_startupAssembly).

[ajcvickers]

/cc @bricelam

[daveidmx]

I'm running into this problem too. We're binding an Options class in a common library used by our dozens of services using something like this:

services.AddOptions<MyOptions>()
    .BindConfiguration(hostEnvironment.ApplicationName.Replace('.', ':'));

As a result, ef tools commands requiring a connection fail because ApplicationName is wrong.

I've filed dotnet/runtime #96596, which I believe is the cause of the issue.

[daveidmx]

@crozone here is my workaround.

Each app:

Runtime96596.FixUpArgs(args);
var builder = WebApplication.CreateBuilder(args);

Common library:

/// <summary>
/// Workaround for <see href="https://github.com/dotnet/runtime/issues/96596"/>
/// and <see href="https://github.com/dotnet/efcore/issues/32202"/>
/// </summary>
public static class Runtime96596
{
    /// <summary>
    /// Call this against the program arguments array
    /// before passing them to the application builder.
    /// </summary>
    public static void FixUpArgs(string[] args)
    {
        for (int i = 0; i < args.Length - 1; i++)
        {
            if (IsApplicationNameArg(args[i]))
            {
                var value = args[i + 1];
                var indexOfComma = value.IndexOf(',');
                if (indexOfComma >= 0)
                    args[i + 1] = value[..indexOfComma];

                return;
            }
        }

        static bool IsApplicationNameArg(string arg)
            => arg.Equals("--applicationName", StringComparison.OrdinalIgnoreCase)
            || arg.Equals("/applicationName", StringComparison.OrdinalIgnoreCase);
    }
}

[crozone]

I'm running into this problem too. We're binding an Options class in a common library used by our dozens of services using something like this:

services.AddOptions<MyOptions>()
    .BindConfiguration(hostEnvironment.ApplicationName.Replace('.', ':'));

As a result, ef tools commands requiring a connection fail because ApplicationName is wrong.

I've filed dotnet/runtime #96596, which I believe is the cause of the issue.

Great job tracking down that rogue assembly.FullName. I knew it had to be somewhere, but didn't realise it was passed via --applicationName. Looks like a single line fix.

I'll implement your workaround for now. Very nice, thanks.