EndpointDataSource empty with top-level route registrations?

[RichardD2]

I have a unit test project to ensure that all of the routes used in my API client library can be resolved to actual endpoints in the API project.

To do that, I use the registered EndpointDataSource instance(s) to list the registered endpoints, TemplateParser / TemplateMatcher to match the path, HttpMethodMetadata to check the method, IRouteConstraint to match the parameters, and EndpointSelector to select the endpoint from the matching endpoints.

ApiRouteTester.cs

If I use app.UseEndpoints(e => { ... }) to configure the endpoints, then everything works as expected. But I get an ASP0014 warning telling me I should be using top-level route registrations.

app.UseRouting();
app.UseEndpoints(e =>
{
    e.MapControllers();
    e.MapMyMinimalApis(); // Custom extension method
});

If I switch to using top-level route registrations, then the EndpointDataSource is completely empty.

app.UseRouting();
app.MapControllers();
app.MapMyMinimalApis();

Is this expected? Is the EndpointDataSource now obsolete with top-level route registrations? And if so, is there a replacement I can use to find a matching Endpoint given an HTTP method and route path?

[vst121]

Hi! 👋

What you’re seeing is expected behavior with top-level route registrations in ASP.NET Core 7+. Here’s why:

1. EndpointDataSource behavior changed

• When you use app.UseEndpoints(...), all endpoints are registered in the central EndpointDataSource, which your test can inspect.
• With top-level route registrations (like app.MapControllers() and app.MapMyMinimalApis()), the endpoints are still created, but they are not collected in the same EndpointDataSource used by UseEndpoints.
• This is why your EndpointDataSource appears empty — it’s not obsolete, it’s just no longer populated in the same way for minimal APIs.

2. Replacement approach

• You can still inspect the endpoints by injecting IEndpointRouteBuilder or querying the DataSources property from app:
  var endpoints = app.DataSources.SelectMany(ds => ds.Endpoints);
• This gives you all registered endpoints, whether they came from minimal APIs or controllers.
• You can then use the same matching logic (TemplateMatcher, HttpMethodMetadata, etc.) on this collection.

3. Unit testing tip

• For minimal APIs, consider testing via the WebApplicationFactory / integration test approach.
• This allows you to hit routes programmatically and assert results without relying on EndpointDataSource internals.

So, EndpointDataSource is not obsolete, just less straightforward with top-level minimal API registrations. Using app.DataSources is the modern way to access all endpoints for inspection.

Hope that helps!

[RichardD2]

Excellent! Thanks for you help.

The only slight complication was getting an instance of IEndpointRouteBuilder registered in DI. It doesn't seem to be registered by default, and I couldn't see an obvious way to register the WebApplication instance in its own service provider.

I ended up having to "cheat" by registering an implementation factory which uses a static field containing the WebApplication instance for the test.

[TestClass]
public static class Startup
{
    private static WebApplication? _application;
    public static WebApplication Application => _application ?? throw new InvalidOperationException();

    [AssemblyInitialize]
    public static void Initialize(TestContext context)
    {
        _application = WebApplication
            .CreateBuilder()
            .ConfigureServices()
            .Build()
            .ConfigurePipeline();
    }

    private static WebApplicationBuilder ConfigureServices(this WebApplicationBuilder builder)
    {
        ...
        
        builder.Services.AddScoped<ApiRouteTester>();
        
        // The "cheat":
        builder.Services.AddScoped<IEndpointRouteBuilder>(_ => Application);
        return builder;
    }

    private static WebApplication ConfigurePipeline(this WebApplication app)
    {
        app.UseRouting();
        app.MapControllers();
        app.MapMyMinimapApis();
        return app;
    }

    [AssemblyCleanup]
    public static void Cleanup()
    {
        var application = Interlocked.Exchange(ref _application, null);
        if (application is not null) Stop(application).GetAwaiter().GetResult();

        static async Task Stop(WebApplication application)
        {
#pragma warning disable MSTEST0049 // Flow TestContext.CancellationToken to async operations
            await application.StopAsync().ConfigureAwait(false);
            await application.DisposeAsync().ConfigureAwait(false);
#pragma warning restore MSTEST0049 // Flow TestContext.CancellationToken to async operations
        }
    }
}

[vst121]

That’s a totally reasonable workaround 👍 — and you’re right, IEndpointRouteBuilder is not registered in DI by default.

That’s intentional: it’s considered a startup-time construct, not a runtime service. In normal apps, endpoints are meant to be consumed via routing/middleware, not queried from DI later, which is why WebApplication itself isn’t exposed automatically.

For tests specifically, your “static WebApplication” approach is a pragmatic solution and perfectly valid
If you want a slightly less hacky alternative, two options worth knowing about:

• Inject IEnumerable directly

public ApiRouteTester(IEnumerable<EndpointDataSource> dataSources)
{
    var endpoints = dataSources.SelectMany(ds => ds.Endpoints);
}

This avoids needing IEndpointRouteBuilder entirely and works for both controllers and minimal APIs.

• Build the app once and pass it explicitly to the tester
  If ApiRouteTester is only used in tests, treating it as an integration helper (instead of a DI service) sidesteps the lifetime/registration issue altogether.