Setting Application name using WebApplicationOptions causes FileNotFoundException

[Toudahl]

Is there an existing issue for this?

• [x] I have searched the existing issues

Describe the bug

When using CreateBuilder overload that takes a WebApplicaitonOptions, and setting the ApplicationName property a FileNotFoundException occurs in the GenericWebHostBuilder on this line

The value set on the ApplicationName makes it way to the output of the GetFinalHostingStartupAssemblies method called above the Assembly.Load

Expected Behavior

No exception is thrown, and the custom application name becomes available through the IWebHostEnvironment interface/implementation.

Steps To Reproduce

https://github.com/Toudahl/didactic-doodle/blob/main/WebApplication2/Program.cs

Exceptions (if any)

System.InvalidOperationException: Startup assembly MyApplication failed to execute. See the inner exception for more details.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'MyApplication, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

File name: 'MyApplication, Culture=neutral, PublicKeyToken=null'
   at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext, RuntimeAssembly requestingAssembly, Boolean throwOnFileNotFound)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.ExecuteHostingStartups()
   --- End of inner exception stack trace ---

.NET Version

8.0.101

Anything else?

The issue occurs both using dotnet run and rider.

.NET SDK:
 Version:           8.0.101
 Commit:            6eceda187b
 Workload version:  8.0.100-manifests.69afb982

Runtime Environment:
 OS Name:     pop
 OS Version:  22.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/8.0.101/

.NET workloads installed:
 Workload version: 8.0.100-manifests.69afb982
There are no installed workloads to display.

Host:
  Version:      8.0.1
  Architecture: x64
  Commit:       bf5e279d92

.NET SDKs installed:
  8.0.101 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/share/dotnet/]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[gfoidl]

That's the same underlying issue as https://github.com/dotnet/aspnetcore/issues/52152 (and unfortunately I didn't have enough time to create a proposal for an API in dotnet/runtime)

[Toudahl]

Ah, you are quite right. Looks like I should have searched harder before creating my issue.

[Toudahl]

@captainsafia i am not sure I agree this is a duplicate.

These are two different problems. This is about an exception one place that occurs because application name is used as assembly name.

The other issue is about secrets not working because application name is used as assembly name, at an other location.

Fixing one will not fix the other.

[jvmlet]

@captainsafia , @gfoidl , please have a closer look at the problem @Toudahl is complaining.

Here is the problematic part in Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions

The fact that the value is set by default to the entry-point assembly name, doesn't allow to treat the ApplicationName as assembly name and try loading it !!!

This is breaking change that is not even documented.

Also, even though the manager instance could be provided via DI, the PopulateDefaultParts method is internal !!! and not marked as override - I hardly understand the reason behind letting user to injects their own implementation if he can't provide his own implementation of PopulateDefaultParts method.

Please reopen and provide estimations for the fix. Thanks