.MapFallbackToPage() in RazorPages-Project fails with "UnsupportedApiVersion"

[DNF-SaS]

2.1+ allows Razor Pages to pass through

Sorry to say, but adding

services.AddApiVersioning(options =>
{
  options.DefaultApiVersion = new ApiVersion(1, 0);
  options.AssumeDefaultVersionWhenUnspecified = true;
});

and

app.UseEndpoints(endpoints =>
{
  endpoints.MapRazorPages();
  endpoints.MapFallbackToPage("/Index");
});

to a NET5.0 Razor Pages project created from the default template also throws the UnsupportedApiVersion error:

{"error":{"code":"UnsupportedApiVersion","message":"The HTTP resource that matches the request URI 'http://localhost:5000/' is not supported.","innerError":null}}

Referenced ApiExplorer is 5.0.0-preview.1

Originally posted by @DNF-SaS in #189 (comment)

[commonsensesoftware]

Are you saying this only happens if you use MapFallbackToPage? API Versioning does not consider endpoints that do not use [ApiController] conventions. Do you have a repro?

[DNF-SaS]

Are you saying this only happens if you use MapFallbackToPage? API Versioning does not consider endpoints that do not use [ApiController] conventions. Do you have a repro?

Yes.
And yes, very simple:

1. Create new project from template "ASP.NET Core Web Application" using C# - select "ASP.NET Core Web App" in the "Create a new ASP.NET Core web application"-page of the wizard
2. Run the application - it will start and show the index-Page (big 'Welcome' Headline)
3. Stop the application.
4. Add NuGet-Reference to Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer (5.0.0-preview.1)
5. Open Startup.cs
6. Add services.AddApiVersioning(); to ConfigureServices()-Method (after Line 26)
7. Add endpoints.MapFallbackToPage("/Index"); to Configure()-Method (after Line 50)
8. Start application again and voilà: the ApiVersionUnspecified-Error shows

[commonsensesoftware]

This is, in fact, a bug.

It turns out this is a regression due to IDynamicEndpointMetadata. API Versioning previously didn't care about this at all, but OData makes extensive use of it. It turns out that other policies such as mapping a fallback also uses this. I need to dig in some more to figure out how to disambiguate dynamic OData routes or whether there is an alternative.

Thanks for trying out the preview and reporting this. It will almost certainly affect the current release candidate too.