Support Microsoft.AspNetCore.OData

[GrayPockets]

Currently the Microsoft.AspNet.OData.Versioning package supports .NETFramework 4.5 and Microsoft.AspNet.OData.

If you're a user of Microsoft.AspNetCore.OData, there does not seem to be an alternative.

We'll need a Microsoft.AspNetCore.OData.Versioning package.

[commonsensesoftware]

It would seem the owner of this package has pulled a fast one on you. That is not an official Microsoft package. I'm internally reaching out to the OData team to be sure. I won't be surprised if the owner isn't contacted to unlist that package.

The official OData repo is https://github.com/OData/WebApi. There is no current, stable implementation for ASP.NET Core (trust me, I wish there was). When it becomes available, I plan on having support. I tried playing with the Alpha bits at one point, but not enough was there.

Sorry for the confusion. I hope that helps. If you're still using the Web API stack, I am happy to say that support for 6.0 will becoming in the 1.1.0 release, which I'm getting close too. The last big chuck is actually adding the Swagger support for OData with versioning.

[GrayPockets]

No fast one here, that package is an unofficial one forked from the official one, since the official one has no stable release. The owner has a PR awaiting merge on the official repo. I figured you might want to wait until the official release, but you might want to pre-build, so to speak.

[commonsensesoftware]

I was to able to confirm with the OData team that they don't own this, but apparently there is a PR they took - as you stated.

I'm a big OData fan and advocate myself. As much as I'd love to support a pre-release, I'm sadly one-man army here. Once there is public NuGet package available for OData on ASP.NET Core, I definitely will consider starting work to support it. I won't be able to support a continuous influx of changes though. Fortunately, most of the OData integration is light. The majority of the work is down in the lower levels.

Probably not the answer you were hoping for, but this topic is certainly on my mind. I've actually been champing at the bit for the OData support for nearly two years. I'm just happy it finally looks like it's going to happen. :)

[mokth]

hope the Asp.net core OData will be available soon.

[jvelezc]

Come on guys! I need ODATA!

[HaroonSaid]

.net core 2.0 has been released - where is OData? Whats the timeframe for release?

[commonsensesoftware]

If you're looking for OData support on .NET Core, then this is not the repo you are looking for. ;) You'll want to file (yet another) grievance in their repo - https://github.com/OData/WebApi/issues. I am a lonely army of one. I'd love to support OData on .NET Core, but I simply don't have the capacity to port the platform. You might also consider posting on https://github.com/aspnet/Home/issues.

If you're looking for support for OData 6.1.0 on Web API, I assume the current flavor will work. If that's not the case, I'll consider taking a look. I usually don't have a lot of extra cycles to chase pre-release versions. If the 6.1.0 release requires a change, I will definitely provide an update as appropriate.

I can't be believe there still isn't support for OData on ASP.NET Core yet myself. I'm clamoring for it just as much as the next guy. Based on my limited inside knowledge, there is a team working on it - somewhere. I don't have any other details. I did manage to scour that the ODataLib 7.2.0 now supports .NET Standard 1.1, which is 100% compatible with .NET Core. It would seem that a ASP.NET Core flavor may not be far off. We've all waited long enough. If someone learns of an official version, even pre-release (I'll make an exception), I'll look into adding support.

Thanks

[philcarbone]

Does this versioning library support OData on ASP.NET Core?

[philcarbone]

@HaroonSaid OData is now available on ASP.NET Core 2.0. I'm still wondering if that is on the radar for this library?!

[commonsensesoftware]

@philcarbone - yes - OData support for ASP.NET Core is still on the radar. The current OData support for ASP.NET Core only recently became available recently (~2 months ago). Unfortunately, the new OData team is not part of the ASP.NET team nor am I. I do have semi-regular discussions with the ASP.NET team to try and keep things flowing smoothly for customers. I've had very little interaction with the OData team. I'm not sure what their schedule is, but their release is still only beta. This is one reason why this issue has been lower on the priority list.

Despite recommendations from the ASP.NET team, the OData team has continued to keep things close to how they were in Web API. On one hand, that's an admirable goal to help developers transition, but on the other, I think we all expect a pretty big change given a new platform. In my opinion, they should rethink a number of things; especially, routing. The consequence is that now I have to go learn and understand their design to make things work with API versioning. It's unclear how long that will take, but if you compare the existing OData support in Web API it took about 80% research and only about 20% actual coding effort as evident by the relatively small amount of code required. In Web API, I ran into numerous scenarios where I had to completely re-implement OData components or leverage very tricky Reflection hacks to make things work. It goes without saying that I'll likely run into similar issues, but now that things are open source with an active team, there's a chance to influence changes as required.

Ultimately, the work required is to make the custom OData routing play nice with the standard ASP.NET Core routing and API versioning. In general, the other platform implementations have stabilized so that should give me time to focus on this effort. I'll reiterate that I'm a big OData fan myself so I want this feature if not for my own self reasons. ;)

[philcarbone]

Hi @commonsensesoftware ! Thanks for the update! I've personally made a versioning and (multi-tenant-prefix) styled OData library for my company (in .NET 4.6) and I was starting to port it for .NET Core when I ran across your wonderful library. You are right, some things can be a bit hacky when customizing the OData stack and not all of it uses injection as the reset of the new ASP.NET Core MVC now leverages. I am MORE than willing to help out if there is anything I can do to help move this along (Especially since I'm already working on this code for my own purposes). I love what I see in your library and it is more robust than my own niche implementation. Anyway, if you are are able to, I'd love to contribute and I can even spend some time on the phone or what-not to discuss design, direction, etc. Let me know.

[lalvaradoday]

Hi @philcarbone , so is finally asp.net core supporting odata?

[commonsensesoftware]

@philcarbone I would definitely welcome the help. I've been getting more and more inquiries about this topic lately. I'm imminently about to serious work on this. I'm sure exactly how much help I'll need just yet. I suspect that 80%+ of the current OData support will be portable to the ASP.NET Core flavor. The real differences will be how routes are registered and the routing itself. If you've reviewed the Web API support today, you'll notice that there isn't a lot to it and much of it piggybacks on the Web API routing infrastructure.

I expect to have some kind of branch visible by this weekend. I'll keep the working changes there so people can see the progress and provide feedback. If I have questions, I'll post them here. If I find that I can split work off, I'll offer up bits that you or others can take up.

[commonsensesoftware]

@lalvaradoday - yes - OData has official Microsoft support on ASP.NET Core, but the library is currently in beta.

[philcarbone]

@commonsensesoftware Let me know what branch. I'll at least pay attention to what your doing, in case you summon me :)

[commonsensesoftware]

Thanks @philcarbone. I've pushed up a bare minimum start to the Support ASP.NET Core OData branch. There aren't new tests for anything - yet. There is a new sample project for basic OData support on ASP.NET Core that will show how things get set up. The overall design and approach is very similar to the Web API implementation. If you're already familiar with that, then there shouldn't be many surprises.

There are a couple of limitations in the OData design that I've had to work around:

1. VersionedODataPathRouteConstraint has to use the adapter pattern because the ODataPathRouteConstraint members are not virtual. >_<
2. The OData implementation replaces the IActionSelector with it's own implementation that doesn't integrate with an existing instance. API Versioning has to repeat the process and re-register an IActionSelector that extends the ApiVersionActionSelector with support for OData. To ensure things are more likely to be setup correctly, you have to use services.AddApiVersioning() first and then services.AddOData().EnableApiVersioning(). I don't really like this setup. If anyone has better ideas, I'm open to suggestions.
3. The VersionedODataModelBuilder is now resolved through dependency injection. This is actually a requirement because building out the EDMs per API version needs to be deferred until all conventions have been applied. I couldn't come up with another way. The new IODataApiVersionProvider reports all API versions supported and deprecated by all OData controllers. This is fed into the default VersionedODataModelBuilder implementation for use in GetEdmModel(). I could have refactored to use a parameter instead, but there are other useful DI features such as the IModelConfiguration entries. This will also maintain parity with the Web API version. The default registration can be replaced with a custom implementation.
4. IModelConfiguration registrations are now supported through DI and/or imperatively by adding to the resolved VersionedODataModelBuilder instance.

At a minimum, the happy path of the ~api/People and ~api/$metadata is working so there is something to play with. Batching is definitely not working. The required setup is unclear (with versioning). Next I'll start flushing out tests. I'm not sure whether unmatched conventions still need to the same approach as Web API with a catch all unversioned route.

Any thoughts or feedback is appreciated. Thanks.

[philcarbone]

Hi @commonsensesoftware, I'm looking at this now. #1 - Got it. #2 - We had to also implement our own IActionSelector in our versioning/multi-tenant solution. #3 & #4 we implemented differently only because we also injected other assemblies into the application for multi-tenant purposes. I am going to study the code. Will you create a PR once the code is being merged up? If so, I can provide another voice for reviewing this code. Let me know.

[commonsensesoftware]

Definitely. I normally do create PRs so people can see what and when I'm doing things. This is the first time I'm working this way on GitHub. What's the best way for you and the community to comment in this situation? A PR? If so, I can create it straight away.

[commonsensesoftware]

Queued up PR #267.

[commonsensesoftware]

For those following, here's an update. I wish I could put this at the top.

• [x] Implement MapVersionedODataRoute and MapVersionedODataRoutes
• [x] Implement OData and API version-aware IActionSelector
• [x] Implement VersionedODataModelBuilder
• [x] Implement VersionedMetadataController
• [x] Implement batching
• [x] Implement 400 (Bad Request) for unmatched OData controllers
• [x] Add tests cases
• [x] Add API version-aware Swagger support

This work is happening in the Support ASP.NET Core OData branch. Thanks to @philcarbone for helping code review and advance the progress.

Once I get everything except Swagger support in, I think it will be time to publish the first Beta package. If anyone wants an Alpha package before that, just speak up. There's a new OData Basic Example for anyone that wants to see how things will wire up. Questions or feedback about the design are welcome. The goal is to have close parity with the Web API setup.

[philcarbone]

Happy Build Conference week!

Any additional updates? We are really excited about the direction of this library and are preparing our projects to use it!

[philcarbone]

poke

[commonsensesoftware]

Apologies for the delay, I've been really busy lately and an internal team discovered a critical issue that triggered a big issue. I've just about got that published, but it resulted in me having to make an internal design change that I was planning on doing in 3.0. That accerlation in plan actually helps address a number of long-standing issues with middleware integration.

There is a relationship to the OData work. Since 3.0 will make middleware support much better, does result in behavioral changes, and OData does have middleware, I think it makes sense to roll the OData support forward as a task in the 3.0 release. That will delay things a bit longer, but for the better. Batching is one of the key remaining items and I think it will be affected by the routing changes. The good news is that there were only really two big items for 3.0 and one of them is now done (pre-aggregating API versions) and the other to interleave across types does not need to be done in the initial release. The OData team just release another beta that I presume contains a fix for an issue I filed.

As soon as I publish the next package (expect today), I'll add this task to the official 3.0 project board and start cranking away. I'll rebase the current branch into master after I have the routing updates in. From that point, I should be able start putting out beta releases.

Again, thanks for all the patience. I know you guys are clamouring for this, but I feel confident the wait will be worth it. I don't want to give you something sub-quality nor make you jump through big hoops during the beta releases.

[commonsensesoftware]

At long last, a beta quality bar release is complete and published for all to use. Thanks for all the input, feedback, and especially the patience. The links to the new packages on NuGet are provided in the readme on the landing page. There are also new example applications. I haven't had a chance to update everything on the wiki yet, but I'm working on it. If there are any questions in the meantime, feel free to ask. Thanks!

[philcarbone]

Thank you @commonsensesoftware ! We are checking it out. :thumbsup: