-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET Core Support - IN PROGRESS #939
Comments
Hi @xiaoxin1983, thank you for bringing up the topics. Please be assured that we are actively working on the next version of OData WebAPI to be compatible with ASP.NET Core. We recently had some shuffling so this is why it seemed like vNext is inactive during the past months. Please note that the vNext branch is still in its early stages and we may take a different approach once we have our architecture finalized. I'm unable to give any firm timelines for releases at the moment, but I would say at least 2-3 months out. For OData lib 7.0, we don't have a plan to port to VS2017 just yet, but we do have visibility on the request for it. We are working on moving OData lib 7.0 to .NET Standard, and we'll coordinate moving WebAPI to 7.0 at that point. Thank you for your patience and contributions to the community! |
@AlanWong-MS
may you publish a smallest available version as soon as you can ? Thank you ! |
We are working with the ASP.NET team here to make sure we have the correct implementations since there are fundamental changes in the ASP.NET Core framework--we are still in the discussion/design process. Thank you for informing us of the issues that you've found in the current state of vNext branch. We'll provide code updates to the repo once we're signed off and will address the bugs that you mentioned. :) Pinging @xuzhg to see if he has any quick input on your questions with the current implementation of vNext in the meantime. |
thank you very much for your supports 💯 , i'm Looking forward to the new version |
+100, can't wait for OData running on ASP.NET Core :) Thanks to the team for working on this, please let us know even if there's an super early Alpha we can start using/testing and provide feedback to you guys..! |
@lelong37 it's possible to get it working with minor modifications to the source code. The problems I faced mostly related to gluing the request to populate the appropriate odata class. I've seen some forks achieving that and I have a local modification that I used myself that seem to get the job done. It's not pretty, but if you need something, it's more than doable. @AlanWong-MS I would like to see more modular components in the redesign. Maybe some sort of provider that I can inject, so that I can manually map from request to the output, if I don't want to rely on MVC routing, or plug in MVC routing partially where it makes sense. Also, I would like to be able to mix OData and GraphQL overtop of webapi. detect which query language the client is asking for, and pipe accordingly, without having to create separate urls for each language. I think it's important to support multiple query languages, and make generic abstractions where it makes sense. Would something like that be practical with the redesign? |
@wizarrc thanks for sharing your experience, can you be more specific on what your fix looks like? |
@mrns sure, I can see if I can do an actual fork and link to it here if you'd like. It might take me a week to get around to it. I'm not really a nuget author, so right now I have everything stored locally. I made a few common sense fixes like changing the output filters to async for things like count to work better with EF core. Other fixes were hacky to get it to flow though; can't remember off the top of my head (3+ months ago). There are other forks and examples I built from. I'd recommend you check them out. |
@wizarrc cool thanks! no need to create a nuget package if that's complicated, maybe a github repo? I am actually having issues setting up vNext in my webapi project because although it is a .net core web api, I have some dependencies with net452 so I had to set it as my target framework and it seems vnext is not compatible. Looking at vNext code and sample right now to see if I can make any changes to make it work. By the way, do you use the convention model builder to hook up an existing EF data model? Like this, where Customer and Order are autogenerated classes: public static IEdmModel GetConventionModel()
{
var builder = new ODataConventionModelBuilder();
builder.EntitySet<Customer>("Customers");
builder.EntitySet<Order>("Orders");
return builder.GetEdmModel();
} |
@wizarrc, I was able to make it work by compiling Microsoft.AspNetCore.OData targeted to net452. I have setup an EdmModel based on my own POCO classes and I can see the odata/$metadata endpoint just fine with all the odata model information ;) The problem I am facing now is that eventhough I've added [EnableQuery] to the controller I get 404 when trying to issue a get to a url similar to odata/Products(1), although my the same controller is reachable at product/1. I already tried a few combinations as well, like odata/Product(1) and so on with no luck. Any ideas? This is how I am enabling the OData route: app.UseMvc(builder => builder.MapODataRoute("odata", model)); |
Does it mean we ain't gonna get OData Webapi previews before Asp.net Core 2.0 released? |
@wizarrc, sorry I somehow missed your message from earlier: We're still in the middle of refactoring the project as our resources were being pulled left and right during the past months. Could you please file a feature request for this so that it doesn't lose visibility? Thanks! @anton-abyzov, we're in the middle of some housecleaning tasks to enable faster releases and more effective community contributions. We made a lot of progress on the WebAPI refactor and we're doing our best to make it compatible with .NET Framework to reduce as much pain as possible. We're wrapping up on the .NET Framework portion and will start on the .NET Core portion shortly. We'll have to revisit the ASP.NET Core 2.0 use case and determine whether it's the right version for us (and you :) ). For now, the status for the project is "in progress;" unfortunately, I don't think we'll be pushing out a preview before ASP.NET Core 2.0 is released. Hope that helps a bit! |
While the complete support would be the most awaited piece of the work, please consider there are many classes that should not live in the same context of the asp.net / webapi stuff. This is what I mean:
Please move these pieces out here in a neststandard library. This should never require any dependency from the asp.net stuff. |
.NET Core 2.0 , AspNetCore 2.0 , EFCore 2.0 all published , and odata core ? |
This is the last thing I am waiting on now in order to move to .NET Core. With the release of .NET Core 2.0 less than a day ago, what's the update on OData support? |
+1 |
Hi everyone, I'm as excited for the newly released .NET Core/Standard 2.0 as everyone. :) Short answer: we've been focused on cleaning the repo for easier understanding and code changes. We're going into our planning phase now and will visit the .NET Core 2.0 topic as we're working on the next version of WebAPI OData. At this moment, there's no definitive answer to when we're moving to .NET Core 2.0, but with our repo improvements during these past months and release of VS2017.3, on your personal environment, you should be able to attempt the migration to .NET Standard/Core 2.0 with a few clicks. Long answer: as you may know, OData is on .NET Standard 1.1, which supports .NET Core 1.0; .NET Standard 2.0 is needed for .NET Core 2.0. During the past months, we've made a lot of improvements to the layout of our repos and internal test systems to help devs modify the code faster and easier. One of those things that we've changed is creating a separate solution (in VS2017!) to house the .NET Standard version of OData and associated unit tests in .NET Core. With the release of VS2017.3, one should be able to open that solution file and switch to .NET Standard 2.0 and .NET Core 2.0 with a few clicks in the project settings within VS2017. We don't have an answer as to when we're moving to .NET Core 2.0 yet as we need to scope out how big of a change it is to move to .NET Standard 2.0 and how big of an impact it will be to the rest of the OData users. This discussion will take place during the oncoming weeks, but for now, one can try out OData on .NET Standard 2.0 and .NET Core 2.0 locally with the steps mentioned above. Hope that helps and thanks for your continued interest and support! |
It is great to see there is some progress, but can you please direct me to somewhere, anywhere that gives some direction on how we can add an odata service to a >net Core 2 WebAPI solution? The documentation is all over the place, and the documentation that is there is a fork with dead links. There are a lot of people who have committed to the oData interface and we really need a workable, comprehensible path to getting a service running on our webapi core2 |
Hi! Thanks to everyone for their patience. Yes, we will be releasing a version of OData WebApi that supports ASP.Net Core. We hope to have an alpha on NuGet in the next several weeks. After that, we’d like to get feedback before releasing an RTM version. If you are interested in help out, please let us know. The current plan involves breaking changes. We want to release the ASP.Net Core version in a Microsoft namespace as opposed to the current System namespace. We decided to change the existing System namespace to a Microsoft namespace while leaving the existing APIs signature as-is. This does constitute a breaking change, albeit one we think is easy to accommodate. We’d love to get your feedback on this approach and its impact to you. If you have a different idea or just want to chime in with a pro or con, please let us know. At a high level, the plan is to combine the code from the master branch (formerly OData60) and the maintenance-aspnetcore branch (formerly vNext) to create two version of OData WebApi from a common codebase: a ASP.Net WebApi 2 compatible version and an ASP.Net Core compatible version. Below, you’ll find some details on how we arrived at this plan. We plan to add a feature branch to the OData\WebApi repository and begin consolidating the changes there. Feel free to chime in with thoughts and concerns regarding this plan on either this issue or a new GitHub issue. Again, thanks for your patience. – The OData Team. We have examined the code in both the master branch (formerly OData60) and the maintenance-aspnetcore branch (formerly vNext) and created a design that supports both ASP.Net WebApi 2 and ASP.Net Core from a single code base. We found that the two branches share about 80% commonality and that the ASP.Net WebApi classes were intertwined with much of the common code. The design we landed on was to refactor the existing code into an ASP.Net WebApi 2-specific portion, which is tightly coupled to the ASP.Net WebApi 2-specific classes, and a common portion which has no dependency on ASP.Net. The code from maintenance-aspnetcore can then be refactored to consume the common portion and provide the ASP.Net Core-specific portion. This design will allow us to ship both an ASP.Net WebApi 2 compatible version of OData WebApi, a.k.a. the recently release OData WebApi 6.0, for customers not interested in migrating to .Net core and an ASP.Net Core compatible version of OData WebApi for customers that do plan to migrate or build new services on ASP.Net Core. The common parts of the code can be maintained more easily for both versions which reduces the overall engineering maintenance cost. Additionally, we will be able to add new features to the ASP.Net WebApi 2 version, as well as the new ASP.Net Core version. The design has been prototyped and mostly coded so we’re confident in the design. The next step is to begin reviewing and committing the code to refactor the existing library into two components. This will be created through a series of pull requests targeting a new feature branch. Once committed, we’ll create and publish a nightly Nuget package in MyGet.org for testing. From there, we’ll add the ASP.Net Core version and tests and publish a second nightly Nuget package in MyGet.org. The feature branch will ultimately be merged to master and we’ll ship both packages via Nuget.org. One issue we ran into during prototyping was the best way to structure the common code. We considered packing the common code into a new Dll based on .NetStandard which can run on Net Framework 4.x as well as .Net Core. However, some of the APIs we needed would have caused a dependency on .NetStandard 1.5, which would force a dependency on .Net Framework 4.6.1 instead of 4.5. To avoid this, we decided to use a Shared Project, a VS 2015 feature that allows common code to be maintained in a single project and included in additional projects. As a result, we’re able to allow each version of the library to take a dependency on the appropriate version of .Net, which will require that the common code compiles for both frameworks and will likely use some conditional compilation, i.e. #if. An additional issue is that we want to release the ASP.Net Core version in a Microsoft namespace as opposed to the current System namespace. The compiler does not offer a way to compile the same code in two namespaces and we didn’t like the idea of conditional compilation for the namespace. We decided to change the existing System namespace to a Microsoft namespace while leaving the existing APIs signature as-is. We have validated that only changing the using statements in the End to End tests results in a project that compiles and runs. This does constitute a breaking change, albeit one we think is easy to accommodate. We’d love to get your feedback on this approach and its impact to you. If you have a different idea or just want to chime in with a pro or con, please let us know. The last hurdle we faced was a build system that can build and release the ASP.Net Core version of OData WebApi. .Net Core is only officially supported on VS2017 so we’ll need to not only require VS2017 for development but also lab builds that produce our Nuget packages. We’ve spent the last few months upgrading our engineering system to eliminate this hurdle. The first part of the refactor will target VS2015; VS2017 will be added as we introduce the ASP.Net Core portion. |
About shared project, I'd recommend using multi-target feature of new csproj format of vs 2017. It allows you to multi target as following for example: net45;netcoreapp20. After that, you can reference dlls, add files etc based on condition. For example, take a look at what I've done in one of my projects: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net45;netcoreapp2.0</TargetFrameworks> <!-- Multi target library -->
</PropertyGroup>
<ItemGroup Condition="'$(TargetFramework)' != 'net45'">
<!-- Please add following file in .NET 4.5 target -->
<Compile Remove="Implementations\ActiveDirectoryUserServiceProvider.cs" />
</ItemGroup>
<ItemGroup>
<!-- Please add nuget packages to all targets -->
<PackageReference Include="AntiXSS" Version="4.3.0" />
<PackageReference Include="IdentityServer3" Version="2.6.1" />
</ItemGroup>
<ItemGroup>
<!-- Please add following project to all targets -->
<ProjectReference Include="..\Bit.Owin\Bit.Owin.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)' == 'net45'">
<!-- Please add following dll in .NET 4.5 target -->
<Reference Include="System.DirectoryServices.AccountManagement" />
</ItemGroup>
</Project> |
@ysmoradi - I looked at the multi-target but there is a subtle difference between this and a shared project: a shared project does not produce an assembly. At the moment, we don't have a plan to refactor the shared into assemblies but there is a feature ask for it. I do think the multi-target makes sense if we want to breakout common code into reusable bits. |
@robward-ms Based on current core-fx team approach which results into several "binaries/nuget packages" such as System.Linq.dll & System.Linq.Expressions.dll etc, I think it would be nice to see a common approach across all "Microsoft/.NET community" based products. Consider a scenario when there is a library developer who wants to create some nuget package for OData server side to provide some added value to the community, what nuget package should be referenced when there is no "ASP.NET/ASP.NET Core" thing required in that library? There are two libraries based on your current decision, "MS.AspNet.OData" & "MS.AspNetCore.OData", so what should be done in this situation? |
Actually yesterday MS release dotnet core 2.1 Rc1 with GoLive. Starting to use it next week - and desperately in need of an odata server component asap for 2 projects. |
@chuanboz @NetTecture Would you please share us the reasons "have to update to 2.1 or high"? |
Simple. Entity Framework 2.1 - 2.0 is unusable for us thanks to missing Group By. This is a long term project and I am opening an evaluaton branch for 2.1. We are getting a go for a refactoring of a quite old and convoluted codebase and given a 12 month timeframe I am really not planning to go with full dotnet. On top, 2.1 does actually have a golive license, Sad how - sadly - Odata is now the stepchild of the whole dotnet web stack. |
EF2.1 does support group by: |
Please please please read what I said again and then have someone explain it to you. You obviously misunderstand plain english. Yes, 2.1 does group by - this is why we need to use 2.1 and can not use 2.0. Sadly 2.1 has no odata release yet ;( |
You should read again what you said instead of complaining. |
Ah, please. Rude is... misunderstanding... "Simple. Entity Framework 2.1 - 2.0 is unusable for us thanks to missing Group By." A little more complex english than in comic books. The answer to: "Would you please share us the reasons "have to update to 2.1 or high"?" Simple. EF 2.1 2.0 is unusable for us thanks to missing GroupBy. It is quite easy to understand (once you get over the SJW attitude of yours) that missing group by refers to 2.0, not 2.1 "What I really don't understand is your rudeness towards people that is only willing to help." "An gutem willen geht die Welt zugrunde." Have someone translate that for you. And explain it, likely. I generally give zero credit for trying. I also do not get paid for tryiing. And I stand to is - sadly OData is the stepshild of the whole stack. Damn, it is such a nice technology but it seems to fall wayside in implementation at the moment. |
@NetTecture - Sorry you feel that OData is not adequate for your project. Also, I've met @raffaeler and he's well spoken and understands English pretty well. All, |
Says tthe next person. I don't think that OData is not adequate - in fact, I think OData is probably the best solution for a very crappy problem that anyone so far has come up with. But OData is a piece of paper - a specification. Andit was repeatedly communiated tha this project is behind schedule with ressources being pulled left and right. That IS the definition of a stepchild project - something falling on the wayside of ressources If it would not be a stepchild project you would have all the ressources and have a beta or something out these days on the nuget official feed to support the dotnetcore 2.1 release. Including client code generation. The fact that OData in dotnet core is like permanently late and that for example Alan Wong has posted stuff like "as our resources were being pulled left and right during the past months." totally makes it a stepchild project. I have never said OData is not adequate. It has some "issues", spec wise, but nothing too grave, particularly in the lst release (how anyone could not have an IN verb for select originally is something I can only attribute to... well, yeah, not thinking it through - but that is fixed now. Frankly, I am quite a little afraid about the future of Odata - because MS has a LONG history of abandoning projects exactly in this area, and so far Odata is about the best thing I have seen to this particular problem.. Funny for example how I am watching build conference videos now and there seems to be zero information about a common data access standard between program parts (i.e. Odata). While this is pretty much extremely important. And btw., I follow the code of conduct. not in the US "SJW and everyone can complain about being insulted" way, but in the good old german "stand to your facts and be right" way. Yeah, cultural difference. |
@NetTecture - The code of conduct is explicit, please read and abide by it. Again, you can review it here. All opinions are welcome and we value constructive conversations. However, your tone is aggresive and insulting. |
You are right. That definitly invalidates every argument I ever made. Robert. Better not make arguments at all because they are insulting to you. Quite understood. Have a good night. |
@xuzhg , the reason we target asp.net core 2.1 is because of the extensive support on [Generic Host] (aspnet/Hosting#1163) and DI and other Microsoft.Extensions.* package that give us flexibility and productivity. Ideally, I'd like to see OData .net core support to natively have the DI support. For example, provide the ability to integrate with IHttpClientFactory to allow us to customize the HttpClient used for communication, that will further allow us to integrate it with Polly library for retry, and also better integrate with Service Fabric to service location and internal DNS resolution, etc. |
You make a very good point that EF 2.1 and GroupBy support.
Again, all opinions are welcome and we value constructive conversations. Thank you for participating in the conversation. When I said your tone is aggressive and insulting, I was responding to:
When I used the words "not adequate", I was using the "not satisfactory or acceptable in quality" definition. I did not mean to misrepresent your words, I was responding to:
When I said the code of conduct is explicit, I was suggesting that individual members do not get to define the code of conduct, including myself. Microsoft has clear guidelines for code of conduct on it's open source projects. I was specifically responding to this:
|
agree w/ @robward-ms, as for the mention/comment:
Wanted to mention that this is not necessarily negative, and actually somewhat by design, dotnet core is heavily modularized especially when compared to legacy .NET pre-core. Therefore frameworks/stacks built upon it will also likely share/follow this design feature and in architectural principle: modularization e.g. ASP.NET Core (Web API), Entity Framework Core, etc., again, are also be heavily modularized. One of the design goals from this effort/design, is to be able to rev other modules at each teams cadence, bandwidth, comfort, parallel development across modules, etc. without the dependency of rev'ing the entire .NET Core Framework in lockstep, meaning the opposite of shipping all or nothing (obviously, depending on the degree of change/rev especially in regards to core modules). This is usually the preferred approach for many runtimes/frameworks, we prefer to get latest features, faster shipments of them, etc. vs. knowing features are scoped, ready, yet held back because of coupling/dependencies on others e.g. legacy .NET. Along with the other cornerstone design reasons e.g. NET Standard, x-plat, cloud density/portability, etc., which are totally different topics and for another conversation. So, we are in the early versions of .NET Core v2x, some of these benefits and advantages from these design decisions will not have been fully materialized, however they will, over time especially when other modules become more mature and frequency of changes/revs reduces. OData is built on top of or with:
OData literally happens via (disclaimer: massive oversimplification):
With that being said, yes, especially in early phase of all things dotnet core v2+, OData is somewhat at the mercy of all of the modules is built on top of, or with (e.g. .NET Core, ASP.NET Core, especially Web API), Entity Framework Core, etc.) more now, than potentially later, in early stages of v2) Again, this is what we want e.g. if Entity Framework Core rev's to vNext and doesn't break OData, we would want the new EF Features, etc. Yes, some could argue, one of drawback's here is there's not a monolithic release, where everything is in released in lockstep e.g. OData vNext is not ready with the latest and greatest ASP.NET Web API vNext bits are ready. However, in my experience this has rarely been the case, dev's want new features ASAP, when there ready, and they want them like yesterday. Off-topic: (forgive my ignorance, if list below has already mentioned or suggested):
|
I dont agree with the @NetTecture message form but the OData team have to understand that early adopters spend a lot of energy in OData and make design choices. Not having a clear roadmap and seeing the very low number of commits last weeks can make people think that they where misled into a dead end. I agree with the fact that EF Core 2.0 is not usable in an application. We really need EF Core 2.1 group by. Is it possible to update Analyzers too? Some referenced packages don't seem to be available in nuget anymore. OData is a great solution and thanks for all the work you've done. |
I have a very large global client that wants an OData endpoint for use with Microsoft Power BI. We’re using .net core heavily at the moment, is .net core support usable ? |
I think this whole discussion about group by support++ is confusing. It seems you discuss features that should not be part of / is not part of OData. Or am I wrong? My understanding is that the OData library is an abstraction over IQueryable (Ok, maybe too much of a simplification, but you get the idea) |
@mickdelaney We're using OData with ASP.NET Core 2.0 on a huge project. Bottom line - Use it, but with caution. Make sure you understand exactly how it works, and work against a well defined set of requirements, so you can map those requirements to existing capabilities. |
@mickdelaney Its been a while since I used PowerBI with OData... but my experience so far has been that it simply sucks all the data out of the source with really simple queries and then does any operations the user wants (grouping, filtering etc.) on its internal copy of the data - I don't think you need $groupby support for PowerBI to make use of your data source. Note that if you have a low default page size and a lot of data its not smart enough to request bigger pages by itself so the initial ingestion of data could take a while. |
@mickdelaney Take my word with a grain of salt, but we are currently migrating a sharepoint-data-based application (for a global customer as well) to a database-based application using the nightly .net core builds. We also plan on using PowerBI in the future and I think the features needed for this are mature enough. We currently have some issues with batch queries only being able to perform 1 request, but I currently have no time to look into it if it's our fault or not - we can work around it so it's no top priority right now. The basis of our (quite complex) system is working right now and we are working on fixing some smaller issues regarding our adaption. There are 20 issues open but for us there was no showstopper yet. We expanded on code from @gordon-matt who now has released a library containing his GenericODataController, he might be able to tell a bit about the maturity as well. |
@mickdelaney, We are using .Net Core WebApi OData in an application using EF7/Orchardcore/Syncfusion controls. All sorting/filtering/grouping commands generated by the Syncfusion Grids work very well. The only issues we have comme from EF7 2.0 that have missing features like In memory group by instead of sql grouping and a bad support for Oracle (Oracle is very late on their .Net Core driver and EF7 driver. We use Devart driver for now). |
@Compufreak345 Thanks for the mention. I am glad to see that code is useful to you. Feel free to contribute back to the repo if you'd like to do so. As for my opinion on the maturity of OData for .NET Core, I use it everywhere throughout my own framework/CMS and a few issues did come up, but they were pretty much all dealt with. I am quite happy about the state of it at the moment. However, there is a new issue I just logged recently with it being broken in .NET Core 2.1 RC (#1447). I assume this will be fixed soon after the final release of 2.1 though. Other than that, all looking good for my use cases. |
Thanks so much everyone for the comments, really appreciated... I feel alot better about going down this road now !!! Regards |
@gordon-matt I will second your statements. I've been using it since Beta-1 and it has fulfilled the majority of our simple use cases. We've only had a few minor issues that I wouldn't consider to be showstopping for a major app (combining a filter with an expand on a field that is a calculated SQL view column). To the folks that made this possible, I give thanks. It has enabled me to keep moving down the aspnetcore path while providing our frontends with critical querying support. @mickdelaney You should be in good hands. |
ASP.NET Web API OData 7.0 is available on Nuget.org now, you can download it from:
Please try it out and let us know any problems, concerns, questions. Thanks! Regards, |
We aren't able to use this alongside Swashbuckle with ASP.NET Core 2.1 and .NET Framework 4.6.2 due to soemthing related to these issues domaindrivendev/Swashbuckle.AspNetCore#581 Is there a plan to get OData working seamlessly with tools such as swashbuckle? We've had to remove our usage of OData given this issue |
Wondering if there is any update on the question @fiksen99 asked related to Swashbuckle integration etc? We started a migration project towards .net core, but a few services expose OData endpoints side to side with regular endpoints, and we need to expose these endpoints in the swagger.json that we generate (we use the generated json to deploy in Azure API management gateway). |
hi, it's long time after.netcore 1.0 released , and the odata lib 7.0 is ready, and the 6.0 is already released, but the odata web api vnext is doing nothing. can you make a plan then i know when can i update my project .
and , the odata lib 7.0 can't install for vs2107, and the vnext branch is import 6.x version, can you update it?
thank you
xiaoxin
The text was updated successfully, but these errors were encountered: