Bad error when booting webhost without calling UseStartup or Configure

[davidfowl]

Unhandled Exception: System.ArgumentException: A valid non-empty application name must be provided.
Parameter name: applicationName
   at Microsoft.AspNetCore.Hosting.Internal.HostingEnvironmentExtensions.Initialize(IHostingEnvironment hostingEnvironment, String applicationName, String contentRootPath, WebHostOptions options)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at ConsoleApp11.Program.Main(String[] args) in C:\Users\dfowler\documents\visual studio 2017\Projects\ConsoleApp11\ConsoleApp11\Program.cs:line 11

[moozzyk]

Just hit this in testing. The error message is really misleading.

[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8776789]       System.AggregateException : One or more errors occurred. (A valid non-empty application name must be provided.
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8778140]       Parameter name: applicationName) (The following constructor parameters did not have matching fixture data: ServerFixture serverFixture)
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8779372]       ---- System.ArgumentException : A valid non-empty application name must be provided.
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8780382]       Parameter name: applicationName
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8781072]       ---- The following constructor parameters did not have matching fixture data: ServerFixture serverFixture
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8799203]       Stack Trace:
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8824001]         
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8826139]         ----- Inner Stack Trace #1 (System.ArgumentException) -----
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8828104]            at Microsoft.AspNetCore.Hosting.Internal.HostingEnvironmentExtensions.Initialize(IHostingEnvironment hostingEnvironment, String applicationName, String contentRootPath, WebHostOptions options)
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8829407]            at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8830773]            at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8831554]            at Microsoft.AspNetCore.SignalR.Tests.Common.ServerFixture.StartServer()
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8832500]            at Microsoft.AspNetCore.SignalR.Tests.Common.ServerFixture..ctor()
[7/11/2017 9:31:34 AM Informational] [xUnit.net 00:00:00.8833458]         ----- Inner Stack Trace #2 (Xunit.Sdk.TestClassException) -----

[moozzyk]

You will also get this exception when UseStartup is called from a HostingStartup assembly: https://github.com/aspnet/Hosting/issues/1140

[CheloXL]

I just upgraded my application to netcore2/mvc core2 and can't run it anymore. I'm injecting the IStartup using ConfigureServices in WebHostBuilder and I'm getting the above error.

Is there any ETA on this? Or there is another way to bypass this error?

[davidfowl]

@CheloXL can you provide repro steps on a new project that show the behavior you're seeing? The issue above is solely about the error message, it has nothing to do with functionality. The behavior should be the same as 1.1.x with respect to adding an IStartup manually.

[CheloXL]

@davidfowl I will try to create one based on the project that I just upgrade. If I'm able to reproduce in a minimal test case, how do you want me to send the files?

[JunTaoLuo]

Would you be able to share it as a git repo?

[davidfowl]

@CheloXL the issue you're likely hitting is the fact that you have to manually set the application name if you add IStartup to the container manually.

[CheloXL]

@davidfowl ok, so, two things: 1) How do I do that? 2) Why on 1.1 I don't have to do so?

@JunTaoLuo yes, I already created a test case. But if @davidfowl is right (and I can setup the application name manually and it works), there should be no need for that. Waiting for (1) to try...

[davidfowl]

1. How do I do that?

.ConfigureServices(services =>
                {
                    services.AddSingleton<IStartup, Startup>();
                })
                .UseSetting(WebHostDefaults.ApplicationKey, typeof(Startup).GetTypeInfo().Assembly.FullName)

2. Why on 1.1 I don't have to do so?

This is a regression caused by this change https://github.com/aspnet/Hosting/commit/ce650eee7f9a5e87e27baaf66a8a2d373530ded3, we no longer fallback to the entry assembly. @anurse I think we agreed this wouldn't break anyone but it breaks this scenario.

[CheloXL]

@davidfowl Perfect. That worked like a charm. Thanks. I would like this to be documented somewhere. I had to migrate my old authentication code and while that wasn't funny, at least it was well documented.

[davidfowl]

@muratg @Eilon This should be a patch candidate.

[muratg]

@JunTaoLuo Could you file 1.0.6, 1.1.3 and 2.0.1 bugs to track this as a patch candidate?

[JunTaoLuo]

Patch issues added.

[JunTaoLuo]

@muratg Actually I think this is only a 2.0.1 patch. The original fallback was removed in 2.0.0 only. 1.1.3 and 1.0.6 are not affected.

[muratg]

Thanks @JunTaoLuo. @Eilon, this is a candidate as well.

[JunTaoLuo]

Let's keep this as 2.1.0? I filed the patch candidate for 2.0.1 at #1177

[muratg]

@JunTaoLuo OK sounds good.

[khellang]

This is a regression caused by this change ce650ee, we no longer fallback to the entry assembly. @anurse I think we agreed this wouldn't break anyone but it breaks this scenario.

@davidfowl The commit you linked even added a test explicitly testing this scenario; https://github.com/aspnet/Hosting/commit/ce650eee7f9a5e87e27baaf66a8a2d373530ded3#diff-83865cc417298cc5d089887c9a0094f9R658

[davidfowl]

Yes, it was never supposed to happen in the common case. Turns out if you add an IStartup to the container directly, those assumptions fall apart.

[analogrelay]

Yep, this is the scenario where it requires a change. I remember discussing it at the time, hence the test @khellang referenced. It does look like it didn't get clearly called out in the Announcement though (https://github.com/aspnet/Announcements/issues/237), which was a mistake.

[analogrelay]

See https://github.com/aspnet/Hosting/pull/1023

The only way to get in the situation where the "non-empty application name" message occurs when the app would otherwise start is if you manually insert an IStartup into the container. In which case, you should still get this error because we need an application name in order to proceed.

This should have been called out more clearly in the Announcement, which is my bad. I've since updated it to help anyone searching for this issue in the future.

[Eilon]

Please email me patch candidates... too hard to track these on GitHub.

[davidfowl]

@Eilon would tags help?

[Eilon]

Not really, because even though we have tags, people keep using them incorrectly 😄