Can't add Health Checks

[mdmontesinos]

I can't configure asp.net core Health Checks with a IServerStartup class due to the order in which they are executed.

This would be the IServerStartup implementation

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/health");
    });
}

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks();
}

And it throws this error on startup:

Application startup exception
      System.InvalidOperationException: EndpointRoutingMiddleware matches endpoints setup by EndpointMiddleware and so must be added to the request execution pipeline before EndpointMiddleware. Please add EndpointRoutingMiddleware by calling 'IApplicationBuilder.UseRouting' inside the call to 'Configure(...)' in the application startup code.
         at Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.VerifyEndpointRoutingMiddlewareIsRegistered(IApplicationBuilder app, IEndpointRouteBuilder& endpointRouteBuilder)
         at Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.UseEndpoints(IApplicationBuilder builder, Action`1 configure)
         at VisionSense.WKF.Startup.ServerStartup.Configure(IApplicationBuilder app, IWebHostEnvironment env) in C:\Users\User\source\route\owner\module.Server\Startup\ServerStartup.cs:line 21
         at Oqtane.Extensions.ApplicationBuilderExtensions.ConfigureOqtaneAssemblies(IApplicationBuilder app, IWebHostEnvironment env) in C:\Users\User\source\route\oqtane.framework\Oqtane.Server\Extensions\ApplicationBuilderExtensions.cs:line 21
         at Oqtane.Startup.Configure(IApplicationBuilder app, IWebHostEnvironment env, ISyncManager sync, ICorsService corsService, ICorsPolicyProvider corsPolicyProvider, ILogger`1 logger) in C:\Users\User\source\route\oqtane.framework\Oqtane.Server\Startup.cs:line 200
         at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
         at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
         at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
         at Microsoft.AspNetCore.Hosting.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
         at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
         at Microsoft.WebTools.BrowserLink.Net.HostingStartup.<>c__DisplayClass1_0.<Configure>b__0(IApplicationBuilder app)
         at Microsoft.AspNetCore.Watch.BrowserRefresh.HostingStartup.<>c__DisplayClass1_0.<Configure>b__0(IApplicationBuilder app)
         at Microsoft.WebTools.ApiEndpointDiscovery.HostingStartup.<>c__DisplayClass2_0.<Configure>b__0(IApplicationBuilder app)
         at Microsoft.AspNetCore.Hosting.WebHost.BuildApplication()

Basically, this occurs because this logic is invoked before UseRouting and all the other middleware in Oqtane.Server startup:

// execute any IServerStartup logic
app.ConfigureOqtaneAssemblies(env);

Is there any way to circumvent the issue?

[sbwalker]

@mdmontesinos currently there is no way to resolve this

[mdmontesinos]

@sbwalker Wait, so there's also no way to add minimal APIs to Oqtane, right? That is unfortunate...

[sbwalker]

@mdmontesinos actually there is always a way with open source... you can fork the project and modify the core framework to meet your own requirements

[sbwalker]

@mdmontesinos correct, there is currently no way to add minimal APIs to Oqtane - however anything you need to accomplish in a Minimal API can be accomplished using a traditional API - so technically there is no limitation (other than developer preference)

[mdmontesinos]

Right, thanks for the answer.

[sbwalker]

@mdmontesinos I experimented with moving the IServerStartup logic later in the Configure method... which would allow for additional endpoints to be registered:

            // execute any IServerStartup logic
            app.ConfigureOqtaneAssemblies(env);

            // simulate the fallback routing approach of traditional Blazor - allowing the custom SiteRouter to handle all routing concerns
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapFallback();
            });

            // create a global sync event to identify server application startup
            sync.AddSyncEvent(-1, -1, EntityNames.Host, -1, SyncEventActions.Reload);

And this appears to work fine for the core framework... and for a variety of custom modules in my environment. This change would only potentially cause issues for custom modules which are dependent upon the current location where this is called in Startup. Thoughts?

[mdmontesinos]

@sbwalker I'm not entirely sure in which cases you would need to execute logic before all the other middleware. However, the current behaviour totally prevents developers from using minimal endpoints, which are gaining a lot of popularity, or health checks, and possibly any other library that adds middleware related to routing, so I'd say the change is benefitial.

Still, I wonder if this could be a breaking change.