search

OData / WebApi

OData Web API: A server library built upon ODataLib and WebApi
https://docs.microsoft.com/odata
Other
850 stars 474 forks source link

.NET Core 3.0 support? #1748

Closed enchev closed 4 years ago

enchev commented 5 years ago

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'.'

image

Let me know if I've missed some setting!

JohnGalt1717 commented 5 years ago

+1

thomas-rose commented 5 years ago

+1

JohnGalt1717 commented 5 years ago

Still broken in Preview 3.

madansr7 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

RomainAn commented 5 years ago

Hi, no update about this issue ?

sergiosysmiddle commented 5 years ago

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

Hello @madansr7 , any news?

charlesjelliott commented 5 years ago

+1 Also a problem for me

Hantse commented 5 years ago

For me too :)

ace90210 commented 5 years ago

+1

madansr7 commented 5 years ago

@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 commented 5 years ago

+1

CLFPosthumus commented 5 years ago

Issue remains with preview 4, +1

wakkasha commented 5 years ago

+1

albiberto commented 5 years ago

+1

ycrespo commented 5 years ago

+1

cesfnc commented 5 years ago

+1

artemedea commented 5 years ago

+1

LisaTehChatBot commented 5 years ago

@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 commented 5 years ago

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

robertmclaws commented 5 years ago

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

Hantse commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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 commented 4 years ago

@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 commented 4 years ago

@pluraltouch How are you misled by the package?

image

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 commented 4 years ago

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 commented 4 years ago

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

si2030 commented 4 years ago

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

si2030 commented 4 years ago

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

Hantse commented 4 years ago

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

KanishManuja-MS commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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.

sdykae commented 4 years ago

Support .Net Core 3.0 please

frabriziocontin commented 4 years ago

Please help!!! Support .Net Core 3.0

dorbacao commented 4 years ago

I tried to use odata in preview 7 and also nothing

robertmclaws commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.