Webapi: .NET Core 3.0 support?

[enchev]

It seems that latest official OData (Microsoft.AspNetCore.OData 7.1.0) cannot be used in .NET Core 3.0.0 Preview 2 MVC app:

Startup.cs

    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc(options =>
            {
                options.EnableEndpointRouting = false;
            }).SetCompatibilityVersion(Microsoft.AspNetCore.Mvc.CompatibilityVersion.Version_3_0);

            services.AddOData();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseMvc(builder =>
            {
                //
            });
        }
    }

Exception:

System.TypeLoadException: 'Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.'

Let me know if I've missed some setting!

[JohnGalt1717]

+1

[thomas-rose]

+1

[JohnGalt1717]

Still broken in Preview 3.

[madansr7]

@enchev , thanks for bringing this to our attention.
The team needs time to investigate the error. The current version of the library is built against Core 2.0 and we need to spend sometime to evaluate any breaking changes in 3.0 that would require a change in the behavior of OData libraries.

[JohnGalt1717]

@madansr7 Mostly this has to do with routing because of the new method of UseRouting(). In the case of SignalR they updated their registration to work under the UseRouting(options => {}) instead of as a direct extension on the app.XXX.

[madansr7]

@JohnGalt1717, thanks for the info. This definitely helps!
We will put this up on our board for grabs.

[RomainAn]

Hi, no update about this issue ?

[sergiosysmiddle]

@JohnGalt1717, thanks for the info. This definitely helps!
We will put this up on our board for grabs.

Hello @madansr7 , any news?

[charlesjelliott]

+1 Also a problem for me

[Hantse]

For me too :)

[ace90210]

+1

[madansr7]

@JohnGalt1717, sorry for the delayed response. The team has this on the board now and we are investigating updates that need to be made.

[BlasVilla]

+1

[CLFPosthumus]

Issue remains with preview 4,
+1

[wakkasha]

+1

[aviezzi]

+1

[ycrespo]

+1

[cesfnc]

+1

[artemedea]

+1

[LisaTehChatBot]

@JohnGalt1717, sorry for the delayed response. The team has this on the board now and we are investigating updates that need to be made.

They know, and I miss which part of "preview" isn't clear

[ace90210]

@LisaTehChatBot it's called feedback, you know the point in releasing a preview

[robertmclaws]

Let's keep this on topic please, folks. No need to be rude to each other.

[Hantse]

Idk if that can help,

But i have similar issue in versionning and find the problems
https://github.com/microsoft/aspnet-api-versioning/issues/499

The class ActionConstraintCache is now internal on last version of .NetCore 3.0

[xuzhg]

The problem is from the usage of ActionConstraintCache class in ODataActionSelector.
in .NET Core 3.0.0, the ActionConstraintCache class is not presented.

If I remove the
public ODataActionSelector( IActionDescriptorCollectionProvider actionDescriptorCollectionProvider, ActionConstraintCache actionConstraintProviders, ILoggerFactory loggerFactory)

It works for the .NET Core 3.0.0 Preview4 by using old Route-based pattern. However, I can't use the _innerSelector, so we have to find a solution to make sure the innerSelector works also.

Besides, we still need to investigate whether to move to endpoint-based routing or router-based routing, or both. If you have any suggestions, please feel free share with us.

[rasolo]

I have no idea what is going on but what solved it for me was to remove ApiVersioning from my project.

So in startup.cs i removed:
services.AddApiVersioning(o => { o.AssumeDefaultVersionWhenUnspecified = true; o.DefaultApiVersion = new ApiVersion(1, 0); });

And removed the ApiVersion attribute from controllers.

I am using Web Api Core 3 preview 5, it worked in preview 3 for me.
I got the same error message as the OP.

[alberk8]

The problem is from the usage of ActionConstraintCache class in ODataActionSelector.
in .NET Core 3.0.0, the ActionConstraintCache class is not presented.

If I remove the
public ODataActionSelector( IActionDescriptorCollectionProvider actionDescriptorCollectionProvider, ActionConstraintCache actionConstraintProviders, ILoggerFactory loggerFactory)

It works for the .NET Core 3.0.0 Preview4 by using old Route-based pattern. However, I can't use the _innerSelector, so we have to find a solution to make sure the innerSelector works also.

Besides, we still need to investigate whether to move to endpoint-based routing or router-based routing, or both. If you have any suggestions, please feel free share with us.

I prefer that both endpoint-based routing and router-based routing be supported going forward as not to break legacy dotnet core apps.

[NetTecture]

At this point I do not care about legacy because the only way to use Odata sensibly in terms of efficient (ror better: correct) sql generation is moving to either efcore 3.0 or entity framework (in net 3.0 preview), given taht theere are a TON of scenarios in which efcore 2.2 is throwing out grossly defective SQL.

Is there any roadmap to actually give us poor abused end users a chance to PLAN this? And/or at least give us some preview or something? Right now this smells like abandoned code, looks like abandonec code and behaves like abandoned code. Which is why more and more post s here get snippy - frustrations building up.

[robertmclaws]

I'm not a Microsoft employee, just a community contributor with a little experience working with the OData team. So I'm gonna jump in here and see if I can provide some observations... but in order for that to happen, we need to have some real talk.

TL;DR: WebAPI OData is currently supported on .NET Core 2.2. If you can't do that because EF Core is generating bad queries (which is not the OData team's fault, I might add), you should be splitting your architecture (which you should have done anyways) and look to the more fully-featured EF 6.2 (which right now means using ASP.NET Classic) to meet your needs.

Now, for the real talk:

• OData is NOT abandoned, WebAPI is a HUGE part of ASP.NET and is not going away. I challenge ANYONE that thinks this code is abandoned to subscribe to notifications about changes to this repo. I'm FLOODED with emails every week from the team working on the next release. Go look at the Pull Requests FFS, some of them have over 100 comments. The team is clearly working. Complaining isn't going to make them work any faster, and it's not their fault if you're not paying attention to where the work is being done.

• The OData team at Microsoft is under the auspices of the Microsoft Graph team. Even though Graph is super-important to Microsoft, it is a DRASTICALLY underfunded team. They do not have anywhere near the resources the rest of ASP.NET does.

• The OData team has to support two different flavors of the runtime: .NET Framework and .NET Core. Until .NET 5 comes along, and everything is under one roof, this will continue to be the case. This means that an already underfunded team has to pull double-duty to service their customers. Not a situation I'd wish on anyone.

• .NET Core 3.0 is not shipping until September / October. There is no requirement that OData work with the preview releases, and there is plenty of time to ship OData support on .NET Core 3.

• .NET Core 3.0 has radical changes to how Routing works. Given what I know about the routing and dependency injection in OData, there are hefty changes that need to be made, so I would not expect .NET Core 3.0 to work for a little while.

• There have been no blog posts, no announcements, no indications at any time that OData is working on Core 3.0. So if you're spending time trying to get it working, you are on your own and working without a net. Should you go down that path, you should be in a helpful mindset of trying to debug through and identify problems and solutions. Otherwise you should be patient and wait like everyone else.

• This last one is important folks: No one _NEEDS_ their API running on .NET Core for your .NET Core app to function. I can say this with _certainty_ because I support a _dozen_ enterprise-scale APIs for different clients, and in those architectures, I have ASP.NET Classic APIs backing up ASP.NET Core 3.0 apps. You may _WANT_ your API running on .NET Core, but if that's because you're putting your APIs in the same app as your View's Controllers, you are likely making very bad architectural decisions, and should re-evaluate your design.

I _WANT_ to run my APIs on .NET Core, thanks to all the performance improvements in the request/response pipeline. But I also want the team to have the time to investigate what that means and to do it _properly_, so they don't accidentally do something that blows up memory usage or something.

Understanding the difference between wants and needs is important. We all want it does as soon as possible. The team NEEDS their time to do it right. We should all be trying to be tailwind, not headwind. Just my $0.02.

[pluraltouch]

@robertmclaws
Thx, but with all my respect, the most polite I can say, you are not helping, (despite of the size of your answer). You touch many out of topic areas like the team hierarchy, economical reasons, architecture lecture for all of us, important advice about life in general etc, but again we are seeking for a workaround/solution.

Regarding current implementation of OData is way behind AspNetCore 3... well we've all been mislead by its package and assembly name "Microsoft.AspNetCore.OData" so by default we thought its part of the Microsoft.AspNetCore, so there is a preview version of it, our bad. Now we know, there is no reason for OData implementation to follow AspNetCore 3 previews, and we also know the deadline to do that is far...

[robertmclaws]

@pluraltouch How are you misled by the package?

It seems pretty clear to me. "ASP.NET Core 2.0". Not 3.0. There's no preview tag, it's not versioned the same as the rest of .NET Core 3.0... I would understand if it had a version 3.0.0-preview5-346731 or whatever, but it doesn't. Misread != misled.

To all reading this: if you're already on .NET Core, then separate your API from the rest of your app, run the API on .NET Core 2.2, and the rest of your app on .NET Core 3.0. If you need guidance, please email me at robert at nimbleapps dot cloud, and I'll be happy to point you in the right direction.

Otherwise, unless you'd like to help update the library (it IS open source, and they take PRs) then just be patient. It's coming.

[bastienlemaitre]

I agree, but with the implementation of integrated identification it is difficult to stay on netcore 2.0 .. Odata should pass as standard on future releases, and be integrated as is WEBAPI .. Despite everything, I agree with you, it's written in black and white, it's incompatible at the moment :/

[keyhooon]

ایشالله درست میشه، غصه نخورید.

[si2030]

Is there a timeline for this upgrade to 3.0. I note this has been open getting on for 6 months now.

[si2030]

Not a word after 11 days.. I guess these guys are on holiday...

[Hantse]

Look on
https://github.com/microsoft/aspnet-api-versioning/issues/499

[KanishManuja-MS]

Thanks @Hantse. The above-mentioned issue might be fixed with preview 7 and there might be other issues that may need to be handled. We will be able to provide support for the preview versions but we are planning on supporting aspnetcore 3.0 by the time it releases.

@si2030 Apologies for the not being very responsive, we were focussing more on the upcoming 7.2 release but hopefully, you understand that we are also blocked by this issue to make progress. Please feel free to tag me or @madansr7 if an urgent response is needed.

[si2030]

Sure no problem.. can you guys tell me what needs to happen for Odata to be up and running on Asp.net core 3.0

I get the impression it might be working on preview 7.

I require Slickgrid which unfortunately uses Odata and I upgraded to 3.0.. bummer.

Just like to know what is the road block and what chance it might be available in the short term..

Cheers

[KanishManuja-MS]

@si2030 It is high on our priority list, however I won't be comfortable committing to a date as of now because there may be other unknowns but we are trying to have it supported by the time of 3.0 RTM.

[iuslkae]

Support .Net Core 3.0 please

[frabriziocontin]

Please help!!! Support .Net Core 3.0

[dorbacao]

I tried to use odata in preview 7 and also nothing

[robertmclaws]

Folks, they know they need to support .NET Core 3.0, and have already said it will happen. Your additional comments on the matter are noise and unhelpful. Please use GitHub's reaction features if you'd like to voice to supporting .NET Core 3.0... it generates fewer emails and makes the thread easier to read.

[saberone]

@robertmclaws I understand that you're "defending" the OData team. I don't think it's about the team. It has to do with the fact that Microsoft has abandoned a lot of promising tech before. So if you say : "The OData team at Microsoft is under the auspices of the Microsoft Graph team. Even though Graph is super-important to Microsoft, it is a DRASTICALLY underfunded team. They do not have anywhere near the resources the rest of ASP.NET does." That is the main issue here. Microsoft is not taking OData as serious as they want to make us think. Which in all honesty really SUX!.

I am by no means an OData specialist, but Odata in combination with EF Core is quite a challenge at times. Does that have to do with EF Core or OData? I wouldn't no. I really scares me if I can crash my whole application doing a fairly trivial Odata query. That's a specific anecdotal fact, but gave me a very bad feeling about OData.

But yes, I really appreciate the OData team effort. And that they are doing there best to make it all work. But Microsoft really should rethink what they want to do with Odata. Cause that other little thing called GraphQL is getting TONS of love from a much bigger community.

[robertmclaws]

The OData team doesn't need "defending", they need to be able to focus on their task list. I'm just pointing out realities as I see them, so people can understand perspectives. I think "Microsoft, the company" doesn't care about whether OData or GraphQL "wins". We're beyond protocol battles as an industry. They care if Azure wins. The fact that they hitched OData to Microsoft Graph is probably the only reason that OData is still alive, since it basically died twice.

The few resources that ARE still on OData are working diligently to make it the best experience possible. The query issues you're running into with .NET Core come from EF Core mostly, not OData. That's why I personally have been saying to stay the hell away from .NET Core for APIs for some time now. As long as it took regular EF to get "good", people should not have jumped headfirst into EF Core... but they did.

EF 6.3 + .NET Core will change the game. You'll get all of the speed and power of an established EF runtime with all of the speed of .NET Core. Combine that with Restier, and OData will be a new force for APIs in the .NET world. But it takes time to get there.

In the meantime, anyone reading this should take the time to regen their entity model in EF6 and implement their API as a separate WebApi2 project in their solution. You can complain about that concept all you want, but it's the only permutation of runtimes that I've seen work successfully, and that permutation is running in mission-critical systems that have saved lives and won tech awards.

To recap: Put your front-end in .NET Core, keep your APIs in a separate WebApi2 project that deploys separately. Then you can have a working solution until the .NET Core 3 architecture ecosystem works itself out.

[sherland]

I'm having the same issue with .NET Core 3.0 rc1 released today.

Is there a timeline for when OData will be supported in .NET Core 3.0?

[robertmclaws]

As @mikepizzo [mentioned on The OData Show last week, supporting 3.0 is going to take significant engineering effort to implement the new routing system. They have been busy implementing OData v4.01 and have not had a chance to work on that. Since they still need to support older versions of .NET Core, they'll have to break out the Routing like they broke out ASP.NET and ASP.NET Core in the first place. If you are already on .NET Core, you should break out your API from the front end and continue to compile it to .NET Core 2.2 while you move the rest of your architecture to 3.0.

[NetTecture]

Is there a link to that show? Because the constant refusal by the team to communicate anything resembling a release schedule is what leads to this mess. And if they went onto a show - I would love to see it.

What does "significant effort" mean? Weeks? MONTHS? A year? Because seriously, we are stuck in 2.2 with an EfCore implementation that breaks on trivial SQL - so bad that as a workaround I am pulling pretty much everythign in memory and then run queries from that. If I have to stay significantly longer on. NET core 2.2 - I have to rip out the ba efcore and go ef classic (for which thank heaven tehre is an open source implementation based on the published code).

[robertmclaws]

First off, it's not a "refusal", they are busy and are a small team. It gets done when it gets done. They just finished moving all of the OData docs to docs.microsoft.com, which was a massive undertaking... plus implemented Delta payloads in OData 4.01, which was itself a huge rearchitecture. They have modernized the unit test suite and now support two completely different platforms... it feels like you're not appreciating how much that small team is accomplishing.

There was a recording of the live show, but the audio was bad. I'll ask him again on the show next week... tune it at 12pm EST on https://bit.ly/RESTierYouTube. It's part of our bi-weekly community standups for shipping RESTier.... and there are 11 episodes up on the YouTube channel.

It is already the end of September, and I already explained what is required. Given that, I would assume that "significant effort" means "not in 2019", and plan accordingly. IIRC, they are going through a set of fixes up the stack, and then starting on specing out 3.0 support. They should have an idea of how long it will take within the next few weeks.

AFAIK you will be able to run EF Core 3.0 on .NET Core 2.2 You can also run Entity Framework 6.3 on .NET Core 2.2 as well. You can also drop the API down to .NET Framework 4.8 and run OData ASP.NET plus EF 6.3 on that. If you architected your app right, then it shouldn't be a problem.

You keep complaining about EF Core but it is not the OData team's fault that EF Core sucks. The EF team was crystal clear up front that the .NET Core implementation was going to be lacking for a while... not Microsoft's fault that you didn't heed their warnings.

Meanwhile, I'm trying to get an official RESTier Beta out the door, so we can ship that. You might want to start taking a look at the nightly builds and move your API to that... it is a LOT friendlier.

[si2030]

Ok so it was clear I would be white before I see anything I could use in 3.0 so I have had to write my own generic extension method for filtering and sorting via IQueryable and using dynamic Linq (builds an expression tree and executes it once the tree is finished). They can take all the time they want now.. anyway as I understand it OData may not be able to do filters across multiple tables etc which wasn't going to help me anyway and I couldnt wait for something that clearly was being regarded as either too hard or to low in priority...

[NetTecture]

as I understand it OData may not be able to do filters across multiple tables

Where you get that from? We do that with the current implementation all the time.

[si2030]

My apologies, I went back and reread the suggestion regarding complex nested tables and it appears its to do with the program that writes the queries for OData and not OData itself.

[BuairtRi]

@robertmclaws There's nothing wrong with developers communicating their needs and desires to the OData team and to Microsoft in general. If, in fact, the OData team is underfunded, then hopefully the OData team can take this thread to the higher-ups at Microsoft in order to advocate for additional funding.

I would argue that Microsoft, and particularly the OData team, needs to be better about communicating timelines and objectives to the community that utilizes those tools. Not all of us have time to watch specific podcasts. I'd love to see an active OData blog or announcements page that helps us understand the limitations of OData and where it is falling behind AspNetCore.

It took a very long time for OData to work on AspNetCore in the first place. I know that one thing that I personally dread, as a consultant, is seeing technologies get out of sync with each other. If OData cannot keep up with the pace of AspNetCore development, that needs to be communicated clearly to the community - so that the community can perhaps move on to GraphQL or some other solution that might have better resourcing (I know nothing about GraphQL on .NET Core's resourcing, just know that it's the next logical place to go).

For my part, I just wish there was clearer communication about OData, specifically, from Microsoft. This is a technology that I build a huge amount of my code on-top of, and when Microsoft does such a tremendous job of coordinating their releases in AspNetCore across the board, this OData stuff really just junks that whole process up.

That isn't to say that I don't appreciate the hard work and talent of the OData team. Just that I'd like to encourage them to improve their community engagement (something a product manager/owner at Microsoft should be pushing for, or doing).

[robertmclaws]

@BuairtRi I'll bring it up with Mike tomorrow and see what can be done about communicating the timeline.

Folks, I know it's disappointing/frustrating. I was in your shoes with OData's RESTier project for a long time. I'm working on articles to help guide people through how to structure your apps when requirements mean that the API and the front-end can't be on the same .NET. I've been doing it for literally years (not just over OData... Microsoft sometimes takes months after a .NET Framework release to roll it out to Azure Websites), and it's not as hard/bad as it might seem.

I'll report back tomorrow after the show. You can watch it live at 12pm EST at https://bit.ly/RESTierYouTube

[NetTecture]

Well, for most of my API's the API and the server HAVE to run on the same .NET instance otherwise I have a slution for a manager - totally useless. Bear with me.

Most of my servers actually are real time persistent data connection servers. Not web server with datbase style, but servers processing large amounts of data that partially MAY have a database behind them but keep a lot of data in memory.

The Odata API is the control and data management interface for those, not a seaprate web application. If I have to keep those in a different version, then basically - I need to make ANOTHER api that then is done in what?

Imagine API's (in Odata) that are used to control i.e. - hm - exchange server? or a system that processes real time data and does analysis which it enables people to pull ito excel using Odata.

So, in this case I have to wait.

Otherwise yeah - stay on 2.2 and try to get on EfCore 3 (was not even aware that should work - interesting. I was thinking they would use the new features). Will give that a try.

But as I REPEATEDLY said - the communication sucks. Seems you need more developers to maintain a one page 5 minute every 2 week basic roadmap - than you need to participate in a live show. Seriously. Just put up a wiki here with a high level roadmap, next coming / planned features and a rough planned timeline. That is a 5 minute task every couple of weeks.

[BuairtRi]

I think we'd all appreciate that.

This isn't just about front-end/back-end architecture differences. I do virtually no front-end development in .NET - it's all in Angular. All I build in .NET Core these days are APIs. But I work with Microsoft AspNetCore Identity along with OData. I do like to stay on top of updates to Identity, in case there are important security updates I need.

In this case, I would have to split my API into two separate projects - one that isolates all Identity operations, and one with OData operations, if I wanted to update Identity. Setting aside the fact that that's literally impossible (I need Identity in place in the OData controllers to provide the authentication/authorization backbone). Splitting the APIs causes all kinds of fun cookie/authentication issues, domain management or advanced server routing.

From a training perspective, it's also harder to explain to junior/mid-level devs why we have two separate API projects. It adds an administrative/training burden, which (for someone who also manages a small team) is not ideal. Splitting our endpoints across lots of different solutions, projects, and framework versions creates a pretty high learning curve, as well as a documentation nightmare. It's a lot easier if I can upgrade the whole enchilada to the latest version.

This isn't to say I couldn't pull them apart when/if necessary. I'm a pretty good architect. But my architecture skills are enhanced when Microsoft communicates upgrade schedules effectively. There's a flip side to this that the AspNetCore Team, which seems to have more community engagement expertise and manpower, could lend some assistance and document conflicts with OData, for example.

Thankfully, I don't need to upgrade immediately, so my whole eco-system will just say on .NET Core 2.2. But it is frustrating.

[Danielku15]

I would also really like to know how the future of this project looks like. The old ASP.net is more or less dead. ASP.net core and EF core on desktop framework are dead. The future is asp.net core on .net core 3.0 and .net 5. For me it would be great to know:

1. Is there a clear roadmap for supporting asp.net core 3.0 (and by this .net core 3.0)?
   We just started a new project based on OData. We need to know what to do for our release next year. You guys know it best how essential it is to start migrating your applications to the next-gen platform.

2. The project has a huge technical dept (source code wise) by maintaining an old-style ASP.net and a ASP.net core variant. Are there plans to drop ASP.net support and clean the source base?
   Considering all the abstraction layers, and hacks needed to support both worlds the overall situation of the library could be heavily improved by dropping ASP.net support. I saw that while analyzing various bugs and opening PRs.

[NetTecture]

Here is another little thing. Unless you are happy to run under .NET core 2.1 - you run out of support 3 months. Period. .NET core 2.2 is end of life end of the year. Now, it will not fail immediately - but it means that for a supported runtime you either need 2.1 (3 year long ter mstable version) or - .NET Core 3.0.

[JohnGalt1717]

@NetTecture Agreed it's that bad. But it will be .NET Core 3.1 by then. Hopefully they get their act together and sync up Odata to .NET Core 3.1 at least.

[mikepizzo]

Thank you all for your comments. I get that you're frustrated, and I do appreciate your passion.

The drastic changes that .NET Core 3.0 introduces are a challenge for us, as we still have customers on .NET Classic as well as .NET Core 2. While we are able to absorb the new framework releases in our lower level libraries fairly easily, the close integration of the WebAPI OData stack makes it much harder to adapt to the seemingly ever shifting landscape of ASP.NET.

We are on a quarterly planning cycle, and we seem always to have more than can fit into each 3 month planning cycle. We do rely on (and appreciate!) community contributions to help address specific blockers (such as the N+1 query issue whose solution was contributed by the community) that come up during the cycle, but something like refactoring to support .NET Core 3.0 is not someting we can realistically expect the community to drive. So this past quarter we allocated time to understand what we need to do to support .NET Core 3.0 in the planning cycle starting October 1st.

As a general policy we don't like to commit to dates for major work items like this because a lot of factors can influence our ability to meet those dates, and we don't want someone to take a hard dependency only to have their project fail because we were delayed due to unforseen circumstances. On the other hand, I understand that it's hard to schedule projects that take advantage of new platforms if you don't know when the components are expected to be available.

I honestly wish there was more I could tell you, but until we complete planning (in the next few weeks) I don't have dates I can give. I will say that we are well aware that this is the highest priority for the community, and are taking it very seriously.

[BuairtRi]

@mikepizzo Thank you for your reply!

Can I ask - are there ways that we, as the community, can help advocate for OData? Can we be emailing higher ups at Microsoft asking them to hire more people for the OData team? Can we be raising noise with the AspNet Core teams, asking them to coordinate more carefully with you or lend you team members to help with this project?

I definitely don't want to be suggesting that I don't understand the significant technical challenges that upgrading to .NET Core 3 presents, especially since there was such a significant rewrite of routing concerns.

As you said, community contributions to such a core element would be difficult. I'd offer to help, but I have my own client workload and parsing through and understanding all of the OData routing code seems fairly daunting if it wasn't a full-time endeavor.

[NetTecture]

@mikepizzo You know, here is a little hint on how to keep people askingaround for SOME roadmap quiet.

Head over to https://docs.microsoft.com/en-us/azure/devops/release-notes/features-timeline and look at the feature pipeline for Azure. VERY rough outlines, in quarters, with very small points each. Note how the future elements are NOT hyperlinks (and the existing ones lead to the azure ticket item). We do not really ask for more, and you are free to add a "by properity, items may be delayed" disclaimer on top. But having SOME idea is critical.

and appreciate!) community contributions

I tell you how much you appreciate them. I threw away code for some contributions because we considered the amount of work to pass your validation to be too much in smaller cases and our customers where not willing to pay for weeks for a supposedly smallish test case. Where I manage to have constructive discussions with the like of i.e. Simple.Odata.Client, any issue with the OData team turns into a "damn, is there an alternative" slugfest pretty fast. I get mostly answered "not a problem" (though it is for compelx scenarios), "please provide full test cases" - sorry, I do not get paid for that. I wish I would, but my clients do not. For me - and that may be in part that my use cases are not totally standard - OData looks like an old house with fresh paint. It looks good, but the moment you look under the hoot (try out something more complex) the amount of problems is brutal. WHich is sad- I am one hugh fan of Odata, thanks to finally having a standard that can support tooling, i.e. Excel.

Please publish SOME roadmap. Keep it like the Azure feature timeline an all of us wil lbe happy. I repeatedly asked for this, this is the FIRST time I hear SOMETHING that does not resemble "Leave the team alone ,tehy are busy doing stufff you do not see in the commits". It is frustrating. Some of us need to plan our own releases. Thiugns get delayed - we know that, but we need to know plans.

[mikepizzo]

@BuairtRi -- Thanks for looking to find ways to help!

The best way to get Microsoft to invest more deeply in OData is to use it -- and to let Microsoft and others know you use it, and how.

One of the challenges of OData has always been that we don't know who all is using it, and for what, which makes it hard to gauge what the value of ongoing investments in the community. We use it a great deal at Microsoft, but we don't have a good way to track use outside of Microsoft. We know some of the other big enterprise players, like SAP and IBM, and data integrators like Progress that are part of the OASIS OData Standards Technical Committee. We know it's used in other standards, like device management and real-estate, both of which have built standards on top of OData. We know from direct engagements it's used in places within government agencies and law enforcement. But anecdotal evidence suggests that's just the tip of the iceburg. If you look at the number of downloads of the .NET libraries, the contributions, comments, and passion from the community, there is a lot more use out there than what we see, and it's that community, more than the more visible enterprise companies, that use and contribute to the .NET libraries.

For a long time, the OData team at Microsoft was sponsored by the team that owned external data connectivity for Excel, PowerBI, Analytics, Machine Learning, Data Integration, etc. Investing in OData accrues value to those products to the extent that it brings relevant data -- your data -- for analytics, integration, and machine learning.

Several years ago Microsoft moved the OData team to the Identity Division in order to support Microsoft Graph. Microsoft Graph is an service that aggregates data across Active Directory, Office, Exchange, Sharepoint, Intune, Teams, and literally dozens of other Microsoft services. The Microsoft Graph API is OData, and Microsoft Graph uses OData to talk to each of those other backend services.

So we understand the value of OData for building distributed services, but that colors our investments and prioritization. When we have reviews with management and talk about ongoing investment in the community, we are often asked whom, outside of Microsoft, uses OData. They just don't hear the buzz.

So make some buzz. Submit a PR to add information about your implementation to OData.org. Better yet, write a blog post that we can post on OData.org talking about how you use OData to solve interesting real-world problems. It doesn't have to be a long missive, just something that lets people know "I'm using OData". Then maybe we can build more of a community voice, justify more of a presence at conferences, and understand and prioritize more investments in the stack for the community.

[weitzhandler]

Hi!
Now that .NET Core 3.0 has been released, are there any steps that can be done internally to make it OData work in 3.0 projects? I'm willing to contribute.

[KanishManuja-MS]

@weitzhandler There are workarounds but I don't think those workarounds can be part of product code. What we are considering is going down this path - https://github.com/aspnet/AspNetCore/pull/8955.
If you want to take a shot at it, feel free.

[luckyycode]

the only thing we can't update our project to net core 3.0 is because of OData, we all would be super glad if it will be available as fast as possible ;)

[weitzhandler]

@KanishManuja-MS Thanks a lot for this direction!
Gonna play with it, hopefully I can put something together.

@enchev Since this issue applies to .NET Core 3 in general, could you please update the title?

[hirre]

@mikepizzo We really need OData to work with .NET Core 3.0 and future releases... When it comes to giving it a "buzz", OData is critical in our new server platform. We are the leading supplier of access control systems in the nordic countries.

[alc86]

Is there any workaround to use the current version with .Net Core 3 ?

[obujeiromhginsurance]

In summary waste of time to read all of this

[KrzysztofPajak]

When OData will be available for NET Core 3.0 (estimate time)?

[josalper]

This is crazy, I can't update my project to Net Core 3.0 only for this reason... :(

Please, an estimation date for the compatible release?

[mikepizzo]

I don't have a solid date yet (sorry) but I wanted to update on status --

Based on overwhelming community feedback (thanks!) that this is high on our priority list for implementing this quarter (which started yesterday). We have done an initial investigation and are working with the ASP.NET team to get this functionality delivered as quickly as possible.

More excitingly, this engagement is leading us to jointly look at ways that we can better factor OData functionality into ASP.NET. This has been a frequent request and a long personal goal of being able to "opt in" to OData features (like $filter) in any ASP.NET service.

In the short term, we are exploring two options for unblocking folks wishing to use OData with ASP.NET Core 3.0; one would support the existing OData routing by disabling endpoint routing, the other would support routing through a dynamic controller. The first would be less work from our side, but would require support in ASP.NET Core 3.x and would not work with endpoint routing. The second would potentially take us longer to deliver, but would not require support from ASP.NET Core 3.x and would enable endpoint routing.

Our first step, which we'll start in the next 2 weeks, is to try prototyping the second approach. Based on that investigation we'll have a much better idea of the date. I would love to complete the work this quarter (i.e., by end of year) but until we prototype it we won't know what obstacles we may face.

In the meantime, I would love to get feedback on which the community would prefer:
-A solution that worked with .NET Core 3 (and EF Core 3) and could potentially be released sooner, but did not support endpoint routing, or
-A solution that supported endpoint routing, but would potentially take longer to release

[BenjaminCharlton]

:-D

Hooray!!!

For me, I prefer option 2, especially if it can be completed this year as you suggest it might be.

[hirre]

I think the second option is better for making the lib more future proof. We want to be able to use OData in the future whether it's .NET 5, 6, 7 and so on...

[BuairtRi]

@mikepizzo Thanks for providing an update!

A lot of it depends on the differences in timelines. If we're talking about a matter of a couple of extra weeks, then I'd opt for the method which supported endpoint routing. However, if we're talking the difference between getting something out this quarter or something out in the spring, I'd prefer to just move to .NET Core 3 without endpoint routing, since I'm already stuck on .NET Core 2.2, which doesn't have endpoint routing. A little blog post or very explicit warning to developers about this requirement (with a code sample of how to turn it off) would be appreciated by those who aren't as active on the forums.

And thank you for your suggestion about how to raise the platform of OData. To me, OData is a no-brainer. A lot of my work is building internal dashboard/management portals, and they involve a LOT of list pages with filter conditions at the top. If I had to custom craft a search model/API action, and then manually map that search model to an Entity Framework query with if statements, the way I did in the pre-OData days, it would just be insanely frustrating and time consuming.

I love having OData available so my controllers are very slim, and then I can completely control the query parameters from the client. It makes my apps so much more flexible. Maybe I'm missing something that other API-designers are doing that makes it possible to build reusable, flexible APIs without OData that support sorting and filtering on all of the different data elements, especially with different filter comparison methods (starts with, equals, ends with, greater than). Back in the day when I was building search APIs with search models, this was a ton of manual work.

I'll try and write up a Medium post or something looking at how I integrate Identity Core with OData to build reusable APIs for small to medium business portals, to show community engagement. This is definitely a technology that helps us out in the small business side of the pool, it's not just about massive enterprise data workloads.

[tjrobinson]

@mikepizzo Thanks for the update.

Would option 1 make option 2 not possible at all, or is it just a matter of which you work on first? I think the answer to that would influence people's choices, including those already posted.

I would prefer option 1 in the short-term as we're not using endpoint routing but are currently unable to upgrade the rest of our application to .NET Core 3.0 to advantage of any of the other new features.

[JohnGalt1717]

We don't use any of the routing at all. We simply [EnableQuery] on webapi endpoints and we're done. So if you can simplify it so that that functionality works without having to enable anything else that would be a major win and simplify everything greatly.

Then the rest is gravy.

[mikepizzo]

@BuairtRi -- thanks for the support. Looking forward to seeing that blog post!

@everyoneelse -- thanks for the feedback on options 1 versus 2. I don't know the difference in how long each option would take, but your feedback helps balance the two options. Long term we'll definitely make sure we have something that will continue to grow with .NET n++. This thread has kicked off discussions with ASP.NET team to understand how to do just that.

[mgernand]

I would like to share the experience I made when trying to create a version that runs on ASP.NET Core 3 and the legacy routing system (mentioned by @mikepizzo). The result of this experiment is a working OData service running on ASP.NET Core 3.0. The code can be found in my fork of this repository:
OData-Core3

There are several thing I ran into trying to make this work which are:

1. The enpoint routing must be disabled and the legacy routing must used.
2. The feature AllowSynchronousIO must be diabled as OData still used some synchonous APIs.
3. Newtonsoft.Json needs to be enabled.
4. Some used AspNetCore.Mvc classes were internalized.

The first threepoints can all be solved by configuring the service as needed by OData. The following code in taken from the sample application.

1. Configure MVC and OData like in ASP.NET Core 2+ in Startup.cs

app.UseMvc(builder =>
{
    builder.Select().Expand().Filter().OrderBy().MaxTop(100).Count();
    builder.MapODataServiceRoute("OData", "odata", model);
});

1. Deactive the AllowSynchronousIO feature. Here I disable it via the Kestrel configuration in Program.cs

return Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.ConfigureKestrel(options =>
        {
                    options.AllowSynchronousIO = true;
        });
        webBuilder.UseStartup<Startup>();
    });

1. Enable Newtonsoft.Json by referencing the new legacy package Microsoft.AspNetCore.Mvc.NewtonsoftJson and adding the serializer in the Startup.cs

services.AddControllers(options =>
{
    options.EnableEndpointRouting = false;
})
.AddNewtonsoftJson();

The fouth point ist the major one. To get past this I just borrowed the internalized classes from the Mvc repository. This includes:

• ActionConstraintCache.cs which must be registered as singleton in the AddOData method:

services.AddSingleton<ActionConstraintCache>();

• ActionSelector.cs
• ActionSelectionTable.cs
• StringArrayComparer.cs
• MvcCoreLoggerExtensions.cs

To make the unit test run I needed to include the following classed from Http and Mvc projects:

• DefaultHttpRequest.cs
• FormOptions.cs
• MvcRouteHandler.cs

After that, the service is executed and the example generates meaningful outputs.

To fix the over 1000 failing unit tests (still 21 at the moment) I had to modify the TestServerFactory class according to the points mentioned above.

Most of the failing unit tests were made because .NET Core 3 changed the default text of the ArgumentException. In .NET Core 2+ the appended text was: "\r\nParameter name: {parameterName}" and in .NET Core 3 it was changed to " (Parameter '{parameterName}')". I added a helper class (ParamHelper) for that, maybe it's useful, maybe not. ;-)

That was my little journey with OData and .NET Core 3 today. I hope the infomation is useful to someone.

Note: Keep in mind that this was just an experiment. Nothing I would use in production!

[BuairtRi]

Oh, my @mgernand! Thanks for that!

[luckyycode]

Meh we just gotta make own OData version lol

[weitzhandler]

@mikepizzo thank you so much for tuning in!
If option 2 would take significantly longer to implement I'd want to go with option 1.

But I guess this will also have impact on the development of RESTier, which I'm also looking at, though I'm still not familiar with its internals, so would pick an option depending on how it will delay/speed up the support of RESTier for .NET Core and .NET Core 3 and on, which is definitely the final result I'd want.

^{_{BTW, I wonder why Microsoft, since RIA Services was killed, and now after the sunset of WCF, doesn't dedicate the resources to finally boost OData which is by any means the best replacement (GraphQL doesn't get anywhere near OData IMHO).
Related https://github.com/OData/odata.net/issues/1508.}}

[vladimirstemberk]

@mgernand
In your AspNetCore3ODataSample.Web in startup.cs you have no ActionConstraintCache as singleton, but it seems its working anyway..

[mgernand]

@mgernand
In your AspNetCore3ODataSample.Web in startup.cs you have no ActionConstraintCache as singleton, but it seems its working anyway..

@vladimirstemberk I added the singleton in the AddODataextension method not in the Startup.cs. Have a look at ODataServiceCollectionExtensions.cs.

[Danielku15]

@mikepizzo If I need to choose I would vote for option 2, longer but more sustainable. If I could propose the path I would say: start from scratch on a .net core 3 only version and deprecate the current one. Drop the old-style ASP.net support completely and focus on using only new ASP.net core features. I saw a lot of technical dept in the codebase by trying to support both worlds. You always need to choose the lowest common featureset or build strange abstraction layers which cost performance and maintenance.

The future path of ASP.net is clear. Desktop .net Framework is dead, ASP.net is dead. ASP.net core and .net (core) are the future. On the .net conf it was clearly stated: take the next year to migrate to .net core to be ready for .net 5. The ASP.net core team already made quite a clear statement with not targeting the .net standard but only targeting .net core 3.0.

[btull89]

Option 2 gets my vote.

[JohanOtto]

I don't have a solid date yet (sorry) but I wanted to update on status --

Based on overwhelming community feedback (thanks!) that this is high on our priority list for implementing this quarter (which started yesterday). We have done an initial investigation and are working with the ASP.NET team to get this functionality delivered as quickly as possible.

More excitingly, this engagement is leading us to jointly look at ways that we can better factor OData functionality into ASP.NET. This has been a frequent request and a long personal goal of being able to "opt in" to OData features (like $filter) in any ASP.NET service.

In the short term, we are exploring two options for unblocking folks wishing to use OData with ASP.NET Core 3.0; one would support the existing OData routing by disabling endpoint routing, the other would support routing through a dynamic controller. The first would be less work from our side, but would require support in ASP.NET Core 3.x and would not work with endpoint routing. The second would potentially take us longer to deliver, but would not require support from ASP.NET Core 3.x and would enable endpoint routing.

Our first step, which we'll start in the next 2 weeks, is to try prototyping the second approach. Based on that investigation we'll have a much better idea of the date. I would love to complete the work this quarter (i.e., by end of year) but until we prototype it we won't know what obstacles we may face.

In the meantime, I would love to get feedback on which the community would prefer:
-A solution that worked with .NET Core 3 (and EF Core 3) and could potentially be released sooner, but did not support endpoint routing, or
-A solution that supported endpoint routing, but would potentially take longer to release

My workaround is splitting my OData from the rest of the app with some middleware on the netcoreapp3 main app to relay the requests securely and lock it down. Once you released an initial update I can change the OData net46 asp core app to be a class library targeting netstandard1.1 and add the assembly as a area and .AddControllersAsServices - remove the middleware. Lets get rolling!

    .SetCompatibilityVersion(CompatibilityVersion.Latest) // Waiting for OData
                ;//.AddApplicationPart(typeof(MyODataController).Assembly)
                 //.AddControllersAsServices();

[NetTecture]

I wish i could do that, but it would lead to the fact that I would have to implement a protocol between the odata layer and the backend that exposes all of odata -basically doing odata myself. Total non issue. Mixing with EfCore 3.0 is ALSO not possible due to netcoreapp 2.2 not supporting netstandard 2.1 - dead end. So, I can simply not split the API. Not sure how ou guys do it - what the heck do you use as communciation protocol to the backend that exposes all the advanced features of odata?

We need a proper full modern implementation of odata - one that uses endpoint routing asap, because without endpoint outing then the question is how the he** we are supposed to use versioning and the api explorer (needed for swagger intration).

On the positive side, I remember the dude from api versioning saying he had a look at the code and the new endpoint routing looks a lot like what odata does internally. If we have a dynamic controller approach, we loose possibly a lot of functionality from the endpoint routing side - and I would at least mid term really love to have a CLEAN approach. One that follows the asp.net standards.

[DerAlbertCom]

Option 2 must be the final goal. BUT ASP.NET Core 2.2 Support is running out soon. So having the possibility to Update to 3.0/3.1 soon would be nice. So if Option 2 takes longer then the End of Core 2.2 Support then go for Option 1 and Option2 later.

[RamjotSingh]

@mikepizzo I am glad to know that OData team is considering fundamental rewrites to the SDK. Having contributed to the codebase I can agree the SDK has grown too complex (partially due to code being shared being MVC5 and 6) and can definitely benefit from a large scale rewrite to align better with the NetCoreNetStandard vision.

That being said, if there is enough zeal to take up that project, I would suggest a small improvement. Can you split the serializationdeserialization process from it's dependence on HttpRequest and Response parts. I have probably spent 10-15 hours on figuring to tear those things apart using shimmed implementations, mocking things out and the solution which did work is very brittle.

There are cases where OData serializationdeserialization needs to run in scenarios where the controller itself is not OData (imagine outgoing notifications where incoming payload is just generic non-OData endpoint).

While we are on the topic, Option 2 gets my vote as well. Turning EndpointRouting off would be a step back from all the performance stuff being built by .Net. That being said, if Option 2 is more than 2 quarters away, maybe an intermittent Option 1 is needed.

[jamie-tillman]

After some internal conflict, I've decided to leave a note here documenting something that might be useful to this team. Please take it in the spirit of critique, rather than whining.

I was looking to use oData in a new DotNetCore API I'm building. I have to make a choice between oData and GraphQL. oData seems like far less work and more flexible, but I am going with GraphQL specifically because of this thread. You had nearly a year's notice about this problem, and you didn't even start making an effort until a few days ago. I realize this is a community-supported project and work on several of them myself, but I can't invest time in a project that lets the technology get away from them like this, no matter how much more work the alternative is.

I sincerely hope to check back in sometime in the future to find this lack of preparation has been somehow addressed by the community. I wish you the best of luck.

[JohanOtto]

I wish i could do that, but it would lead to the fact that I would have to implement a protocol between the odata layer and the backend that exposes all of odata -basically doing odata myself. Total non issue. Mixing with EfCore 3.0 is ALSO not possible due to netcoreapp 2.2 not supporting netstandard 2.1 - dead end. So, I can simply not split the API. Not sure how ou guys do it - what the heck do you use as communciation protocol to the backend that exposes all the advanced features of odata?

We need a proper full modern implementation of odata - one that uses endpoint routing asap, because without endpoint outing then the question is how the he** we are supposed to use versioning and the api explorer (needed for swagger intration).

On the positive side, I remember the dude from api versioning saying he had a look at the code and the new endpoint routing looks a lot like what odata does internally. If we have a dynamic controller approach, we loose possibly a lot of functionality from the endpoint routing side - and I would at least mid term really love to have a CLEAN approach. One that follows the asp.net standards.
Something like this?

internal class ODataProxyMiddleware
    {
        readonly string _baseUrl;
        readonly RequestDelegate _next;
        //static HttpClient httpClient;   
        static readonly ConcurrentDictionary<string, HttpClient> _clients = new ConcurrentDictionary<string, HttpClient>();

        public ODataProxyMiddleware(RequestDelegate next, IConfiguration config )
        {
            _next = next;
            _baseUrl = config.GetSection("ODataProxy")["BaseUrl"];

            if (string.IsNullOrEmpty(_baseUrl))
                throw new CoreException("There is no configuration for ODataProxy.BaseUrl");
        }

        public async Task Invoke(HttpContext context, UserManager<IdentityUser> userManager)
        {
            var endRequest = false;
            if (context.Request.Path.Value.StartsWith("/odata", StringComparison.OrdinalIgnoreCase))
            { 
                await ProxyAsync(context, userManager);
                //await StreamAsync(context, url);
                endRequest = true;                
            }
            if (!endRequest)
            {
                await _next(context);
            }
        }

        async Task ProxyAsync(HttpContext context, UserManager<IdentityUser> userManager)
        {
            var usr = await userManager.GetUserAsync(context.User);

            var url = _baseUrl + context.Request.Path;
            var client = GetHttpClient(usr);
            try
            {
                HttpRequestMessage request = new HttpRequestMessage(
                    new HttpMethod(context.Request.Method), url);

                HttpResponseMessage response;
                switch (request.Method.Method.ToUpper())
                {
                    case "GET":
                        response = await client.SendAsync(request,
                          // this ResponseHeadersRead force the SendAsync to return
                          // as soon as the header is ready, faster
                          HttpCompletionOption.ResponseHeadersRead);
                        break;
                    case "PUT":
                        response = await client.PutAsync(request.RequestUri, new StreamContent(context.Request.Body));                        
                        break;
                    case "PATCH":
                        response = await client.PatchAsync(request.RequestUri, new StreamContent(context.Request.Body));
                        break;
                    default:
                        response = await client.PostAsync(request.RequestUri, new StreamContent(context.Request.Body));
                        break;
                }
                context.Response.StatusCode = (int)response.StatusCode;
                if (context.Response.StatusCode != 204)
                {
                    await context.Response.WriteAsync(await response.Content.ReadAsStringAsync());
                }
                //context.Response.StatusCode = (int)response.StatusCode;
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex);

            }

        }

        HttpClient GetHttpClient(IdentityUser usr)
        {
            _clients.TryGetValue(usr.Id, out HttpClient client);
            if (client == null)
            {
                client = new HttpClient(
                    new HttpClientHandler()
                    {
                        UseProxy = false,
                        Proxy = null,
                        UseDefaultCredentials = true
                    })
                {
                    BaseAddress = new Uri(_baseUrl)
                };
                client.DefaultRequestHeaders.Add("ProxyUserId", usr.Id);
                _clients.TryAdd(usr.Id, client);
            }
            return client;
        }


    }

And in for fluff

public static class ApplicationBuilderExtensions
    {
        public static IApplicationBuilder UseODataProxy(this IApplicationBuilder app)
        {
            //return app.Use(next => new ODataProxyMiddleware(next, baseUrl).Invoke);
            return app.UseMiddleware<ODataProxyMiddleware>();
        }        
    }

[cilerler]

I'm frustrated by uncertainty on OData. OData is a significant part of my life, how it can not support .NET CORE 3? If we already build projects on top of OData, how can we move further?

I appreciate what you guys doing, and support you from the bottom of my heart, however, forcing our hand to "wait" without a time-frame is killing me. Major things should move together. Please be more transparent and have a plan for the releases.

I don't mean to disrespect the efforts you are doing; I'm just asking for more controlled rapid releases. Thanks again.

[mikepizzo]

@jamie-tillman, @cilerler and others -- We really do understand, and I wish I could pull a few all-nighters and get this working. The reality, though, is that we are very closely tied to how ASP.NET does routing, and .NET Core 3.0 radically changed how routing is done which makes it non-trivial to get this working (especially if we have to mantain existing codebases for .NET Core 2 and .NET Classic).

We're trying to juggle demands across the OData libraries, addressing both internal and external requirements. We verified the Core OData libraries with .NET Core 3, but the .NET Core 3 work in the WebAPI OData library took a back seat to some other critical feature and parity work over the past few months (we were hoping that disabling endpoint routing would buy us a bit of time, but that was disabled in the final beta).

As I mentioned above, this is a high priority item for us to fix this quarter. The good news is that we are getting more resources onboarded to the OData team, but don't we expect them to be up to speed in time to help with this task. Longer term we are looking for ways to better partner with the ASP.NET team so that OData features are better factored into the core features and easier to keep in sync.

All of which, I know, doesn't help you today, but know we are taking your feedback to heart.

[jccdev]

After some internal conflict, I've decided to leave a note here documenting something that might be useful to this team. Please take it in the spirit of critique, rather than whining.

I was looking to use oData in a new DotNetCore API I'm building. I have to make a choice between oData and GraphQL. oData seems like far less work and more flexible, but I am going with GraphQL specifically because of this thread. You had nearly a year's notice about this problem, and you didn't even start making an effort until a few days ago. I realize this is a community-supported project and work on several of them myself, but I can't invest time in a project that lets the technology get away from them like this, no matter how much more work the alternative is.

I sincerely hope to check back in sometime in the future to find this lack of preparation has been somehow addressed by the community. I wish you the best of luck.

I would warn you graphql is not like odata at all. I tried using it in a similar way as odata and the functionality it just not there. Its just a query specification that you have to manually implement yourself.

[jamie-tillman]

I would warn you graphql is not like odata at all. I tried using it in a
similar way as odata and the functionality it just not there. Its just a
query specification that you have to manually implement yourself.

I had gathered that, and oData was my preference. HotChocolate is a
project that appears to get close to a low-code implementation if one is
using EntityFramework. Their use of IQueryable to automatically generate a
graphql schema (complete with paging, sorting, and filtering) is pretty
good. Granted, there is definitely more work involved than with oData, but
so far it seems like it might be ok.

I should add that I'm only doing query implementation with these technologies anyway. Mutations are being performed through another channel.

[cilerler]

• this is a high priority item for us to fix this quarter.
• The good news is that we are getting more resources onboarded to the OData team.
• Longer term we are looking for ways to better partner with the ASP.NET team so that OData features are better factored into the core features and easier to keep in sync.

@mikepizzo, I appreciate the time you took and provide a detailed explanation. The paragraph above gave me great hope. It looks like the future is bright, thanks again. 🤗

[ItielBeeri]

I vote for option 2 too.
Last quarter we started the development of a quite big enterprise system, which its main API is based on oData + EF Core. Currently, we use version 2.2, and in consideration of the big changes done in version 3, especially in EF Core, we don't plan to upgrade at least until the release of the more stable version of 3.1 in November. When it will be released, we will obviously require a version of oData that supports it. Once the main bundle of .net core 3.1 is released we could wait a few more weeks for a future-proof version of oData, and I hope that this time frame would be sufficient to supply an implementation of option 2.

[weitzhandler]

What's encouraging, and should also be encouraging for Microsoft to dedicate resources to the OData team, is that it looks like quite an amount of people use OData.

[NetTecture]

It is. In part because it actually gets the job done - while other attempts to standardize REST are half. At best. There are a ton of rough edges around odata (less with 4.01 that FINALLY added an IN clause) and the implementation of some features is complex (to be nice), but it acutally does an amazing work on providing a cross platform language between the most important layers in a tiered application (i.e. out to the "public" so you can i.e. use Excel to access corporate data). Kudos to whoever had that amazing idea. I have considered abandoning odata repeatedly - but there is no alternative. Not if you look for more than "have website, need to access rest, somehow", but want proper control for search results, proper tooling - heck, anyone who ever worked with someone even remotely related to management will know how those people SWEAR around excel).

I am a hugh fan - and I hope that once a streamlining of the odata project is over, a lot of energy can be put into making it easier to use and moving forward with the standard. We are just rolling out a major odata upgrade for a core technology for a well known german company asap - likely in two month, though until I resolve the workaround I have now for the EfCore bugs (which I solve by loading all data into memory that a user can see) performance is an issue. OData is a major element there to allow users to use alternative standardized tools and likely will replace the whole reporting side of the system in short order.

[tfabian]

DLL hell....

[russharding]

Throwing my hat into this. I'm working on a project to migrate from .NET to .NET Core and the project uses OData enough that backing out is a non-starter right now. Downgrading to .NET Core 2.2 is also off the table because of the extensive use of EntityFramework, which requires us to be at 6.3/.NET Core 3.0.

Getting this fixed is a high priority for our project. If we have a fix in the .NET Core 3.1 timeframe, that would be ideal. Even a preview in that time frame would work if a final version needs a bit more time to fully bake.

[tfabian]

Here is the long story: I changed our common web service dll to target .net core 3. Everything successfully compiled. It was very suspicious for me, and I found out that Microsoft architects invented a new kind of dll hell. It will be called multitargeting dll hell.
I ported my brand new .net core 3 web api to use .Net Framework Microsoft.AspNet.OData. The correct package name is Microsoft.AspNetCore.OData, ups.
Let's build it.... 346 compilation errors....
Missing/renamed/moved interfaces/namespaces/extension methods/classes/properties etc. related to Microsoft.AspNet* and Microsoft.OData*. No documentation about breaking changes.... So I decided to build our brand new ASP NET CORE OData WEB API from scratch. AddMVC ... MapODataServiceRoute, Start debugging.... crash:
Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0
Then I found this thread from January.
Even you MS guys are not able to upgrade your OData due to these bad decisions (breaking changes and dll hell).
When I reported a bug to RX team, they released a new version within 2 days!

Regards, Tomas Fabian

[aderderian]

Hoping to get this supported as well.

[emouawad]

Any timeline update on this? even a nightly would do!
Anyone found a workaround?

[alc86]

Are you planning to fully integrate odata into asp.net core 3.0 (routing, API explorer, etc.)?
We would like to take advantage of the IApplicationModelConvention and IControllerModelConvention interfaces. Our goal is to use swashbuckle with the default configuration (default API explorer of asp.net core 3.0). Currently odata controllers were not recognized by the API explorer.

[wusanwa]

如果你们需要的话我做了一个支持 .Net Core 3.0的版本https://gitee.com/wusanwa/WebApi.git
I've made a version that supports. Net core 3.0 if you need it.https://gitee.com/wusanwa/WebApi.git

[wusanwa]

如果你们需要的话我做了一个支持 .Net Core 3.0的版本https://gitee.com/wusanwa/WebApi.git
I've made a version that supports. Net core 3.0 if you need it.https://gitee.com/wusanwa/WebApi.git

github : https://github.com/WuyanLee/WebApi.git

[SiberaIndustries]

I guess you are talking about this branch? https://github.com/WuyanLee/WebApi/tree/aspnetcore3
I will try :)

[tfabian]

I am trying @WuyanLee's solution, but it doesn't return any data.
GET http://localhost:63580/efcore/Movies
HttpStatus is 200 Ok, but the data is not in the response.

In my case http://localhost:63580/efcore/$metadata is also empty

[mgernand]

@emouawad @SiberaIndustries @tfabian
Try what I described here: https://github.com/OData/WebApi/issues/1748#issuecomment-537551659
My fork; OData-Core3

I had problems running the experiment in IIS Express, but running self-hosted with Kestrel works.

@WuyanLee
There are some more tweaks you have to do to make things work. See links above.

[wusanwa]

@tfabian @mgernand @SiberaIndustries
Thanks!
"IIS Express"无法工作的原因是没有正确的配置"AllowSynchronousIO",抱歉我忘了添加
"IIS express" can't work because "AllowSynchronousIO" is not configured correctly. I'm sorry I forgot to add it.

你可以使用下面的方法添加
You can use the following methods to add
services.Configure<IISServerOptions>(options => { options.AllowSynchronousIO = true; });

[alc86]

Are you planning to fully integrate odata into asp.net core 3.0 (routing, API explorer, etc.)?
We would like to take advantage of the IApplicationModelConvention and IControllerModelConvention interfaces. Our goal is to use swashbuckle with the default configuration (default API explorer of asp.net core 3.0). Currently odata controllers were not recognized by the API explorer.

[tfabian]

Hi,
@mgernand @WuyanLee Get is working in both solutions, but Post contains only default values. For example a string Name property is null. I'm testing it with a working .net framework client app. Did you try to Post some value? Put seems that doesnt work at all. Delete is ok.

thx Tomas

[mgernand]

@tfabian
I just tried POSTing and it works as intended. Maybe you forgot to add the [FromBody] attribute to the model parameter. I added a Post-Method in the MoviesControllerif you want to have a look at it.

[keatkeat87]

I will vote Option 2.
does the the decision come out, option 1 or 2 will be make ?
will this publish end of this year ?

[tfabian]

@tfabian
I just tried POSTing and it works as intended. Maybe you forgot to add the [FromBody] attribute to the model parameter. I added a Post-Method in the MoviesControllerif you want to have a look at it.

@mgernard I'm converting a Katana web api to Kestrel. In .NET Framework 4.7.2 Microsoft.AspNet.OData 7.6.0 Post-Method does not require the [FromBody] attribute, so it is another breaking change I found out :( . It's obviously not based on convention anymore in Microsoft.AspNetCore.OData.

Thx for your branch, it helps me with the whole migration.

[shahriarhossain]

I've tried with .NET Core 3.0.100 . But still having the same issue. Any update on this?

[KrzysztofPajak]

According from information with Hassan Habib (Sr. Software Engineer, Microsoft) - OData will be available on the 2nd Quarter of 2020 - https://devblogs.microsoft.com/odata/optimizing-web-applications-with-odata-select/

[cilerler]

@KrzysztofPajak according to @mikepizzo we will have a release by the end of 2019

[NetTecture]

Maybe @mikepizzo can give up an update on the current progress?

[cilerler]

@NetTecture give him a breathing room, he is continuously get bombarded with this question, and I bet he is doing his best to lay it to the team. He is well aware of the situation and has a great understanding of the pain we have. So let's have a little bit of patience, we will get there pretty soon. The info I have is from last week's RESTier community standup.

[mikepizzo]

Not much new to report; we are working on the second option (full support for endpoint routing) and it is one of the highest prioritized features for this quarter (next to completing some work that was already underway around supporting $select options, and onboarding new team members). In the meantime, it's been great to see the community support, including what appears to be a short term solution here or here. Note that we have not reviewed these solutions so you should determine whether or not appropriate for your use, but it's great to have folks working to make these solutions available.

[mikepizzo]

I suspect Hassan was referring to 2nd Quarter of Fiscal 2020, which is the current quarter that ends December 31, 2019.

From: Krzysztof Pajak [e-mail]
Sent: Monday, October 28, 2019 7:04 AM
To: OData/WebApi [e-mail]
Cc: Michael Pizzo [e-mail]; Mention [e-mail]
Subject: Re: [OData/WebApi] .NET Core 3.0 support? (#1748)

According from information with Hassan Habib (Sr. Software Engineer, Microsoft) - OData will be available on the 2nd Quarter of 2020 - https://devblogs.microsoft.com/odata/optimizing-web-applications-with-odata-select/https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevblogs.microsoft.com%2Fodata%2Foptimizing-web-applications-with-odata-select%2F&data=02%7C01%7Cmikep%40microsoft.com%7C683ada7ac1524f31e24308d75bafb592%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078682537110628&sdata=VWpxnEfyl%2FbZ0I%2FnF4snP43uenIIE6jWrZ%2BbI3%2FWtxs%3D&reserved=0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOData%2FWebApi%2Fissues%2F1748%3Femail_source%3Dnotifications%26email_token%3DACCCOXRQU3LTTZDXQABQAILQQ3WNVA5CNFSM4GTKE362YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECM7MXQ%23issuecomment-546960990&data=02%7C01%7Cmikep%40microsoft.com%7C683ada7ac1524f31e24308d75bafb592%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078682537120587&sdata=N6bD6JcpO8rVwsJF3CIuJR5gUHao5J4QJYqqeBDAypg%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACCCOXXVCRKFUGO2UOTXHP3QQ3WNVANCNFSM4GTKE36Q&data=02%7C01%7Cmikep%40microsoft.com%7C683ada7ac1524f31e24308d75bafb592%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078682537120587&sdata=L7EGyqV9TC7p6uAxST3V8YA6xBeJhg652JvVvuhnnEQ%3D&reserved=0.

[Zzarek]

@mikepizzo Hi Mike, thanks for prioritizing this. I'm yet another person stuck on the upgrade. I just wanted to clarify option2 does not include support for option1, correct? So I will not be able to use EnableEndpointRouting = false?

I can live with it (despite my problem, i also would have voted option 2), but id like verification. I have a separate library that opted to go with option one, so temporarily im forced into EnableEndpointRouting = false for one of my APIs.

[mikepizzo]

@Zzarek; As I understand it, EnableEndpointRouting=false was a stop-gap solution that is not fully supported in the release version of .NET Core and planned to be deprecated/removed in the future, so I think our efforts would go into fully supporting endpoint routing and not include EnableEndpointRouting=false.

[Zzarek]

I completely agree with that priority @mikepizzo , and i had the same understanding. I was just confirming it wouldn't be a byproduct of your effort.

[commonsensesoftware]

This is good news. I think we're all anxious for this to become available.

As someone that is deeply familiar with the internal mechanics of how routing works
and is implemented in the Microsoft OData stacks, I would like to provide the following
guiding principles when designing and implementing _Endpoint Routing_.

• Consider, but don't limit yourself to the OData routing mechanics of old
  
  
  
  • This has stymied taking advantage of improvements in newer routing systems
  
  
  • Ease of adoption by developers upgrading is a great objective, but - in general - we can live with breaking changes on a major upgrade
  
  
• Don't assume or enforce that an OData request must match exactly one route
  
  
  
  • The ASP.NET routing system already handles this and returns an appropriate 500 response indicating a developer mistake
  
  
  • The _one route_ match policy makes it difficult for framework extenders (API Versioning was an influencer to the new _Matcher Policy_ design)
  
  
  • API Versioning has historically had to fork or replace a significant portion of the OData routing infrastructure because it's closed or makes too many assumptions
    
    
    
    
    
    • API Versioning itself doesn't alter routing, it merely disambiguates duplicate route matches by an API version discriminator
    
    
    
  
  
• Generate or otherwise build the OData templates ahead of time
  
  
  
  • This makes the rest of the _Endpoint Routing_ pipeline really straight forward
  
  
  • Performance should be improved as all of the route templates are known upfront (as opposed to going through OData-specific convention code on every request)
  
  
  • The API Explorer becomes generally available to OData controllers
  
  
  • While it's currently specific to API Versioning, much of the foundation doesn't have to be. You can see and get a sense of how this _could_ be done in OData here, here, and here based on how it's achieved in API Versioning's API Explorer support for OData
  
  
  • Attribute routing in OData isn't really _Attribute Routing_, but it could be
  
  
  • Yes - this will likely break or supplant the old OData convention approach, but there is probably a way to retain or other otherwise hook that in with a route constraint. In practice, I've found and seen very little need for custom OData conventions; however, they do exist.
  
  

There's some food for thought. Take it as you will. Happy to meet with the team again to discuss further.

[Danielku15]

@commonsensesoftware

Performance should be improved as all of the route templates are known upfront (as opposed to going through OData-specific convention code on every request)

One small extension to this. It must be considered that the IEdmModel might be dynamic and not static. In our case we have per tenant an own model generated with user defined entities. The EDM is generated on-the-fly, cached, and then provided as scoped dependency. But in the end you are right, also in our case it is still clear which route ends up at which controller as user defined entities all end up at a common controller via custom routing convention.

[NetTecture]

@commonsensesoftware How can EdmModel be dynamic? One model per tenant is still a static model per tenant.

I am way more concerned about the intricacies how OData allows for thigns like casts in the URL - the amount of valid URL's - if you prebuild them - will get BRTUALLY high extremely fast, particualrly with casts (as) in part of the URL as additional entries. You may end up with 20+ URL#s for one navigation property, with one being the default (and the others should not be in api explorer normally).

[Danielku15]

@NetTecture

How can EdmModel be dynamic? One model per tenant is still a static model per tenant

We have this in place by allowing the customer do define additional custom properties and entities during runtime by configuration (also via API). This is quite common in ERP systems, but also other pieces of software like forums, wikis, project management systems allow the operator to define new fields and items during runtime. We develop a multi-tenant app with database-per-tenant.

In our case the API layer is always strictly typed and showing the final models as per customer configuration in a strict static fashion. We do not use open types as they're too loose and have poor framework support.

Hope this gives some good insight 😉

[commonsensesoftware]

@NetTecture you're right that you would not want nor need to build _every_ possible URL combination. You need the core route templates and the rest would come from a request. I'm not sure it would make sense to have route templates with the cast in it already. At least to me, I think of the cast operator as more of a route parameter that the client must specify. I rarely use cast so maybe I'm missing something.

@Danielku15 a _dynamic_ EDM will come with some consequences, but it should be possible. Not all aspects of an EDM affect routing. ASP.NET Core does have a facility to notify the platform that the available actions have changed. API Versioning uses this technique for OData because it doesn't know how many times you may have called MapVersionedODataRoute, MapVersionedODataRoutes, or a combination thereof and it needs to know the combination of all routes, versions, and their containers that have been registered. You wouldn't want to regenerate the EDMs on every request, but if you had a way to signal it, you could subsequently indicate that the available OData actions have changed and they would be rebuilt, including their route templates. There's some devil in the details, but that's conceptually how it could work.

[MasiumDev]

in .Net Core 2.2, I used app.UseMvc and set
routes.EnableDependencyInjection();
routes.Select().Filter().Expand().MaxTop(null).OrderBy().Count();
through IRoutingBuilder extension methods.
Now, in .Net Core 3.0, when I use app.UseEndpoints, how can I do this for injecting ODataQueryOptions?
In other words, how to enable OData components on non-OData routes in .net core 3.0 Endpoints?

[jayoungers]

I'm also trying to get this setup in a new dotnet core 3.0 project: for my use case all I really need is ODataQueryOptions<TEntity> and its ApplyTo method (my business logic only requires an Expression).

Is there a slimmed down package I should be using? I feel like there's a massive amount of setup going on that's not needed for what I'm looking to do (parse odata parameters into an expression given an entity type).

[hairlesshobo]

I'm also trying to get this setup in a new dotnet core 3.0 project: for my use case all I really need is ODataQueryOptions<TEntity> and its ApplyTo method (my business logic only requires an Expression).

Is there a slimmed down package I should be using? I feel like there's a massive amount of setup going on that's not needed for what I'm looking to do (parse odata parameters into an expression given an entity type).

Please let me know if you find anything that satisfies this requirement! This is my exact use case as well, I just need to parse the oData params and get an Expression from it.

[jannikbuschke]

interesting, I would actually also like to see something like this. I feel like the odata querying part is super useful and easy to use, whereas the command part is a bit overengineered and does not meet my requirements often (its more pain than joy to use). Thats why I started to use odata only for my read model, whereas my write models are implemented with webapi + mediator.
Slimmed/core packages that do not depend on any specific webapi layer would be usefull. I feel applying odata querying parameters to expression is the key feature

[mikepizzo]

Update on this; good news and bad. We've been working with the .NET Core Team, and the solution we were planning on using for plugging OData routing logic into endpoint routing uses a DynamicTransformer mechanism designed for custom routing logic. Unfortunately, this mechanism doesn't support everything that we need in order to do OData routing (in particular, the DynamicTransformer returns a controller and an action name, but our routing supports multiple action overloads with the same name, so simply returning the name is not sufficient.) The .NET Core team was able to come up with a workaround, but it's more than slightly hacky, and relies on routes being evaluated in a particular order which is an anti-pattern for scalability reasons. So we now understand what is required from the .NET Core team, and they have it on their radar -- unfortunately the earliest they'll be able to deliver the functionality is .NET 5. In the meantime, we have figured out what looks like a pretty reasonable solution with endpoint routing disabled, that doesn't require copying a bunch of (now) internal ASP.NET Core classes, and doesn't seem to require any additional changes from .NET Core. So, in order to get a solution out by the end of the year, we will likely have to fall back to an interim solution that doesn't use endpoint routing, and deliver full support for endpoint routing in the .NET 5 timeframe. Not ideal, but at this point that looks to be the cleanest and quickest way that we can unblock folks wanting to use OData with .NET Core 3.0.

[NetTecture]

Damn, that is not nice. .NET 5.0 timeframe is brutal - according to https://devblogs.microsoft.com/dotnet/introducing-net-5/ taht targets November 2020, so a year from now. I hope your workaround works nice and I also hope someone manages an API Explorer integration (please keep that in mind, make sure all the routes can be asked for on the outside) to integrate with Swashbuckle.

Looking forward to see how this works out. Any idea when there will be some sort of experimental branch or build so we can look at that you guys come up with?

[jayoungers]

Hey @mikepizzo - any thoughts on the direction those of us that use the library strictly for parsing the odata parameters to an expression should be taking?

I know there are a few hacky examples out there of manually creating an EDM and using the uri parse class to build an expression, but I wasn't sure if the library was layered in such a way that something similar could be done without building the EDM.

[weitzhandler]

@mikepizzo

Thanks for the update. That is great news. We could live without the endpoint routing so long it works with .NET Core 3.
I wish OData gets back the flashlights, because it's so much more powerful than GraphQL, also in the client-side option choice.

And BTW, if any MS official is reading my message, I'm hoping that more resources whould be given also to the client side OData management, such as to Simple.OData.Client which is a bit abandoned.

[gordon-matt]

It's good news that a workaround will be available soon. However, is there any chance that from .NET 5 onwards that OData can become a "first-class citizen" in .NET? It always seems to be an after thought, which is very puzzling considering just how useful OData really is. One would think that by now it should be a part of the default MVC setup or at least very easily enabled without all this trouble. Basically: please tell me that once it's sorted for .NET 5, that we won't see this same issue for .NET 6 and so on... Of course I know there are no guarantees, but it would be nice if your team and the .NET Core Team were collaborating long before the release of each version of .NET going forward so that OData will be supported from day 1.

[mikepizzo]

Absolutely. The silver lining to this cloud is that the OData and ASP.NET teams are more engaged and we are looking not just at how to support endpoint routing, and not just making sure that future versions of .NET don't break OData, but we are looking at how we can better factor/integrate the OData functionality into ASP.NET so you can do things like opt into individual pieces, for example, supporting $filter over any controller/action in a much more seamless manner without depending on OData routing and serialization.

Regarding timing of having something you can start experimenting with, if the solution from the .NET Core team is as straightforward as it appears, I would hope to have an early version around the end of the month.

[commonsensesoftware]

@mikepizzo This is great news and certainly in the right direction, even if we have to wait for a bit. The concept of _Dynamic_ concerns me though. What is actually dynamic? Without the full details and context, I suspect this may have limitations to things like API exploration for tools like Swagger/OpenAPI. None of the current OData APIs support URL generation based on user-defined route templates and/or well-known OData conventions. Yes - you can build an OData URL if you provide all the constituent pieces yourself, but that's not the same thing. I'm convinced that most, if not all, OData URLs can be built ahead of time, even the so-called _dynamic_ URLs; for example, an action mapped to $ref. There's nothing wrong with mapping multiple templates to the same action descriptor. The only gap I can think of is possibly custom OData conventions, but there are likely other, better ways to handle those edge cases.

I may be missing some details or challenges, but I definitely think it's important to include support for qualified OData route templates in a deterministic manner. Simply supporting routing is just part of the story. Being able to access the known OData routes should be something that is intrinsically supported. At least for API Versioning, considerable work was required to build these templates to support route matching and API exploration, when it is something that is better suited to be provided and owned by the OData libraries - IMO. Any customer wanting to enable API documentation will find that useful, versioning or no. I'm happy to open and link a new issue if you think it's better suited or should be tracked separately. I mostly just want to stress that the forthcoming routing design changes should consider and provide this capability. If that still means things are _dynamic_, then so be it.

[aderderian]

I am for anything that gets it up and working even with non dynamic routing. Currently I have to keep all my Data and Common classes at Core 2.1 because that is the last version where ODATA works. Can you confirm we will get a working version in December, just no endpoint routing?

[NetTecture]

@commonsensesoftware I think the problem with dynamic is that it makes NO SENSE to actualyl generate a static list of all variants of URL's - a tool like Swagger and an explorer should give you a basic overview of what is in the API (similar and based on $metadata) but should NOT interfere with the dynamic additions.

What am I talking about?

• URL's that only return one property
• URL's that limit queries in navigations to other properties to a specific Type

Basically - generate the base URL's and then it is up to the tools. Otherwise a simple EntitySet with an enitty with 10 properites and 5 navigation properties will have WAY MORE than 20 different URL's mostly because of the possibly dynamic parts.

As a user, Ido not want t obother with this (i.e. I do not want to geenerate hardcoded Routes for every version) and in the API explorer you would go bonkers if you would not only see the entity set, but also every single URL for accessing a single property and going to navigation properties buy only as specific type etc. It would overload the whole system.

[commonsensesoftware]

@NetTecture fair, but I wouldn't really call that _dynamic_. You have a route template with a parameter for the property name (e.g. orders/{navigationProperty}). Ultimately, the mapping is what the EDM says unless you get into truly _dynamic_, _loosey-goosey_ open types. I'm totally onboard with opting out of the behavior. There's likely even multiple ways it might be done. For example, opting out of exploration would simply require adding [ApiExplorerSettings(IgnoreApi = true)]. Today, everything is opted out. Furthermore, OpenAPI documents support enumerations. This type of route can be modeled as a single route template where the parameter _may_ be provided by a distinct set of values (e.g. enumeration) from the EDM type. This would result in a single route with many possible values for a single parameter (hence, you don't go _bonkers_ :smile:) For open types, this may be even be _any_ name you want. I'm not attempting to pigeonhole everything to one particular facet. Perhaps a routable OData template and a _logic_ OData template are needed to support the mix of both. I'm also not saying they _have_ to be generated up front, but they might be.

I'm not proposing this hold up the progress. Clearly, having a working implementation is the goal here. However, if we're talking about making routing design changes, then I think this is worth bringing to light. These areas have been an afterthought in previous implementations.

[hidegh]

As in many times the querying is what matters, wondering if a decoupling into simpler architecture for the base usage would be possible (and would get support):

Actually with .NET core 2.2 (but even in old OWIN) by overriding the EnableQueryAttribute I was able to allow OData queries on any API/MVC route, without any extra configurations (like adding entities to the ODataConventionModelBuilder or configuring separate route).

There were just 2 things to solve:

• executing the result (so it does not fails silently outside MVC environment due serialization issues) - by considering in-memory object as querying the database with the linq expression
• plus wrapping the result into a special result type

So on any route (provided by MVC) I just applied [CustomEnableQueryAttribute], which always provided me with the result in the following format:

    public class ODataPagedResult
    {
        public ODataPagedResult(IEnumerable items, Uri nextLink, long? count)
        {
            Value = items;
            NextLink = nextLink?.ToString() ?? "";
            Count = count;
        }

        [JsonProperty("value")]
        public IEnumerable Value { get; set; }
        [JsonProperty("@odata.count")]
        public long? Count { get; set; }
        [JsonProperty("@odata.nextLink")]
        public string NextLink { get; set; }
    }

[svrooij]

Everybody using only the $select part of odata, to limit the amount of data transfered. Check-out this code https://gist.github.com/svrooij/8fef0289385257722fd344e79ad2e84a

[hidegh]

@svrooij actually I use aggregates (special grouping grid), paging, complex select clauses (as grid has a flexible filtering header). the $select is the least important part at the moment. I'd prefer a slick integration out of the box (as I suggested and i'm using outside EF Core - that would require changes in my code).

[Dzivo]

Is there any news on this are we going to get support for .netcore 3 ?

[Danielku15]

While I was also very hyped on OData and its capabilities I found out in the meanwhile that the main things we actually need are only some core features of the OData query language: $count, $skip, $top, $expand, $orderby.

Those are features that could work on top of any API, without the need of having all the heavyweights of OData. In the last 2-3 days I worked a bit on a prototype/proof-of-concept what it would mean to simply provide the OData query options on top of a classical Web API. And it turned out that it was quite easy to get this kickstarted:

https://github.com/Danielku15/OpenApiQuery/

It would still be a bit work to get it all clean and working as expected but the basics are already working.

I often feel myself locked in the OData strictness of routing and the EDM link and I'm not sure if I will continue the path of finalizing my "OpenApiQuery" library for the use in our ongoing product development. I am mainly sharing this insight in the hope that this is also a path that the OData / ASP.net core team is considering. The comment of @mikepizzo here sounded very promising towards this.

The whole query system of OData is basically a nice "URL query parameter to IQueryable" translator which can work independent. OData and the EDM just add some strictness on top.

[jannikbuschke]

@Danielku15 totally agree.
Not sure if this is well known, but several odata operations work on normal webapi controllers if the EnableQuery attribute is applied (https://www.jannikbuschke.de/blog/webapi-enable-query/). At least pagination, filtering, ordering and selecting works. One thing that does not work is expanding.

[EamonNerbonne]

While I was also very hyped on OData and its capabilities I found out in the meanwhile that the main things we actually need are only some core features of the OData query language: $count, $skip, $top, $expand, $orderby.

Yeah, I would love to see OData split into components. One component I'd use in a heartbeat would be a query-serializer, which is essentially what $query-op syntax provides, but not in a way that's reusable outside of HTTP. Even where OData-lib functionality is combined with HTTP, being able to more easily use just a subset would be nice.

[hairlesshobo]

@Danielku15 totally agree.
Not sure if this is well known, but several odata operations work on normal webapi controllers if the EnableQuery attribute is applied (https://www.jannikbuschke.de/blog/webapi-enable-query/). At least pagination, filtering, ordering and selecting works. One thing that does not work is expanding.

@jannikbuschke I am not where I can check this right now, but do you know if this limited functionality works in .NET Core 3.0? This functionality would be exactly what I need, assuming it works. I will check this Monday if you haven't already tested.

[jannikbuschke]

@hairlesshobo all my projects are stuck on 2.2 because odata, so I didn't yet experiment with 3.0 :/

[Dzivo]

@jannikbuschke same here

Also rather naively i started some new projects in 3.0 so i need to use alternative maybe its time to move away from odata

[tbalakpm]

Any update on support odata in asp.net core 3.0?

[KrzysztofPajak]

Nightly package does not supported odata for net core 3.0 yet :(

[PJPWF1]

likewise for me, all my projects are stuck on 2.2 because odata

[DerAlbertCom]

Please! Stop complaining now and asking for when it will happens, read the comments first, it's coming.

This comment: https://github.com/OData/WebApi/issues/1748#issuecomment-553109029

[weitzhandler]

@DerAlbertCom you're right, but OTOH, it maybe gives an insight of how much traffic there actually is.

[robertmclaws]

@weitzhandler No it doesn't, @DerAlbertCom is right, it just spams everyone. People should use reaction emojis, it lets you gauge traffic without cluttering up the thread.

For those that are unable to follow what is going on, the ASP.NET Team accidentally broke some stuff that OData needs for .NET Core 3.0, and the teams are presently working together to get it fixed. There should be a build ready in December 2019. You can whine and complain about it all you want, but team schedules don't always align, and it's in active development right now... so it would be helpful if you folks would just chill out and be patient. Being noisy about it works when nothing is getting done. But they're doing something about it now so the noise is just that.

If you think that the query stuff should be broken out, great. That has nothing to do with .NET Core 3.0 support... but it is a valuable discussion, so please open a new issue about it and have that discussion there.

For those of you that want to stay in the loop on things, we have a community stand-up every two weeks at https://bit.ly/RESTierYouTube. Check out the last 2 videos where we talk about this, and follow @ODataRestier on Twitter to get more info and join us for the live sessions.

Thank you for your understanding and cooperation.

[mikepizzo]

Just a quick update; we have the end-to-end tests running against .NET Core 3 and hope to have nightlies available soon. The current solution requires setting synchronous IO to true in .NET Core 3, so we are exploring the impact of rewriting the I/O to be async, which would provide better performance in .NET Core 3.

Are folks interested in getting nightlies with .NET Core 3 support, or waiting for us to explore the async IO work?

[SanderSade]

Nightlies, please. Even if they aren't ready for production, they will unblock the development work.

[NetTecture]

Push the changes, then work on async ;) I mean, at this point we all want to just see it working and try it working.

I have some projects I want to try that out and I do not care - like at all - about performance when it is about a proof of concept ;) I am not rewriting THAT much code to async in a week or so ;)

Obviously I would prefer async working, but if I can start doing generic prep work with a nightly - please ;)

Is ther a chance to push that to public nuget? I mean, there is semver and you could easily push it as preview (which most people will not even see).

[Olli64]

Nightlies would be awesome

[crackalak]

Will this be built for .NET Core 3.1? I know it's in preview but should be out in December, and it's an LTS release.

[xuzhg]

For guys who are interested in the Nightly, you can get some info from: https://github.com/xuzhg/WebApiSample/tree/master/AspNetCore3x/AspNetCoreOData3x

[Danielku15]

@mikepizzo It is great to see that the .net core 3.0 porting is advancing and I really appreciate your hard work to release this ASAP. Do you already have a clear vision/roadmap how you plan to continue on OData with .net core 3.x support? You spoke already about a lot of ideas that you and the main ASP.net core team have. I'd like to understand where the OData library is going and what the next steps are. Obviously as initial step you want to support .net core 3.0 with the library as it is. But what next?

I need some more insight to decide on the technology roadmap for our new product we are currently building. We are using today OData with .net core 2.x but we have quite severe issues due to restrictions and lacking features (spatial types, 1:n on API to CLR type mapping, custom filter functions, less restrictive routing, not possible to document the API apropriately with EDM). I have my doubts if we can continue with OData as it is today. But if your vision of OData would match with what we want to achieve, I might considering not to drop it.

I already started my own framework as PoC to replace OData with an Open API specification based system. Mostly I'm rebuilding what OData theoretically offers, and it is in a very early feature state. But I'd like not to reinvent the wheel.

No pressure on the details, I understand you are heavily loaded, but it would be nice to get in some small bullet point list what you decided to go for after these various polls and the very long discussion already 😉

[Diraekt]

Thanks a lot for the nightly build!

When you add the package:
<PackageReference Include="Microsoft.AspNetCore.OData.Versioning" Version="4.0.0" />
and add the versioning - feature in in Startup.cs:
services.AddOData().EnableApiVersioning();
You will recive the same error again:

TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

Do you have any idea how to fix it ?

[NetTecture]

Do not use versioning. I would say it is totally unrealistic at this point to expect the Odata Versioning package - particularly one that targets the OLD odata mechanisms - to actually work. Plus, this is the wrong place to ask for help - odata versioning is iirc part of a separate package (versioning) and thus once odata is stable enoug hto go into a preview - THEN is the moment you can open a bug on their forum about this behavior.

Note how the 4.0.0 version that you use is a month old. While the nightly that changes routing internally (which versioning is tied to) is brand fresh ;)

The repository is around https://github.com/Microsoft/aspnet-api-versioning/

[MinhMit]

Any update for .net core 3.0? I can’t install nightly for .net core 3.0.

[Diraekt]

Here you get the nightly feed:
https://www.myget.org/F/webapinetcore/api/v3/index.json

Should we Report bugs from the nightly build here? Or are the nightly builds not testet and so Reporting makes not much sense?

[xuzhg]

Any feedback is welcome！

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Diraekt [e-mail]
Sent: Friday, November 29, 2019 11:48:01 PM
To: OData/WebApi [e-mail]
Cc: Sam Xu [e-mail]; Assign [e-mail]
Subject: Re: [OData/WebApi] .NET Core 3.0 support? (#1748)

Here you get the nightly feed:
https://www.myget.org/F/webapinetcore/api/v3/index.jsonhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.myget.org%2FF%2Fwebapinetcore%2Fapi%2Fv3%2Findex.json&data=02%7C01%7Csaxu%40microsoft.com%7Cf4dba49aad3846a1dca208d77569a000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637106968826542597&sdata=moDyL%2Fskz78sxXanZlOYkQW%2BUaLaq9yG9LSv2oD8X5Y%3D&reserved=0

Should we Report bugs from the nightly build here? Or are the nightly builds not testet and so Reporting makes not much sense?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOData%2FWebApi%2Fissues%2F1748%3Femail_source%3Dnotifications%26email_token%3DACH5NQ7JRPOABBDMUSBC6TTQWILDDA5CNFSM4GTKE362YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFP3V7I%23issuecomment-559921917&data=02%7C01%7Csaxu%40microsoft.com%7Cf4dba49aad3846a1dca208d77569a000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637106968826547582&sdata=4EqxFIDZdYYNmfQCGPVwQFGaxt0ex4f7eNZCP8tSPLc%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACH5NQ5TAT3ZBZUJED3JY5DQWILDDANCNFSM4GTKE36Q&data=02%7C01%7Csaxu%40microsoft.com%7Cf4dba49aad3846a1dca208d77569a000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637106968826552578&sdata=OP2H5cCbrJJL2eFshUG4%2B7jMryvMuUk7%2Bcr%2FTeIJ1D0%3D&reserved=0.

[NetTecture]

I would strongly suggest NOT to post bugs here and to prefix them as new issues i.e. with "3.0:". The main reason that any discussion of details of multiple bugs in parallel in one thread here will turn into a nightmare - and.... that it becomes extremely unreadable and issues can not be tracked at all once you mix them all up in one thread.

[Diraekt]

Does nightly builds passes your unittests?

[joaopgrassi]

Just tried the nightly build 7.3.0-Nightly201911272029 today and some basic tests seem to be working. I didn't change the synchronous IO settings. @mikepizzo did you guys already have some code for the async part you mentioned, so that's why it works?

This is already some improvement to get things going.. but we miss API versioning/Swagger support 😕. We started new projects with ASP.NET Core 3.0 so.. doesn't make much sense to go back to 2.2 now. Looking forward to seeing this progressing. Thanks for the hard work!

[xuzhg]

@Diraekt All of our Unit tests can pass both for .NET Core 2.0 and .NET Core 3.0 at our side. See the PR https://github.com/OData/WebApi/pull/1963

@joaopgrassi We embeded the synchronous IO settings internally. See the PR #1963.

[aderderian]

Anything need to change in Startup.cs for this to work now? I am not using endpoint routing.

[xuzhg]

Anything need to change in Startup.cs for this to work now? I am not using endpoint routing.

See the sample codes in https://github.com/xuzhg/WebApiSample/tree/master/AspNetCore3x/AspNetCoreOData3x

[NetTecture]

Are you guys actually making sure that all the routing is accessible for getting it i.e. into API explorer? Or into API versioning? Both I would consider to be fundamental these days and ignored what seems to be out of of principle (for years). Expecially api versioning is an ugly theme and there IS someone working on it, so why not integrate.

[ud09]

Anything need to change in Startup.cs for this to work now? I am not using endpoint routing.

See the sample codes in https://github.com/xuzhg/WebApiSample/tree/master/AspNetCore3x/AspNetCoreOData3x

Thanks it works, when will be this published officially on nuget ?

[xiaomin-ms]

Just tried "7.3.0-Nightly201911272029" and it works well with Asp.Net Core 3.0. I have an existing non-OData API controller and I'm using endpoint routing. To support my new OData Controller, I simply copy the code from startup.cs from sample code and it works correctly without conflicts.

But I spend quite sometime struggling with injecting my custom odata serializer provider since the online doc Customize OData Formatter is out of date (not for Asp.Net Core). Here I paste my code to ingest my serializer provider:

            builder.MapODataServiceRoute("odata", "",
                    containerBuilder =>
                    {
                        // inject CustomODataSerializerProvider
                        containerBuilder.AddService(OData.ServiceLifetime.Singleton, typeof(IEdmModel), sp => model)
                            .AddService(OData.ServiceLifetime.Singleton, typeof(IEnumerable<IODataRoutingConvention>), sp => ODataRoutingConventions.CreateDefaultWithAttributeRouting("odata", builder))
                            .AddService(OData.ServiceLifetime.Singleton, typeof(ODataSerializerProvider), sp => new CustomODataSerializerProvider(sp, builder.ServiceProvider));
                    });

Also I found ODataEntityTypeSerializer class is not available, so I used ODataResourceSerializer as based class of my custom entity serializer and it works well.

````
public override ODataResource CreateResource(SelectExpandNode selectExpandNode, ResourceContext resourceContext)
{
var traceContext = new TraceContext(this.traceLogger, resourceContext.Request.Path);
var entity= resourceContext.ResourceInstance as MyEntity;
if(entity!= null)
{
// do whatever data enrichment logic here.
}
else
{
Debug.Assert(false, "ResourceInstance should be an MyEntityobject.");
}

        return base.CreateResource(selectExpandNode, resourceContext);
    }

````

Hope these information is useful for others.

[flipdoubt]

Where should we watch for an official announcement of a release? Is there a specific blog to watch or just expect to see something at https://www.nuget.org/packages/Microsoft.AspNetCore.OData/?

[EquiAvia]

I have been testing the latest nightly build and it is working fine with ASP.NET Core 3.1
Thanks for the update guys.

[wjvii]

I am not all that familiar yet with ASP.NET Core 3.1 so wanted to ask a question as I am getting started with a project and want to look at including OData. Is using MVC necessary for pure API projects in order to use OData?. When I create a new API project in ASP.NET Core 3.1 there is no reference to MVC but all the OData samples I see use MVC for routing. In the migrating from .NET Core 2.2 to 3.0 document https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio#routing-startup-code it says to "migrate the app to Endpoint Routing if possible". Is that possible with OData and if so, what is the proper syntax?

Thank you in advance.

[commonsensesoftware]

@wjvii no - you don't need MVC as that's the UI part. This has effectively been the setup in ASP.NET
Core since 1.0. ASP.NET Core 3.0+ changed it's model from individual package references or even meta package references to a _framework reference_. This was mostly to help discover and find which references you need. The compiler is smart enough to only link what you actually need. By default, you take a reference to the entire ASP.NET Core framework by using the Microsoft.NET.Sdk.Web SDK.

Endpoint routing is normally configured with:

```c#
app.UseRouting();
app.UseEndpoints(endpoints => endpoints.MapControllers());

I think where you might be confused is the legacy routing middleware, which is still support. Routing is independent of MVC. The `UseMvc` connects the MVC pipeline, even for API-only setups, with the routing system. Since OData doesn't support Endpoint Routing - yet, you need to continue to use this setup:

```c#
app.UseMvc(routes => routes.MapODataServiceRoute(…));

This will add the OData route to the convention-based route table in the pipeline. Despite it's name, it doesn't have anything to do with the MVC UI side of things.

I hope that helps.

[tfabian]

I installed <PackageReference Include="Microsoft.AspNetCore.OData" Version="7.2.3" />, but I received the following error at runtime: TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Microsoft.AspNetCore.Mvc.Core 3.1 is not available from nuget.

[Roman1991]

A few days ago I migrated ASP.NET Core to 3.0. OData is not fully supported in that version of ASP.NET Core, so installed a nightly build. It works well, except for one thing. If I specify the child path in one of the query options it will throw an exception.

The following query string params I send to the API:

And I get System.InvalidOperationException with the following message:

The LINQ expression 'DbSet<MediumPublisher> .Where(m => m.MediumID == __mediumId_0) .Join( outer: DbSet<Publisher>, inner: m => EF.Property<Nullable<Guid>>(m, "PublisherID"), outerKeySelector: p => EF.Property<Nullable<Guid>>(p, "ID"), innerKeySelector: (o, i) => new TransparentIdentifier<MediumPublisher, Publisher>( Outer = o, Inner = i )) .OrderBy(m => EF.Property<Nullable<Guid>>(m.Inner, "ID") == null ? null : new Publisher{ Status = (Nullable<PublisherStatus>)m.Inner.Status, ... } .Name)' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to either AsEnumerable(), AsAsyncEnumerable(), ToList(), or ToListAsync(). See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.

[NetTecture]

@Roman1991 Hate to tell you but that is likely NOT an odata bug but a limitation of the again not really usable Ef Core. Your best bet at this point is to dump EfCore and use EntityFramework (classic) which IIRC should be usable in dotnet core 3.1.

Again (like in all versions before) tehre are SERIOUS issues with the SQL generation being seriously sub-par compared to EntityFramework. As it says - could not be translated. I am in similar scenarios right now and I plan to upgrade to 3.1 over/after the weekend and then likely dump EfCore until a point in time it is usable (which likely is 2030 or so). I personally will have some serious propblems with that due to the use of global query filters, but then again there are third party EntityFramework extensions doing the same - only WORKING.

Btw, the LINQ expression looks quite complex. What is the corresponding raw Odata expression? Or the LINQ in C# style code?

[PeterTim]

I installed <PackageReference Include="Microsoft.AspNetCore.OData" Version="7.2.3" />, but I received the following error at runtime: TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Microsoft.AspNetCore.Mvc.Core 3.1 is not available from nuget.
@tfabian
You can get nightly build (7.3.0-Nightly201911272029) from https://www.myget.org/F/webapinetcore/api/v3/index.json. I've tested it on .net core 3.1 and looks like it works.

[hidegh]

@PeterTim Any schedule when it will be avail as nuget? or at least as a prelease?

[PeterTim]

@PeterTim Any schedule when it will be avail as nuget? or at least as a prelease?

@hidegh I don't know, I'm not developing this module ))

[aderderian]

Disregard @Roman1991 ’s comment. He sounds like a bozo. I’m thankful for the hard work the team is putting in on this for us and I have successfully launched a ton of sites on EF Core. If there is an optimization you need, roll your own for now. There is a lot going on I am sure. I’m excited to install the OData update and have been aligned with it as I build a new application because I knew the team would deliver.

[Roman1991]

Disregard @Roman1991 ’s comment. He sounds like a bozo. I’m thankful for the hard work the team is putting in on this for us and I have successfully launched a ton of sites on EF Core. If there is an optimization you need, roll your own for now. There is a lot going on I am sure. I’m excited to install the OData update and have been aligned with it as I build a new application because I knew the team would deliver.

Hm, I'm really confused and do not understand what is wrong with my comment.

[tfabian]

Batch operations for related entities are probably not working correctly:

Client side code:

      container.AddToUsers(user);
      container.AddLink(role, "Users", user);

      container.SaveChangesAsync(SaveChangesOptions.BatchWithSingleChangeset);

Startup:

      app.UseODataBatching();

      app.UseMvc(routeBuilder =>
      {
        routeBuilder.MapODataServiceRoute("odata", null, edmModel, new DefaultODataBatchHandler());
      });

Controller:

    [AcceptVerbs("POST", "PUT")]
    public IActionResult CreateRef(string navigationProperty, [FromBody] Uri link)

In case of batch operation the uri is "$44". How is it possible to get the ID of the newly created entity? In case of SaveChangesOptions.None it can be extracted from uri, in that case it looks like this:
"https://localhost:44311/Users(158)"

Is this a bug? The same code works for Microsoft.AspNet.OData (net framework 4.72).
Thx

[mikepizzo]

Please note that the 7.2.3 that we released last night is NOT the .Net Core 3.0 release. 7.2.3 contains some some features and fixes that we wanted to release for the current platforms, so that we could base our .NET Core 3 release on that latest codebase.

We will release a .NET Core 3 beta very soon. Because of the timing pressure we will have a very short beta cycle to confirm that this beta release works (based on the nightlies, it looks like it should) and then RTM.

@tfabian - the batching code had to be rewritten between Asp.Net and Asp.NetCore, but hasn't changed between .NET Core 2 and .NET Core 3. So that we don't lose this in the .NET Core 3 issue, can you open a separate issue, and comment on whether it is a change between .NET Core 2 and .NET Core 3, or whether it works the same in .NET Core 2 and .NET Core 3, but different in .NET Classic? -- Thanks!

[tfabian]

Please note that the 7.2.3 that we released last night is NOT the .Net Core 3.0 release. 7.2.3 contains some some features and fixes that we wanted to release for the current platforms, so that we could base our .NET Core 3 release on that latest codebase.

We will release a .NET Core 3 beta very soon. Because of the timing pressure we will have a very short beta cycle to confirm that this beta release works (based on the nightlies, it looks like it should) and then RTM.

@tfabian - the batching code had to be rewritten between Asp.Net and Asp.NetCore, but hasn't changed between .NET Core 2 and .NET Core 3. So that we don't lose this in the .NET Core 3 issue, can you open a separate issue, and comment on whether it is a change between .NET Core 2 and .NET Core 3, or whether it works the same in .NET Core 2 and .NET Core 3, but different in .NET Classic? -- Thanks!

@mikepizzo - sure I can. Actually I already added a comment to an existing issue from 2015 :) Is this good enough or should I open a new issue, because it will be probably closed as duplicate.

https://github.com/OData/odata.net/issues/241

Thx.

[xuzhg]

@All
The preview beta version is available at https://www.nuget.org/packages/Microsoft.AspNetCore.OData/7.3.0-beta. Please try and let us know any questions. Thanks.

[tjrobinson]

Thanks @xuzhg.

The preview beta version is available at https://www.nuget.org/packages/Microsoft.AspNetCore.OData/7.3.0-beta. Please try and let us know any questions. Thanks.

I'm getting this error when building:

[CS1705] Assembly 'Microsoft.AspNetCore.OData' with identity 'Microsoft.AspNetCore.OData, Version=7.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' uses 'Microsoft.AspNetCore.Routing, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version than referenced assembly 'Microsoft.AspNetCore.Routing' with identity 'Microsoft.AspNetCore.Routing, Version=2.2.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

TargetFramework: netcoreapp3.1

[PJPWF1]

I tried running 7.3.0-Beta via MIcrosoft.AspNetCore.OData.Versioning (V4.0.0)

But I still see a System.TypeLoadException. Am I doing something wrong?

TargetFramework: netcoreapp3.0

[GlennVegarSorensen]

I am pretty new to OData but see the potential.
I have the site running with 7.3.0-beta running and calling the api directly works fine but when querying anything I get the result:
[{"instance":null,"container":{},"modelID":"793b0452-7a0f-4889-85f4-07a55b6cf02f","untypedInstance":null,"instanceType":null,"useInstanceForProperties":false},... etc

Has anyone experienced something similar?

TargetFramework: netcoreapp3.0

[hidegh]

So here I got a working set-up, with camelCase support and with standard MVC routes. Only extra thing was to wrap the result via a custom ODataQueryableAttribute. It has also NSwag set-up, but haven't tested it with ApiVersioning yet. Link: https://github.com/hidegh/Meal-tracker/commits/master

[commonsensesoftware]

@PJPWF1 unfortunately - yes. The API Versioning support for OData in 4.0/4.1 targets ASP.NET Core 2.2, not ASP.NET Core 3.0/3.1 respectively. API Versioning needs a version of OData to build its package from. Since OData hasn't supported .NET Core 3.0+ until now, there was no path to create such a version. From a source code perspective there are few changes. My options were to leave OData users behind or multi-target and still provide the latest features and fixes on ASP.NET Core 2.2 until OData catches up. Now that there is some version available, I can consider building such a package.

@xuzhg what is the actual change up to this point? I was looking at the commit history, but couldn't really tell. Perhaps I'm looking in the wrong place or branch. Is this simply the 7.x codebase (mostly) retargeted to .NET Core 3.0, while still using the legacy IRouteBuilder routing method? Honestly, that's the best case because it means minimal work for API Versioning to get a working flavor out the door, which the community is clamoring for. ;)

@ALL is there any reason we are spending cycles on .NET Core 3.0? .NET Core 3.1 come out last week and is LTS. While .NET Core 3.0 is forward compatible with .NET Core 3.1 (at least as I've uncovered so far), I should point out that they are different runtimes and SDK installations. Since we missed the 3.0 train, it seems like we should just immediately move to 3.1. The primary reason I ask and mention this is because it adds significant engineering overhead. I can't speak for the OData team, but I have no team. I own everything from specs to build to coding. Building against multiple .NET SDK versions has a lot of tedious tasks to configure (at least for me). At this point, in order to build a compatible flavor of API Versioning for OData on .NET Core 3.0, I have to go back and setup a new build to support it so I can produce 4.0.1. On the other hand, everything else has already moved to .NET Core 3.1. 3.0 only lived for about a month anyway. If the OData package supports .NET Core 3.1, then it's fairly straight forward for me to crank out a package for 4.1.1, which will contain the new OData support. I'm curious what the strategy is because there doesn't seem to be any point in investing in .NET Core 3.0 at this point. I would have to assume customers (aka the community) want a flavor with LTS.

[NetTecture]

• The Core 3.x build uses IRouteBuilder - was the fastest way while they plan to make a proper implementation for .NET 5.0, also IIRC becuase they need some changes on endpoint routing (which the core team only does in the 5.0 timeframe and they lacked the ability to plan that forward to get stuck out of 3.1).

• Drop 3.0. 3.0 is a surplus release, mostly also because EF Core is ttoally broken (in ALL versions sadly) and the SQL issues only get fixed in the 3.1 timeframe (not that they are THAT much better given how much in Ef Core is still broken). At least in 3.1 you can use Ef as backend ;) 3.1 has basically broken SQL and a very limited lifespan not being an LTS release - at this point there really is no sense in supporting it. It is more the result of a fixed release date (with tons of bugs) in preparation for 3.1

If I would have a developer not planning a 3.1 upgrade SOON and being on a 3.0 project - I would send him to HR. It is obvious 3.0 is a "failed" release and only a stepstone to 3.1. Nothing lost by not supporting it.

[mikepizzo]

If there are no objections, I am in favor of making the 7.3 release .NET Core 3.1 and not supporting .NET Core 3. Any objections? Speak now...

[EquiAvia]

I have migrated directly to .NET Core 3.1.

You have a thumbs-up from me.

From: DenisAgarev [e-mail]
Sent: Friday, 13 December 2019 7:32 AM
To: OData/WebApi [e-mail]
Cc: EquiAvia [e-mail]; Comment [e-mail]
Subject: Re: [OData/WebApi] .NET Core 3.0 support? (#1748)

If there are no objections, I am in favor of making the 7.3 release .NET Core 3.1 and not supporting .NET Core 3. Any objections? Speak now...

Sure, we are waiting

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/OData/WebApi/issues/1748?email_source=notifications&email_token=AAYFIWIDEG37M5TT2BNMDH3QYJ7RBA5CNFSM4GTKE362YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXS2AY#issuecomment-565128451 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYFIWNVVAGQJYLS6E75L3DQYJ7RBANCNFSM4GTKE36Q .

[alvachien]

@tjrobinson @GlennVegarSorensen
Maybe you can take a look at the example from @xuzhg local repository: https://github.com/xuzhg/WebApiSample/tree/master/AspNetCore3x/AspNetCoreOData3x

Simply replace the OData package to 7.3.0 Beta, the repository above can be built, run and test.

With TargetFramework as: netcoreapp3.0;
Package Microsoft.EntityFrameworkCore.InMemory, Version 3.1.0
Package Microsoft.EntityFrameworkCore.SqlServer, Version 3.1.0

[XardasLord]

@mikepizzo For me it's ok to release 7.3 version supporting .NET Core 3.1

[keatkeat87]

Just upgrade to 3.1 and odata 7.3 beta, look like ok, thank a lot for odata team effort.

[alvachien]

@mikepizzo
Also support to release 7.3 version supporting .NET Core 3.1.
The only question is when ...

[tjrobinson]

I'm getting this error when building:

[CS1705] Assembly 'Microsoft.AspNetCore.OData' with identity 'Microsoft.AspNetCore.OData, Version=7.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' uses 'Microsoft.AspNetCore.Routing, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version than referenced assembly 'Microsoft.AspNetCore.Routing' with identity 'Microsoft.AspNetCore.Routing, Version=2.2.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

TargetFramework: netcoreapp3.1

I resolved this by adding this to my .csproj file:

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

[AgustinLuquesSV]

@keatkeat87

Can we see your Startup.cs using net core 3.1 and odata 7.3?

[jayoungers]

In our dotnet core 3.1 app, I've added the package:

<PackageReference Include="Microsoft.AspNetCore.OData" Version="7.3.0-beta" />

And made the adjustments to startup:

```c#
services.AddControllers(mvc =>
{
mvc.EnableEndpointRouting = false;
});

...

        //app.UseRouting();
        //app.UseEndpoints(endpoints =>
        //{
        //    endpoints.MapControllers();
        //});

        app.UseMvc(routeBuilder =>
        {
            routeBuilder.EnableDependencyInjection();
        });

My custom end points appear to be working:

```c#
        [HttpGet]
        public Task<List<MyViewModel>> Query([FromServices] MyService, ODataQueryOptions<MyEntity> queryOptions)

Thanks everyone!

[XardasLord]

I'm using this package the same way as @jayoungers. My startup:

app.UseMvc(routeBuilder =>
{
    routeBuilder.EnableDependencyInjection();

    routeBuilder.Select().Expand().Filter().OrderBy().MaxTop(odataOptions.MaxPageCount).Count()
        .EnableContinueOnErrorHeader();

    routeBuilder.MapODataServiceRoute("odata", "odata",
        oDataModelBuilder.GetEdmModel(app.ApplicationServices));
});

OData queries seem to be working :)

[Diraekt]

Is there any chance to see the commit changes from nightly build 7.3 to the beta?

We have some features they worked with the nightly build but does not work with the beta release.

Thanks

[xuzhg]

@Diraekt The changes from my nightly to beta is listed in https://github.com/MicrosoftDocs/OData-docs/blob/master/Odata-docs/changelog/webapi-7x.md. It will refresh at https://docs.microsoft.com/en-us/odata/changelog/webapi-7x, but not now.

[Diraekt]

Thank you very much for your fast response.

There are no commit ids, tags and or branches for "nightly bulids"?
The only thing I found was the beta branch called "ASP.NET Core 3.x", but when I look at the commit history of this branch, I can't reproduce the changes from NightlyBuild to the BetaBuild.

Thanks for a comment ;)

[sdar1419sn]

As discussed above, i upgraded to 3.1 with ODATA 7.3.0-beta . ODATA is partially working. i have seen $select and $expand is not working for me and getting error:[{"instance":null,"container":{},"modelID":"de19de66-6e70-4ce2-a1e8-317e003e02ea","untypedInstance":null,"instanceType":null,"useInstanceForProperties":false}]. other then that all queries are working(like filter,groupby, top etc). please do the needful

[hassanhabib]

Here's a step by step for those who want to try the beta version themselves (source code included):
https://devblogs.microsoft.com/odata/experimenting-with-odata-in-asp-net-core-3-1/

Also a video tutorial:
https://www.youtube.com/watch?v=VGnLZ6Fxnx8

[sdar1419sn]

Here's a step by step for those who want to try the beta version themselves (source code included):
https://devblogs.microsoft.com/odata/experimenting-with-odata-in-asp-net-core-3-1/

Also a video tutorial:
https://www.youtube.com/watch?v=VGnLZ6Fxnx8

thanks for your post. got to know , where lies the problem as ODATA is not friendly with mvc api routes.just used odata routes and everything is working as expacted and also removed routes.EnableDependencyInjection(); from routes delegate. just a concern , why is not working with existing mvc api routes?. once again thanks a lot!!

[hassanhabib]

Here's a step by step for those who want to try the beta version themselves (source code included):
https://devblogs.microsoft.com/odata/experimenting-with-odata-in-asp-net-core-3-1/
Also a video tutorial:
https://www.youtube.com/watch?v=VGnLZ6Fxnx8

thanks for your post. got to know , where lies the problem as ODATA is not friendly with mvc api routes.just used odata routes and everything is working as expacted and also removed routes.EnableDependencyInjection(); from routes delegate. just a concern , why is not working with existing mvc api routes?. once again thanks a lot!!

The main reason is that this beta release doesn't support endpoints routing yet, but the final release should have that covered up.

[NetTecture]

THen i have to wait with testing. For reasons of problems with odata and clients I happen to

• use normal non odata routing for some endpoints - odata routing gets refused for some actions mostly.
• use some normal non odata controllers to handle some non odata api endpoints. This is mostly a "no time to rewrite some clients, but I can just redirect them until we move them too data".

Together this means I pretty much MUST be able to use some routing other than odata ;( Once the new api is in place, i will open bug reports for every item under 1. Those acutally irk me.

[xuzhg]

@all

---

Today, we published the 7.3.0 RTM on nuget.org, see below:

---

Be noted:
1) 7.3.0 RTM includes the .NET Core App 3.1 bits, see below.
2) Please refer to https://docs.microsoft.com/en-us/aspnet/core/migration/30-to-31?view=aspnetcore-3.1&tabs=visual-studio for the prerequisites

Please help try it and feel free let us know any concerns and questions.

[xuzhg]

@hassanhabib Thanks for your blogs and videos. For the Endpoint routing, It's not included in 7.3.0 RTM, i think @mikepizzo 's previous comments illustrated the root cause. However, endpoint routing is high priority of our next step. We will work closely with .NET team to figure out the solution.

[hassanhabib]

Thanks @xuzhg - I have updated the blog accordingly.

[jpmckearin]

Thanks @xuzhg - I have updated the blog accordingly.

Link to the blog?

[xuzhg]

@jpmckearin here's the link for the new odata blog: https://devblogs.microsoft.com/odata

[TheAifam5]

Recently released dotnet core 3.1 and odata 7.3.0 is no worth to upgrade. There is so much bugs, that breaks completely everything. :) so be aware.

[hidegh]

@TheAifam5 Be prepared on other EF core issues, especially when it comes to
simple group by...

[NetTecture]

So, in simple words: The best thing about dotnetcore 3.1 is that you can throw out the buggy efcore and go back to proper entity framework which may be a LOT less modern - but actually WORKS?

[hidegh]

@NetTecture The old EF works should with code-first approach, so no EDMX.
But there are a lot of bad things in the old EF, some performance related -
you notice it once you used a real ORM. EF Core should have tackled those
"extras" but they seems to be behind some years (decades)...and well, I
think this is something not related to OData, yet it might spare some
future tickets :)

[mikepizzo]

@TheAifam5 -- can you elaborate on your comment that there are a lot of bugs in updating to .NET Core 3.1 and odata 7.3.0?

OData 7.3.0 was targeted primarily at .NET Core 3.x support (especially since .NET Core 2.2 went out of support December 23rd), so we didn't do a lot of new feature work. However, looking through the issue list I don't see any newly reported OData issues that appear to be introduced in the new release. If you are encountering new issues, please create separate issues to report.

Note that there are some differences in what EF supports in .NET Core 3 and previous versions. If those what you are referring to, then please follow up in that forum. In the meantime, note the EF team is continuing to support the older EF, and we have tested the new OData 7.3.0 libraries with the older versions of EF to make sure that your existing code should continue to work against the older versions of EF.

[royzhang666]

If you only want to make data queries, the QDataLite.Net may satisfy your requirements. It is sooo lightweight that will not take much effort on adoption. And it is based on netstandard2.1 😃

[JohnGalt1717]

So endpoint routing still doesn't work 5 months after release of .NET Core 3.0 and the termination of support for .NET Core 2.2....

Is there a way to hack in AddODataQueryFilter without using the full routing? (I could care less about routing, just want the query filtering on mvc standard routes)

[flipdoubt]

Where is the best place to watch for announcements on supporting endpoints in 3.1? That is the last piece of the puzzle we need to use both OData and SignalR in the same 3.1 app.

Thanks for all your work.

[robertmclaws]

Endpoint routing requires too many fundamental changes to the .NET Core pipeline that we’re not able to be finished by 3.1. The ASP.NET and OData teams are working together to have the necessary changes implemented by .NET 5.

In the meantime, new builds support standard routing with .NET Core 3.x and there are instructions on how to use it earlier in this thread.

[JohnGalt1717]

@robertmclaws So now the ETA for this to work is November 2020? A year after .NET 3.0 was released and 11 months after support for .NET 2.2 ended?

I trust you can see why this is a collasal screwup that destroys faith in .NET when you EOL a product without a viable upgrade path. I trust also that someone is going to take this product seriously and fix this going forward.

In the mean time, I strongly suggest that you get an interim product out that doesn't require actual routing persay and just makes [EnableQuery] work. Since it's just looking at the Query String this should be trivial to make function without the rest of the plumbing.

[flipdoubt]

@robertmclaws, thanks for letting us know not to expect an update that supports endpoint routing until .NET 5. We're all in this boat together.

[robertmclaws]

@johngalt1717 you might consider taking a step back for a sec. First off, I’m a maintainer in the Restier project, not a member of the OData team... so I don’t need to “do” or “realize” anything.

Second, I believe you misunderstood. OData supports .NET Core 3.x. Just not the new Endpoint Routing system. The ASP.NET Core team built that feature without visibility into the OData Team’s needs, and the system needs more features for OData to work. So now they are working more closely with the OData team to evolve that feature for the next release.

In the meantime, the old .NET Core routing system still works. If you are running into conflicts with your apps, you need to consider splitting Endpoint Routing code into another project and deploying it separately, or use one of the other workarounds provided earlier in this thread.

Hope that helps!

[JohnGalt1717]

Sorry, thought you were MS based on your statements.

But no it doesn't help.

.net 2.2 was depreciated before a viable solution was ready leaving customers high and dry with only a half baked product that doesn't work or a massive security risk that could blow up in a heartbeat while we wait for .net core 3 to become usable in .net 5.

.net 3.x was released at least 6 months too soon with poor planning. This just being one. Json half baked mess being another, and ef.core is even worse than it was before with ef core 2.2 (which was still phenomenally bad compared to ef 6) after being rewritten for the 3rd time.

This is the definition of how you lose trust from your customers.

We're actively investigating future projects divesting from Microsoft as a result of this horrific decision making and the very real fear it's going to happen again.

In the mean time we're ripping out odata entirely as a result of this disclosure.

In a day I wrote a compatible parser and implemented an alternative enablequery attribute and middleware to apply query params from it completely eliminating this mess so that we can finally release a supported version that isn't open to security risk because of .net core 2.2 depreciation before .net core 3 was ready.

The only open question now is if we get a satisfactory answer outlining how this and the rest of the disaster that is .net 3 will never happen again, or if we bail from MS development tools entirely and move to dart+flutter (as an initial example we're now forced to actively investigate).

(See also grpc being released in .net 3 but you can't actually host it anywhere on azure nor any Microsoft web server and Microsoft didn't disclose this until customers outted them. And still, 4 months after RTM, it doesn't work. head bang)

If Microsoft wants to be a verticalized company with a complete development and hosting story, then they have to get this stuff right. And right now Microsoft is failing hard. Heads should be rolling and Microsoft should be issuing a public statement about how .net core 3 failed and how it's going to be fixed before .net 5. This is Windows XP level disaster and the response needs to be as intensive as sp2 was in that case.

The first step is to extend security patching support for .net core 2.2 until this stuff can be properly addressed. Then outline a plan to get .net 5 up to par so that .net 2.2 upgrades are actually an upgrade and not a downgrade.

[mikepizzo]

I'm going to close this thread as the original issue (support for .NET Core 3.x) has been resolved. Customers can migrate from the now deprecated .Net Core 2.2 with very little change.

We understand that folks are eager to use endpoint routing with OData, and I will open a new issue to track that ask. As @robertmclaws says, .NET Core 3.x lacks the functionality we need to do OData routing properly, and we are working with the .NET team on a tighter integrated solution for .NET 5. However, in the meantime we do have a potential work-around that we are pursuing to support endpoint routing with OData in .NET Core 3.1. For discussion of endpoint routing support in OData, see Issue #2029

If you encounter any other issues with .NET Core 3.x, please open as separate issue so that we can track appropriately.

Thanks!

[aderderian]

Thanks for your help on this one. It was an important one.

[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?

[xuzhg]

@NetTecture Thanks for your reply. I don't have answers for your bunch questions yet 😄 .
By the way, Could you do me a favor to move/copy your comment to the new Issue at https://github.com/OData/WebApi/issues/2029. Because this issue is too big and it's closed already. Thanks.

[NetTecture]

Done

[tinonetic]

Hi,
Where can one find a sample application?

[ikemtz]

I created a VS extension that has templates that greatly streamlines the process of creating an OData service.

https://marketplace.visualstudio.com/items?itemName=ikemtz.NRSRxExtensions

[xuzhg]

Hi,
Where can one find a sample application?

@tinonetic What kind of sample application are you looking for? Actually, you can find some tutorials at https://devblogs.microsoft.com/odata/. For example,
1) https://devblogs.microsoft.com/odata/asp-net-core-odata-now-available/ for getting started.
2) https://devblogs.microsoft.com/odata/enabling-endpoint-routing-in-odata/ for endpoint routing.

Please leave more details so we can help you more efficiently. Thanks.

[gordon-matt]

@tinonetic I created a GenericODataController and a demo app as well.

[tomasfabian]

Here you can find a library for OData CRUD operations, CreateRef, DeleteRef, OData batching with SQL server transaction, Startup plumbing code for hosting and more.
I have a complete .NET example application which sends http request via OData client to SQL server and all connected apps have updated their UI via Redis pubsub ,

https://github.com/tomasfabian/SqlTableDependency.Extensions

[tinonetic]

Wow! Thank-you guys for sharing your knowledge. @xuzhg , I am struggling to understand how I can make it work with Entity Framework

[tomasfabian]

@tinonetic here I have a sample from above mentioned github repository - Kestrel hosted OData and EF code first migrations with containerized developement environment: https://github.com/tomasfabian/SqlTableDependency.Extensions/tree/master/Samples/OData/SelfHostedODataService

[NetTecture]

This is actually the more simple part. Here some rules, though:

• Do NOT expose Ef objects. Make a defined API and use Automapper Projection to map them.
• Stay away from EfCore as far as you can. Ef classic works in netstandard.

Then it is quite simple. All queries are automatically translated in the query tree.

[weitzhandler]

I work with EF Core and OData and have no problems.

[NetTecture]

Then you do not use projection and expose Ef objects directly to the outside world, which is an antipattern. The only sensibe way to map EfCore objects to business objects is Automapper ProjectTo (because it handles query parameters through the whole projection) and that is broken - and gladly ignored by your friendly EfCore.

Also - your use cases MUST be simple with your users never wanting to acutally USE odata more complex features. Why? Because hey, even the official blog lists EfCore as not working:

https://devblogs.microsoft.com/odata/aggregation-extensions-in-odata-asp-net-core/

in 2.2 aggregations happen client side (performance: well, lets say 100 times slower than proper SQL is a use case that we right now suddenly got). 3.1 - no client side, no support for certain aggregations = not working.

[weitzhandler]

I see. I admit I haven't done complex things with OData and EFCore.

[tinonetic]

Thank-you guys. As @NetTecture mentioned too, we also tried using AutoMapper but it broke the OData functionality. We ended up using it as is and it worked so far. We

1. ran against a DB view(meaning readonly) with only the minimal possible data, zero sensitive data
2. used the paging attribute to enforce paging
3. secured it using IdentityServer

That's the best we could do

We are currently trying to use Redis cache based on Microsoft.Extensions.Caching.StackExchangeRedis

Not sure if anyone has experiences to share on that

[JohnGalt1717]

@tinonetic

The issue is EF Core 3.0. Basically what's happening is that it supports WAY fewer queries server side, AND they eliminated client side evaluation except for on the result from the server.

So, OData effectively breaks in a ton of cases where it was fine before, and there's a ton of cases where complex queries that then have odata applied to them will just fall over.

I.e. the very case where you really want oData for complex queries that then filter the resultset with $filter, $select, $orderby etc. are now toast with EF Core 3. This won't be fixed until EF Core is fixed and the EF Core team doesn't think there is anything to fix.

So I suggest you mosy on over to the EF Core group, and give them examples and complain that their choices in rewritting EF Core for a 3rd time and making it even worse than it was before as completely broken oData in any complex scenario and they need to fix it. Maybe with a few more voices they'll finally admit they have a problem.

[NetTecture]

As a workaround: Use EntityFramework, NOT CORE - it works fine in .NET core 3.1. Just finishing moving my whole project over.

I have no idea about how one working on an OR/Mapper can be so arrogant as the EfCore team is - but they seriously seem to think that their Hello World examples are all that there is and have no inclination to actually fix the product in anything you would possibly call acceptable timeframe. For now, the only choice is to use EntityFramework - non core. Magically it works.

[tomasfabian]

I tried to trivially use Automapper with IQueryable<T> ProjectTo, but it seems that it automatically increases the payload (it fills navigation properties) without explicitly declaring Include/Expand. As it is done during projection if I understand it correctly, DisableLazyLoading won't help in this case.
EF Core was able to fetch the data from db, but EF 6.4 throws:
_'Sample.Domain.DTO.BookDto' appears in two structurally incompatible initializations within a single LINQ to Entities query. A type can be initialized in two places in the same query, but only if the same properties are set in both places and those properties are set in the same order.'_

I also tried to use ProjectToQueryableinstead of ProjectTo, but it is not supported in NETCOREAPP.

```C#
// Profiles CreateMap(); CreateMap();
public class BookDto
{
public string Title { get; set; }
public PublisherDto Publisher { get; set; }
}
public class PublisherDto
{
public string Name{ get; set; }
public List Books { get; set; }
}

public IQueryable GetAll()
{
return booksRepository.GetAll().ProjectTo(mapper.ConfigurationProvider);
}

As a seasoned .NET developer I would probably not recommend using Automapper for newcomers. Isn't it much easier to decorate your internals or secrets with (similarly to NotMapped db annotation):

```C#
[Microsoft.OData.Client.IgnoreClientProperty]
public bool IsDeleted { get; set; }

oDataModelBuilder.EntitySet<StoreItem>("StoreItems").EntityType.Ignore(c => c.IsDeleted);

and applying SelectExpandQueryValidator for restricting Expands etc, or intercepting object materialization if necessary?

OData is Open by default, so hiding is up to the API consumers and the clients are free to compose their queries by demand.

As a proof for not increasing the payload from the server unnecessarily, try to return an object with filled navigation properties from a POST and OData will discard those values.

Have a lot of fun(Kotlin syntax)
Howgh

Regards Tomas

[NetTecture]

It is quite trivial to write a program that analyzes the expands coming from an odata query context and extract the necessary includes (which you can turn into ProjectTo). I did so in about a day back when we started with automapper.