Diagnostics experience with IIS Express is very poor when application fails to start

[pranavkm]

Consider this application:

public class Startup
{
   public void ConfigureServices(IServiceCollection collection)
   {
      throw new Exception("Can't start me.");
   } 
}

When the app is launched via kestrel, we get a proper stack trace. However running this via IIS Express causes the browser to spin forever with no trace of the exception.

[sayedihashimi]

Here is what I get when I F5 for a project configured in that way.

What are you seeing? Can you give me some specific steps to follow?

[pranavkm]

My bad - the issue isn't when a user throws an exception. It happens if an exception occurs as part of creating the service provider:
For example:

public void ConfigureServices(IServiceCollection services)
{
     services.AddTransient<IDisposable, IDisposable>();
}

@Tratcher is this something hosting should be handling?

[Tratcher]

Stack trace?

[pranavkm]

The exception gets thrown from https://github.com/aspnet/DependencyInjection/blob/dev/src/Microsoft.Extensions.DependencyInjection/ServiceLookup/ServiceTable.cs#L32 as part of BuildServiceProvider

[Tratcher]

No, the full stack trace. I need to know where it's called in Hosting.

[pranavkm]

System.ArgumentException: Cannot instantiate implementation type 'System.IDisposable' for service type 'System.IDisposable'.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceTable..ctor(IEnumerable`1 descriptors)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(IEnumerable`1 serviceDescriptors)
   at Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()
   at Microsoft.AspNet.Hosting.Internal.HostingEngine.Start()
   at Microsoft.AspNet.Hosting.WebApplication.Run(Type startupType, String[] args)
   at Microsoft.AspNet.Server.Kestrel.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
   at Microsoft.Dnx.ApplicationHost.Program.<>c__DisplayClass3_0.<ExecuteMain>b__0()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()

[Tratcher]

That's not going to work. The server needs DI services, so if DI fails then we can't start the server.
https://github.com/aspnet/Hosting/blob/dev/src/Microsoft.AspNet.Hosting/Internal/WebApplication.cs#L174-L182

[pranavkm]

This goes back to the discussion we had with @BillHiebert which was to have some way for PlatformHandler to pipe Startup failures to VS. Without it, it looks like the server's spinning indefinitely.

[sayedihashimi]

@BillHiebert is working on this. He's creating a shim process to start the HttpPlatformHandler suspended and then after the debugger is attached it will resume HttpPlatformHandler and go away.

[Tratcher]

It's not HttpPlatformHandler that starts suspended, it's the application exe. HttpPlatformHandler spinwaits for the application exe to open the port and accept requests, and it's timeouts will be disabled if the debugger is attached to the exe.

[sayedihashimi]

@Tratcher

It's not HttpPlatformHandler that starts suspended, it's the application exe.

That's correct, sorry. My uber point is that @BillHiebert is aware of it and working to fix it. :)

[sayedihashimi]

This issue is pretty old. We recently released RC2 https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/. I'm hoping that this is no longer an issue so I'm closing this. If this is still an issue with RC2 please reopen this.

[Tratcher]

@shirhatti and @pan-wang are working on this. It has a long way to go.

[pranavkm]

According to @colemickens this issue hasn't been resolved. @colemickens, do you have a simple repro app for the tooling team to verify this?

[colemickens]

sure, here's a very trivial repro: https://github.com/colemickens/dotnet-cli-swallow-exceptions-repro

I ran it with: docker run -it -v $(pwd)/repro:/opt/repro microsoft/dotnet:1.1.0-sdk-msbuild where that repo is cloned to $(pwd)/repro

Despite an exception being thrown, it doesn't blow up until it tries to inject the IFoo instance to Configure(...):

Unhandled Exception: System.Exception: Could not resolve a service of type 'HelloMvcApi.IFoo' for the parameter 'foo' of method 'Configure' on type 'HelloMvcApi.Startup'. ---> System.NotImplementedException: The method or operation is not implemented.
   at HelloMvcApi.Startup.makeFoo() in /opt/repro/Startup.cs:line 22
   at HelloMvcApi.Startup.<ConfigureServices>b__0_0(IServiceProvider _) in /opt/repro/Startup.cs:line 13
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.<>c__DisplayClass16_0.<RealizeService>b__0(ServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.AspNetCore.Hosting.Internal.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Hosting.Internal.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at HelloMvcApi.Program.Main(String[] args) in /opt/repro/Program.cs:line 12

[Tratcher]

@colemickens DependencyInjection is all lazily evaluated, Your makeFoo method isn't run until someone requests an IFoo from the container.

[colemickens]

The failure output is still a bit confusing though, no? The actual exception is never surfaced.

[davidfowl]

It is:

Unhandled Exception: System.Exception: Could not resolve a service of type 'HelloMvcApi.IFoo' for the parameter 'foo' of method 'Configure' on type 'HelloMvcApi.Startup'. ---> System.NotImplementedException: The method or operation is not implemented.

It's the inner exception which is displayed as well as the service resolution failure.

[webtools-bot]

The GitHub Issue Tracker for the aspnet/Tooling repo is being deprecated in favor of Visual Studio's Report a Problem tool.

If this issue is still a problem with the RTW release of Visual Studio 2017, please report a new issue using the Report a Problem tool. While you can still use .NET Core and ASP.NET Preview tools with Visual Studio 2015, Visual Studio 2017 is now the officially supported tool for developing .NET Core and ASP.NET Core projects.

By using the Report a Problem tool (available in both VS 2017 and VS 2015), you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks. See Visual Studio's Talk to Us page for more details.

Please use the discussion topic here for feedback and questions on the deprecation of this issue tracker. Thanks!

[mlorbetske]

Closing this as there hasn't been any activity here in quite a while & it sounds like the information given on the failure is as it is expected to be. Additionally, for Visual Studio 2017, we've improved the amount of information given when the app itself can't start (instead of starting and then crashing) with more verbose logging to the output window. If you're still experiencing problems with this, please report it on the developer community site