Please add support for OData endpoint routing

[mikepizzo]

Starting with Microsoft.AspNetCore.OData 7.3, we support .NET Core 3.1, which enables folks to forward-migrate their code from the (now deprecated) .NET Core 2.2 with very little change.

However, due to limitations in how .NET Core 3.1 does endpoint routing, we do not yet support endpoint routing in Microsoft.AspNetCore.OData.

Many people would like to use the new endpoint routing in .NET Core, so this issue is to track supporting endpoint routing in Microsoft.AspNetCore.OData.

See Issue #1748 for additional discussion on .NET Core 3.x and endpoint routing requirements and support.

[xuzhg]

@ALL

An Endpoint routing nightly version is available at:
https://www.myget.org/feed/webapinetcore/package/nuget/Microsoft.AspNetCore.OData/7.4.0-Nightly202001292116

It enables the Endpoint routing now. This Nightly is related to the PR at #2035.

If you are interested in, please try the nightly and share us your thoughts.
Also, i'd happy to see any contributes for my PR to make Endpoint routing available to customers ASAP.

Besides, i have a sample project using this Nightly. For detail, feel free to refer: https://github.com/xuzhg/WebApiSample/tree/master/AspNetCore3x/AspNetCore3xEndpoint

[NetTecture]

Whiw. Let me add a direct question - what happens to the "we MUST wait for .NET 5 before enabling endpoint routing"?

I love that - this means that you an acutally use SignalR (Blazor server model) in the same application if needed (not that you should - at least keeping the API separate does make sense).

Well done with that. I liked the first release without endpoint routing. As in: Get it out in any means possible, then try to make the rest work. That worked well - I am near ready to deploy a .net 3.1 upgrade the next days, and then we can move forward from this after that. VERY nice.

When would this hit regular build release? a month? two? What actually IS the release cadence? When is 7.4 planned?

[KanishManuja-MS]

@NetTecture Thanks for asking the question candidly. The endpoint routing in .NET Core 3.0 did not support method overloading. This is the reason why the official communication was that we would have to wait for .NET 5 before we could support endpoint routing. However, given the community was asking for endpoint routing and we anticipated that timeframe (to wait 10 months) was not reasonable and therefore @xuzhg continued investigating for a reasonable workaround.

We have the workaround now and we are working closely with .NET folks to natively support OData's requirements. Hopefully, with .NET 5, we will see a better solution for the same and perhaps some performance improvement in routing. I hope that answers your question and thanks again for your continued enthusiasm in providing feedback.

[harshan007]

Thanks much for this, we are building a service fabric application using OData based on ASP.Net Core 2.2 and we badly wanted endpoint routing to build a custom middeware that requires routing to be resolved.

If i undertstand correctly, does this workaround only for .Net Core 3.1? Or does this also support .Net Core 2.2 (if not do you intend to port this workaround to also support .Net Core 2.2)?

I configured endpoint routing following this:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  //added endpoint routing that will resolve the endpoint object
    app.UseEndpointRouting();

 //our custom middlware
    app.Use((context, next) =>
    {
        // Doesn't work! :(
        var endpointFeature = context.Features[typeof(IEndpointFeature)] as IEndpointFeature;
        var endpoint = endpointFeature?.Endpoint;

public void Configure(IApplicationBuilder app)
{
    // Add the endpoint routing matcher middleware to the request pipeline
    app.UseRouting();

[NetTecture]

You would be surprised that noone with any sense of time will support .NET core 2.2. 2.2 is totally out of support by now - it was retired in December and is not even getting security fixes anymore. It is basically wasted time trying to backport anything - you end up being the only one doing so.

https://dotnet.microsoft.com/download/dotnet-core

lists end of support in 2019-12-23. And yes, that is - amazing, but it is as it is. Note that 3.1 End of Support is 2022-12-03. The last LTS before 3.1 is .NET Core 2.1 - 2.2 was NEVER intended to be used long term. Which is a little odd, but it is as it is ;)

[JohnGalt1717]

@NetTecture The obvious issue is that when .NET 2.2 was released we were promised a viable release before it expired, so based on Microsoft's promise, lots of us went to .net 2.2 and used it's features assuming that they were being honest. It turns out that even now, there is no viable release to upgrade with out hundreds of man hours (so far and counting!) to work around the endless issues introduced in .net core 3.x. Here's a short list:

1. Json serialization is just broken. If you use Newtonsoft, lots of packages are no longer supporting it, so you have trouble there, and if you don't, the built in one is vastly incomplete.
2. EF Core 3 breaks queries that used to work (and used to work with server evaluation, because we treated the warning as an error!) compared to EF Core 2.2. But guess what? The only way to test is to run your code, there's no compile time warning. So we have to have 100% code coverage of all code paths that call our database to be able to upgrade to EF Core 3.
3. OData - Completely broken and they didn't even start working on it until after V3.0 was released. Still doesn't work properly.
4. Azure Function apps (still not released, still in preview even though .net core 2.2 is EOL and a security risk) DI broken in multiple ways, one so bad that if you try and replace IConfigurationManager with your own after using Azure KeyVault injection the function will crash, thus blocking updating at all and of course downstream projects that the functions depend on have to be upgraded to V3 for database etc. so complete blocker. (what's new, the Azure Function host is possibly the most brittle ... thing ever released from Microsoft, the issue are legend) Best part is that there's no longer any way to actually debug into that startup code so you're religated to using Console.WriteLine to try and diagnose all of the things it's freaking out about now that worked before.

I could go on. But what's absolutely clear is that .net core 3.x shouldn't have ever been released in it's current state, and MS needs to extend security patches for .net core 2.2 support until they have a viable upgrade path that isn't a disaster. That means working, fully functional json; working fully functional odata; all ef core 2.2 queries that executed on server side before, executing server side now without errors (and give us an analysis tool that will go through a project and find every single existing query that will fail and error and give us a report so we can go fix them); and Azure Functions actually working as a start.

The .net team needs to do a lot of navel gazing as to their huberous and what they've done to their customers on this and fix their mistake by supporting .net core 2.2 until they fix the rest of it and give a viable upgrade path.

[cilerler]

@harshan007 @NetTecture @JohnGalt1717 would you mind creating a separate issue and not hijack this one. Thanks in advance.

[wjvii]

I am trying to use the new 7.4 nightly build with a new project and must have something wrong with the routing. I am wanting to use this with EF Core 3.1 and not a custom OData model. However whenever I call what I think is the right endpoint I get:

Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
An unhandled exception has occurred while executing the request.
System.InvalidOperationException: Cannot find the services container for the non-OData route. This can occur when using OData components on the non-OData route and is usually a configuration issue. Call EnableDependencyInjection() to enable OData components on non-OData routes. This may also occur when a request was mistakenly handled by the ASP.NET Core routing layer instead of the OData routing layer, for instance the URL does not include the OData route prefix configured via a call to MapODataServiceRoute().

The method appears to be MapODataRoute but it takes a model as a parameter and I want it to work with Entity Framework and my existing entities.

Is it best or required to use EnableDependencyInjection in this case or is there another way to setup a route for OData and still use it with Entity Framework Core.

Thank you in advance.

[SiberaIndustries]

The method appears to be MapODataRoute but it takes a model as a parameter and I want it to work with Entity Framework an my existing entities.

Where is the problem or rather how did it work without using ODataConventionModelBuilder before?

I've tested the latest nightly in my netcoreapp3.1 project and it is working properly. I also use EF Core 3.1 and EnableDependencyInjection is definitely not required for an OData-only case. I just had to change a few lines of code.

OLD CODE

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options => options.EnableEndpointRouting = false);
    // ..
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // ..
    app.UseODataBatching();
    app.UseMvc(routebuilder =>
    {
        routebuilder.Select().Expand().Filter().OrderBy().MaxTop(100).Count();
        routebuilder.MapODataRoute("odata", "api", model, new DefaultODataBatchHandler());
    });
}

NEW CODE

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    // ..
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();
    app.UseODataBatching();
    app.UseEndpoints(endpoints =>
    {
        endpoints.Select().Expand().Filter().OrderBy().MaxTop(100).Count();
        endpoints.MapODataRoute("odata", "api", model, new DefaultODataBatchHandler());
    });
}

I hope a stable release comes soon :)

[NetTecture]

Do we have any indication when this will be released? I have repeatedly asked at least for an outline of your planned release schedule (i.e. like "we plan to do a release every quarter, feb, mai etc.) so we can have an idea ;)

Is this nightly build compatible with API versioning?

[aivascu]

@NetTecture I think #2035 is the "confirmed" solution to endpoint routing. It has the 4.7 Beta milestone reference and all.

[NetTecture]

@aivascu And when would this be released? What IS the release cadence for this?

[aivascu]

@NetTecture I'd like to know that too since I've got work that depends on this missing feature.
By the looks of that PR there is still some work as it has been destroyed at code review. 😅

[NetTecture]

Ok, trying to move my setup code to the nightly with endpoint routing, I am stuck with this error.

Code:

            e.MapODataRoute(
                "odata", null,
                b => {
                    b.AddDefaultODataServices(ODataVersion.V401);
                    b.AddService(ServiceLifetime.Singleton, sp => model);
                    b.AddService<ODataDeserializerProvider>(ServiceLifetime.Singleton, sp => new Code.EntityReferenceODataDeserializerProvider(sp));
                    b.AddService<IEnumerable<IODataRoutingConvention>>(ServiceLifetime.Singleton, sp =>
                        ODataRoutingConventions.CreateDefaultWithAttributeRouting("IgnoredRouteName", sp));
                }
            );

As you can see, I have to use a little more complex setup because I am putting in my own serializer for handing some specific reference syntax (odata bind).

I am stuck with an error and no idea how to fix this one. Executing this gets me:

System.InvalidOperationException: 'No service for type 'Microsoft.AspNet.OData.IPerRouteContainer' has been registered.'

Where do I find that one and how do I register it? A look into the builder and the services extensions gave me no sensible methods.

As info: I do have AddOData up in the services configuration. I also played around with EnableDependencyInjection before and after the MapODataRoute call and have no luck. Stuck here - and I need this overload because of the customized deserializer.

[xuzhg]

Do we have any indication when this will be released? I have repeatedly asked at least for an outline of your planned release schedule (i.e. like "we plan to do a release every quarter, feb, mai etc.) so we can have an idea ;)

Is this nightly build compatible with API versioning?

@NetTecture We had a meeting with ASP.NET Core team yesterday and went through all codes in PR #2035. We are waiting the inputs from them to make sure whether the solution in the PR is "feasible" and "Ready for community" or "should we change something before RTM"? So, the release date is uncertain but soon. Please be patient.

[JohnGalt1717]

Where can I find the latest nightly for this?

[xuzhg]

Where can I find the latest nightly for this?

Is there any problem to use nightly at:
https://www.myget.org/feed/webapinetcore/package/nuget/Microsoft.AspNetCore.OData/7.4.0-Nightly202001292116 ?

[JohnGalt1717]

@xuzhg It's really old by tech standards. I was hoping that there was a more solid version.

[xuzhg]

@xuzhg It's really old by tech standards. I was hoping that there was a more solid version.

Here's the latest one: https://www.myget.org/feed/webapinetcore/package/nuget/Microsoft.AspNetCore.OData/7.4.0-Nightly202002252317. Hope can get more feedback.

[JohnGalt1717]

@xuzhg Thanks! I'm on vacation until Monday. Depending upon decisions being made about the future of .NET/Azure/Microsoft within our company, I'll let you know how it goes on our end early next week.

[mikepizzo]

@JohnGalt1717 — have a great vacation; we’ll look forward to your findings once you return. Let us know if you run into any issues!

[xuzhg]

@ALL
7.4.beta is out. Feel free to try it out at https://www.nuget.org/packages/Microsoft.AspNetCore.OData/7.4.0-beta

Any feedback is welcome. Please feel free file new issue to releated 7.4.beta

[xuzhg]

@ALL

And We just published a new blog related to 7.4.beta at: https://devblogs.microsoft.com/odata/enabling-endpoint-routing-in-odata/

Thanks @hassanhabib.

[Jamaxack]

I’m facing the issue on swagger UI page: {“StatusCode”:500,”Message”:”System.InvalidOperationException: No media types found in ‘Microsoft.AspNet.OData.Formatter.ODataOutputFormatter.SupportedMediaTypes’. Add at least one media type to the list of supported media types.”}

Using:
.Net core 3.1
Microsoft.AspNetCore.OData 7.4.0-beta
Swashbuckle.AspNetCore 5.0.0
Swashbuckle.AspNetCore.Swagger 5.0.0

[lsuarez5280]

@Jamaxack That's a known limitation of the Swashbuckle library that has nothing to do with this beta. There's lots of information out on the web about how to work around, but you can see various suggestions on https://stackoverflow.com/questions/50940593/integrate-swashbuckle-swagger-with-odata-in-asp-net-core.

[JohnGalt1717]

@Jamaxack After your endpoints.Select()....

Add endpoints.EnableDependencyInjection();

And before your mvc configuration add these:

services.AddOData();
services.AddODataQueryFilter();

You should be good to go.

[maboivin]

Hey guys, I'm trying to have both WebiApi (attribute routed) and OData in the same project and I'm still running into an issue where when the OData route is matched, it calls the (wrong) WebApi controller.

I have created a simple repro project here: https://github.com/maboivin/WebApiAndODataIssue.

Here's an extract of the logs when the route is matched but the wrong controller gets called:

Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/1.1 GET http://localhost:26679/api/odata/users  
Microsoft.AspNetCore.Routing.Matching.DfaMatcher: Debug: 1 candidate(s) found for the request path '/api/odata/users'
Microsoft.AspNetCore.Routing.Matching.DfaMatcher: Debug: Endpoint 'api/odata/{**ODataEndpointPath_odata}' with route pattern 'api/odata/{**ODataEndpointPath_odata}' is valid for the request path '/api/odata/users'
Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware: Debug: Request matched endpoint 'WebApiAndODataIssue.Api.WebApi.UsersController.Get (WebApiAndODataIssue)'
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executing endpoint 'WebApiAndODataIssue.Api.WebApi.UsersController.Get (WebApiAndODataIssue)'

And here's an extract of the logs when the route is matched but there's only the OData controller in the project:

Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/1.1 GET http://localhost:26679/api/odata/users  
Microsoft.AspNetCore.Routing.Matching.DfaMatcher: Debug: 1 candidate(s) found for the request path '/api/odata/users'
Microsoft.AspNetCore.Routing.Matching.DfaMatcher: Debug: Endpoint 'api/odata/{**ODataEndpointPath_odata}' with route pattern 'api/odata/{**ODataEndpointPath_odata}' is valid for the request path '/api/odata/users'
Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware: Debug: Request matched endpoint 'WebApiAndODataIssue.Api.OData.UsersController.Get (WebApiAndODataIssue)'
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executing endpoint 'WebApiAndODataIssue.Api.OData.UsersController.Get (WebApiAndODataIssue)'

I dug into the source code of the DfaMatcher and the EndpointRoutingMiddleware but couldn't find the right integration point so far. Are there any additional configurations needed? Do I need to override any service?

[joaopgrassi]

Just tried today the latest beta (7.4.0-beta) and I noticed something not working. Maybe it's just me doing something wrong but one never know.

I configured my OData route like this: (notice the guid route constraint on tenantId)

endpoints.MapODataRoute(
     "odata", "v1/tenants/{tenantId:guid}/odata", EdmModelBuilder.GetEdmModel());

My controller class has this attribute at the top [ODataRoutePrefix("Things")] and I only have one get method:

[ODataRoute]
[EnableQuery]
public IActionResult Get(
	[FromRoute] Guid tenantId, CancellationToken cancellationToken)
{
	....

	return Ok(query);
}

If I then visit the odata route

https://localhost:44325/v1/tenants/00000000-0000-0000-0000-000000000001/odata/entity

I get back the usual list of entity + the $metadata address:

{
  "@odata.context":"https://localhost:44325/v1/tenants/%7BtenantId:guid%7D/odata/$metadata",
  "value":[
    {
      "name":"Entity",
      "kind":"EntitySet",
      "url":"Entity"
    }
  ]
}

But the replacement of the Guid in the route is completely broken on the $metadata url. If I change the odata route on Configure to "odata", "v1/tenants/{tenantId}/odata", EdmModelBuilder.GetEdmModel()); then the substitution works fine. But the huge problem now is that I can put any value there and it still works.

I have the same thing configured in another API using the 7.3.0 and having the constraint there works fine. If enter an invalid Guid it doesn't work and gives me back a 404, which is what I expected. I presume the model binding happens and it sees it's an invalid Guid and doesn't find a proper endpoint for it.

I'll try create a repro later today and post here so you guys can debug.

[ImGonaRot]

Added the new 7.4.0 beta to my OData core 3.1 project and the endpoint routing is not working with either the OData Connected Service client or the Unchase OData Connected Service client.
https://docs.microsoft.com/en-us/odata/client/code-generation-tool
The "GET" is working but the "PUT", "POST", "PATCH" are not working with those clients.

Basically to get these clients to work, I had to roll back to use MVC routing.

services.AddControllers(mvcOptions => mvcOptions.EnableEndpointRouting = false);

// NOTE: If you remove the UseMvc it will break the OData Client proxy
// TODO: Remove the UseMvc once the OData team gets it working. 
app.UseMvc(routeBuilder =>
{
    routeBuilder.Select().Filter().OrderBy().Count().MaxTop(100);
    routeBuilder.MapODataServiceRoute("odata", "odata", GetEdmModel());
});


// NOTE: If you add the UseEndpoints it will break the OData Client proxy
// TODO: Add the UseEndpoints once the OData team gets it working. 
//app.UseEndpoints(endpoints =>
//{
//    endpoints.MapControllers();
//    endpoints.Select().Filter().OrderBy().Count().MaxTop(100);
//    endpoints.MapODataRoute("odata", "odata", GetEdmModel());
//});

I can provide sample project if needed.

[xuzhg]

@joaopgrassi Thanks for reporting this. Your scenario (constraint) is not fully supported.

So far, It's only replace the template in the prefix at https://github.com/OData/WebApi/blob/master/src/Microsoft.AspNetCore.OData/Extensions/Endpoint/ODataEndpointLinkGenerator.cs#L82-L101. That part welcomes any contribution.

[xuzhg]

@ImGonaRot Please share your sample project. Thanks

[xuzhg]

@maboivin Can you share a sample project also for us to dig more?

[maboivin]

@xuzhg Repro project available at https://github.com/maboivin/WebApiAndODataIssue. Also, I have opened issue #2107 as I thought it would be easier to track in a separate issue.

[rossbuggins]

Hi, I've followed the example at https://devblogs.microsoft.com/odata/enabling-endpoint-routing-in-odata/ and that is returning odata data well with the endpoint routing. However, trying to access the $metadata, is just returning a 404? i.e.

https://localhost:5001/odata/$metadata

[11:53:17 INF Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/1.1 GET https://localhost:5001/odata/$metadata
[11:53:17 DBG Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware] Wildcard detected, all requests with hosts will be allowed.
[11:53:17 DBG Microsoft.AspNetCore.HttpsPolicy.HstsMiddleware] The host 'localhost' is excluded. Skipping HSTS header.
[11:53:17 DBG Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware] The request path /odata/$metadata does not match a supported file type
[11:53:17 DBG Microsoft.AspNetCore.Routing.Matching.DfaMatcher] 1 candidate(s) found for the request path '/odata/$metadata'
[11:53:17 DBG Microsoft.AspNetCore.Routing.Matching.DfaMatcher] Endpoint 'odata/{**ODataEndpointPath_odata}' with route pattern 'odata/{**ODataEndpointPath_odata}' is valid for the request path '/odata/$metadata'
[11:53:17 DBG Microsoft.AspNetCore.Mvc.Infrastructure.ActionSelector] No actions matched the current request. Route values: []
[11:53:17 DBG Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware] Request did not match any endpoints
[11:53:17 DBG Microsoft.AspNetCore.Server.Kestrel] Connection id "0HLUMUG6DF47E" completed keep alive response.
[11:53:17 INF Microsoft.AspNetCore.Hosting.Diagnostics] Request finished in 182.992ms 404

[joaopgrassi]

@joaopgrassi Thanks for reporting this. Your scenario (constraint) is not fully supported.

So far, It's only replace the template in the prefix at https://github.com/OData/WebApi/blob/master/src/Microsoft.AspNetCore.OData/Extensions/Endpoint/ODataEndpointLinkGenerator.cs#L82-L101. That part welcomes any contribution.

@xuzhg I could give it a shot. Any tips on how to get started? Where's the target ASP.NET Code we ultimately want to use?

[ImGonaRot]

@xuzhg

Here is a link to the test project.
It includes both a Console client and an IIS Express OData site.

https://github.com/tcon47/tcon47.github.io/tree/master/TestODataCore

[mikepizzo]

Closing this issue as endpoint routing was added in 7.4 (we had to do a few hacks to get it to work against .NET Core 3.x, but working with the .NET team to have better support in .NET 5).

Please open a new issue if you are encountering any issues.

[tiwaripradeep123]

is this really fixed ? Can i use app.UseEndpoints or we have to rollback to app.useMvc ?

[mikepizzo]

Yes; you can really use endpoint routing in .NET Core 3.x with starting with the 7.4 version of Microsoft.AspNetCore.OData.

If you run into any issues, please create a new issue here.

Thanks!

[tiwaripradeep123]

thanks for quick response !
This setup is not working :(

services.AddControllers(opts => opts.EnableEndpointRouting = true)
.SetCompatibilityVersion(CompatibilityVersion.Version_3_0)
.AddNewtonsoftJson(opt => opt.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);

and
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
endpoints.EnableDependencyInjection();
endpoints.Expand().Select().Count().OrderBy();
});

[xuzhg]

thanks for quick response !
This setup is not working :(

services.AddControllers(opts => opts.EnableEndpointRouting = true)
.SetCompatibilityVersion(CompatibilityVersion.Version_3_0)
.AddNewtonsoftJson(opt => opt.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);

and
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
endpoints.EnableDependencyInjection();
endpoints.Expand().Select().Count().OrderBy();
});

@tiwaripradeep123 Here's a blog at https://devblogs.microsoft.com/odata/enabling-endpoint-routing-in-odata/, hope it can help you.