When running application on RC2, I am getting exception

[halter73]

From @keyurtechy on June 21, 2016 2:52

Hi,
When running the application on RC2, I am getting the exception. Here is the stack trace of that exception:

Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60:Error: Connection id "0HKSPFOMGGOFR": An unhandled exception was thrown by the application.

System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeAssembly.get_DefinedTypes()
at Microsoft.AspNetCore.Mvc.Controllers.ControllerFeatureProvider.PopulateFeature(IEnumerable1 parts, ControllerFeature feature) at Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartManager.PopulateFeature[TFeature](TFeature feature) at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.GetControllerTypes() at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.BuildModel() at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.GetDescriptors() at Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.OnProvidersExecuting(ActionDescriptorProviderContext context) at Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.GetCollection() at Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.get_ActionDescriptors() at Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.GetTreeRouter() at Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.RouteAsync(RouteContext context) at Microsoft.AspNetCore.Routing.RouteCollection.<RouteAsync>d__9.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.<Invoke>d__7.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Web.BrowserLink.Runtime.BrowserLinkMiddleware.<ExecuteWithFilter>d__5.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware.<Invoke>d__8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Hosting.Internal.RequestServicesContainerMiddleware.<Invoke>d__3.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Server.Kestrel.Http.Frame1.d__2.MoveNext().

Need to understand why I am getting that error. Here is the project.json. Let me know whether I am doing something wrong. The same application was working file in RC1

{
  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.0.0-rc2-3002702",
      "type": "platform"
    },
    "Microsoft.AspNetCore.Mvc": "1.0.0-rc2-final",

    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0-rc2-final",
    "Microsoft.AspNetCore.Server.Kestrel":"1.0.0-rc2-final",
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0-rc2-final",
    "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0-rc2-final",
    "Microsoft.Extensions.Configuration.Json": "1.0.0-rc2-final",
    "Microsoft.Extensions.Logging": "1.0.0-rc2-final",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc2-final",
    "Microsoft.Extensions.Logging.Debug": "1.0.0-rc2-final",
    "Microsoft.ApplicationInsights.AspNetCore": "1.0.0-rc2-final",
    "Microsoft.Legal.MatterCenter.Repository": "1.0.0-*",
    "Microsoft.Legal.MatterCenter.Models": "1.0.0-*",
    "Microsoft.Legal.MatterCenter.Utility": "1.0.0-*",
    "Microsoft.AspNetCore.Authentication.JwtBearer": "1.0.0-rc2-final",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc2-final",
    "Microsoft.AspNetCore.Diagnostics": "1.0.0-rc2-final",
    "Microsoft.AspNetCore.Http.Abstractions": "1.0.0-rc2-final",
    "Microsoft.IdentityModel.Tokens": "5.0.0-rc2-305061149",
    "Microsoft.Extensions.Configuration.Binder": "1.0.0-rc2-final",
    "System.Globalization": "4.0.11-rc2-24027",
    "System.Runtime": "4.1.0-rc2-24027",
    "System.Threading.Tasks": "4.0.11-rc2-24027",
    "System.IO": "4.1.0-rc2-24027",
    "System.Text.Encoding": "4.0.11-rc2-24027",
    "System.Xml.XmlDocument": "4.0.1-rc2-24027",
    "Newtonsoft.Json": "8.0.3"
  },
  "tools": {
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": {
      "version": "1.0.0-preview1-final"
    }

  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": [
        "dnxcore50",
        "net451"        
      ],
      "dependencies": {
        "Swashbuckle.SwaggerUi": "6.0.0-beta9",
        "Swashbuckle.SwaggerGen": "6.0.0-beta9",
        "Microsoft.SharePointOnline.CSOM": "16.1.5026.1200",
        "Microsoft.Exchange.WebServices": "2.2.0 "        
      }
    }
  },

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true
  },

  "runtimeOptions": {
    "gcServer": true
  },

  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "appsettings.json",
      "web.config"
    ]
  },

  "scripts": {
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
  }
}

Copied from original issue: aspnet/KestrelHttpServer#936

[halter73]

@keyurtechy It looks like Assembly.DefinedTypes is throwing a ReflectionTypeLoadException when MVC is trying to search for Controller types which is fairly unusual. Unfortunately the error message leaves a bit to be desired. As the exception message suggests, you really want to see the LoaderExceptions to figure out what's really going on.

I think MVC should have special logging for ReflectionTypeLoadExceptions like SignalR does. SignalR takes it a step further by using any Hub types found in the Types property of the exception and carrying on as if there was no exception at all (aside from logging). I'm not sure MVC has to take it that far.

In the short term, you can probably get more detail into the cause of the exception my adding some custom logging middleware before calling UseMvc. You could add something like the fallowing in your Startup.cs file:

using System.Reflection;

// ..

public void Configure(IApplicationBuilder app)
{
    // ..
    app.UseMiddleware<ReflectionTypeLoadExceptionLoggingMiddleware>();
    app.UseMvc();

// ..

public class ReflectionTypeLoadExceptionLoggingMiddleware
{
    private readonly RequestDelegate _next;

    public ReflectionTypeLoadExceptionLoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public Task Invoke(HttpContext httpContext)
    {
        try
        {
            return _next(httpContext);
        }
        catch (ReflectionTypeLoadException ex)
        {
            Console.WriteLine("ReflectionTypeLoadException!!! {0}", ex);

            if (ex.LoaderExceptions != null)
            {
                Console.WriteLine("Loader exceptions messages: ");

                foreach (var exception in ex.LoaderExceptions)
                {
                    Console.WriteLine(exception);
                    Console.WriteLine();
                }
            }

            throw;
        }
    }
}

[pranavkm]

@halter73 - perhaps the error page middleware would be a better fit for the exception unwrapping code ?

[halter73]

@pranavkm I didn't try it, because I didn't what to figure out how to create a ReflectionTypeLoadException, but are you sure the error page middleware will show you ReflectionTypeLoadException.LoaderExceptions?

Given no reference to this exception type and no use of reflection (including json encoding) in DeveloperExceptionPage.DisplayRuntimeException(), I doubt the error page will show info visible only by reading a property specific to the exception type.

This is another reason that MVC should probably handle this exception type explicitly. Perhaps it could just throw a new exception with more details from the LoaderExceptions in the main Message.

[pranavkm]

Nope - I was implying we should have the exception unwrapping code in the diagnostics middleware. I don't think it exists as of now.

[Eilon]

MVC 1 - 5 originally had some logic in it for this exact exception. I'm guessing that's where SignalR got its logic from 😄 I would think in the new world perhaps it is best to catch the exception, handle all the types that did load, and log all the errors? The "annoying" thing about this exception is that it can sometimes be innocuous. E.g. sometimes apps have DLLs that reference other DLLs that aren't deployed because perhaps they're used only in other scenarios (e.g. design-time or test-time only), but Reflection will throw an exception if it can't resolve the base class of a type, even though that type is not of any interest to the scenario in question (e.g. discovering controllers).

[Eilon]

@ajaybhargavb please discuss with @pranavkm to make sure all 3 of us are on the same page here before we code this up.

[rynowak]

The "annoying" thing about this exception is that it can sometimes be innocuous. E.g. sometimes apps have DLLs that reference other DLLs that aren't deployed because perhaps they're used only in other scenarios (e.g. design-time or test-time only)

Is this still a relevant concern in the project.json/dotnet world?

Type-load exceptions are probably the number one way people discover they have a package mismatch. Putting it in the log means that most won't notice it until they notice that one of their controllers is missing, and we've turned something obvious into a silent failure. VS users today don't really see the console log today.

This just seems like a workaround for something that shouldn't be common in a package-centric workflow.

[pranavkm]

I agree with @rynowak , Logging isn't a great source of discovery of issues. Unwrapping the exception as part of displaying it in Diagnostics seems like something we could do pretty easily and it has higher value than logs. Even in your scenario of missing types, seems like it would be more useful to see the name of the assembly rather than a generic TypeLoadException.

[davidfowl]

+1 on a diagnostics page to show something special for these types of exceptions. Though it won't cover all of the cases though for e.g. The hosting dll can't be loaded

[pranavkm]

@davidfowl would that be too early for the Startup error page to show anything?