.NET Core Support - IN PROGRESS

[hi-xiaoxin]

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

[AlanWong-MS]

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!

[hi-xiaoxin]

@AlanWong-MS Thank you for your reply ! we think the .netcore/aspnetcore is exciting, so we are actively upgrading to new platform, but we stop at odata, i tried to debugging and compile the vnext branch. here is some issues , FYI

1. $select query ( just use $select segment only) is not working ,this is a bug ( ODataQueryOption BuildQueryOptions method )
2. $expand on one to many navigation is not working , it's throw exception 'Argument types do not match'
3. the ODataInputFormatter is not finished
4. ...

may you publish a smallest available version as soon as you can ?

Thank you !

[AlanWong-MS]

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.

[hi-xiaoxin]

thank you very much for your supports 💯 , i'm Looking forward to the new version

[lelong37]

+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..!

[wizarrc]

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

[mrns]

@wizarrc thanks for sharing your experience, can you be more specific on what your fix looks like?

[wizarrc]

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

[mrns]

@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();
}

[mrns]

@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));

[anton-abyzov]

Does it mean we ain't gonna get OData Webapi previews before Asp.net Core 2.0 released? Could anybody from MS let us know the status on OData please?

[AlanWong-MS]

@wizarrc, sorry I somehow missed your message from earlier: @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?

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!

[raffaeler]

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:

• The ODataUriParser is already in the OData.Core BUT it is useless to extract a predicate (Func<T, bool>) or a projection. The FilterQueryOption class should not stay here and it is super-precious because it is the one that allows converting the odata query in a Linq Expression (via FilterBinder class).
• The same apply for the other Query Options
• The ConventionalModel Builder is not available either in OData.Core or in Edm (nestandard) nuget packages. Why? (I had to build a model by hand using reflection ... is a pointless and useless work)

Please move these pieces out here in a neststandard library. This should never require any dependency from the asp.net stuff.

[hi-xiaoxin]

.NET Core 2.0 , AspNetCore 2.0 , EFCore 2.0 all published , and odata core ?

[gordon-matt]

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?

[Daniel-Glucksman]

+1

[AlanWong-MS]

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!

[statler]

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

[robward-ms]

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.

[ysmoradi]

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>

[robward-ms]

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

[ysmoradi]

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

[robward-ms]

@ysmoradi - We have a request for splitting parts of WebApi into ODL, #1054. Our thinking at the moment is that this makes sense for certain parts that are not strictly part of the server side, such as model building. That would mean that MS.AspNet.OData" & "MS.AspNetCore.OData would contain the server-side components. In your example, OData.Core would be the thing to reference.

FYI, there is an answer on #1066 which discusses the impact of additional binaries on release management and deployment w.r.t. OData WebApi.

Maybe I'm not fully understanding your example. If not, could you help me better understand?

[rendmath]

When can we expect a first version of OData on ASP.NET Core? Is it the feature/netcore branch?

[ysmoradi]

@robward-ms I've read your comment and I'm satisfied with that. Let's start a journey!

[robward-ms]

@rendmath - From my earlier comment, We hope to have an alpha on NuGet in the next several weeks. Yes, it is accumulating in the feature/netcore branch which got it's first commit yesterday. There are a total of 9 steps/PRs to get current project refactored for the AspNetCore component, I have step 2 in PR now.

[lelong37]

We are super excited for this..! Will this release support EF v6 & EF Core? @TonySneed

[robward-ms]

@lelong37 - For EF Core support, #669. This item only tracks ASP.Net Core support.

[tonysneed]

@robward-ms ASP.NET Core can target either .NET Core (EF Core) or the full .NET Framework (EF 6). (See my demo: https://github.com/tonysneed/Demo.AspNetCore2.EF6.) So you're saying that OData Core will only support .NET Core (EF Core) and not full .NET Framework (EF 6)? /cc @lelong37

[robward-ms]

@tonysneed - I'm trying to say this GitHub issue tracks the ASP.Net core work only. We should track EF in separate issues and #669 is one of those.

[tonysneed]

@robward-ms Got it -- I'll check over there. Thanks!

[ghost]

mh, what about this maintenance-aspnetcore branch? It targets .NetStandard 2.0 and there is a sample project that targets netcoreapp1.0

[robward-ms]

maintenance-aspnetcore is a branch originally forked from the 5.7.0 version of OData WebApi. It has gone through a few changes and the samples may not match the product at this point. The feature/netcore branch will borrow code form there but not necessarily ship in the same form.

Our plan for the feature/netcore branch is to target both AspNetCore 1.x and 2.x as well as AspNet 5.x. To do this, we'd compile OData WebApi as a NetStandard 2.0 dll, a NetStandard 1.3 dll and a net45 dll similar to what's in the existing OData WebApi package.

We'd love some feedback on this plan. Honestly, AspNetCore 1.x is a harder target to hit due to changes in the reflection namespace in NetStandard 1.x but we're trying to be as flexible as possible on our side and accommodate those who want to run on any of these platforms.

Thoughts?

[rogerfar]

Personally I wouldn't bother with AspNetCore 1.x, as there was no official .NET Core release most will migrate from .NET 4.x to AspNetCore 2.

[BruceHunter]

I was going to create a new AspNetCore 2.0 project with OData, but it's not available. I will be skipping AspNetCore 1.x for any projects. I feel that AspNetCore 2.0 is more mature. With OData not being ready, I am disappointed and must go back to creating net45+ projects with OData instead.

[toxik]

I won’t be using AspNetCore 1.x either, but I’m very excited about OData on 2.x !

[ghost]

I also would love to see odata on asp net core 2 without wasting time on asp net core 1.x. I also cannot imagine that there will be many projects that settle on asp net core 1.x with a need for odata.

[grahamehorner]

@jannikb-sim I would suggest that more information would be needed to make that assumption, I personally while using aspnet core 2.0 for web development use .net standard 1.3 & 1.6 for libraries so lesser versions can use them. So in short it the standard that should targeted and if the apis in the standard are available to make it work use the minimum

[ghost]

true, its just an assumption

[lelong37]

Agreed, OData for ASPNetCore v2 should be the focus, would go as far as OData for ASPNetCore v1 not even needed. The reality in the enterprise was really to wait for ASPNetCore v2, being that there was quite the anxiety with the frequency of (breaking) changes for both NetCore, ASPNetCore, EFCore to a arrive @ v1 as well as parallel efforts on .NET Standard API Spec. Now with all things Core v2 release behind us, as well as .NET API v2.0 Specification, think there is a very positive outlook on stability, reliability and the .NET community starting to truly understand the whole .NET Standard API Spec. Last but not least, with many enterprise teams/projects also not making the leap to ASPNetCore v1 due to their dependency on OData being deeply embedded in our architectures as well as being the defacto REST strategy for many of us (kudos to the team, OData is simply awesome and arguably the best way to implement REST architecture, from a REST resource querying perspective with the best implementation of fine granular control of object graph payloads coming across the wire). In short, most teams that are running ASPNetCore v1 obviously aren't using OData anyway. However all teams that have a dependency and are waiting OData before crossing over to ASPNetCore can just make the leap directly to ASPNetCore v2, and why wouldn't they? If your going to cross over, make so the most sense to directly go to v2. @robward-ms @yesman85 @BruceHunter @toxik @jannikb-sim @tonysneed

[cohenomri]

Agreed, we also plan to skip on ASPNetCore 1 and go straight to ASPNetCore 2

On Thu, Sep 28, 2017 at 10:46 AM Long Le notifications@github.com wrote:

Agreed, would really just focus on ASPNetCore v2+, the reality in the enterprise was really to wait for ASPNetCore v2, being that there was quite the anxiety with ASPNetCore alpha making to to official v1 as well as the frequency of (breaking) changes for both NetCore & ASPNetCore to a arrive @ v1. With Core v2 behind us, think there is a very positive outlook on stability and reliability. Last but no least, with many enterprise teams/projects also not making the leap to ASPNetCore due to dependency on OData being deeply embedded in our architectures as well as OData being the defacto REST strategy for many of us. Again, OData for ASPNetCore v2 should realy be the focus that makes the most sense both from timing perspective, community confidence in terms of NETCore, ASPNetCore, EntityFramework Core v2 API and overall stability.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OData/WebApi/issues/939#issuecomment-332756006, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo2WSZIa5RaH-OTuaY8GpocYzZtMoijks5sm07AgaJpZM4MaldT .

[gordon-matt]

Any updates on when the alpha will be ready?

[cohenomri]

+1

On Mon, Oct 2, 2017 at 4:02 AM gordon-matt notifications@github.com wrote:

Any updates on when the alpha will be ready?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/OData/WebApi/issues/939#issuecomment-333419812, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo2Wc2SX5khjzU3wURuNXUDAXbQpubPks5soDYXgaJpZM4MaldT .

[rldjenkins]

+1

Any ETA on even an alpha version? We're using OData extensively and are looking to move a large app of ours to DotNet Core v2 but we're holding off until there's OData support available.

FWIW we're not interested in DotNet Core v1 support either.

[robward-ms]

Thanks for the feedback on AspNetCore v1 vs v2.

Yes, I was a bit vague at the end of August with "We hope to have an alpha on NuGet in the next several weeks". I'm still a few weeks away from having something to test. I think coding-wise I'm 1-2 weeks away from that but I suspect code review will add another week.

The feature/netcore branch now has a compliable AspNet (not core) product dll without tests. Steps 5-8 will add the unit and E2E tests; this work is done and waiting on PRs to complete. 'd like to have this all reviewed and committed by the end of next week.

What's on my dev box is the AspNetCore-specific components for a basic service, which includes model building, routing & formatting. I'm not sure exactly the best way to get these changes through the PR process but I suspect you'll start to see PRs rolling out the week after next (week of Oct 16th). The early stages of those PRs probably won't be functional, I think it might take another week (week of Oct 23rd) to get a functional AspNetCore product in features/netcore.

It will likely be end of Oct/early November before tests and docs for AspNetCore start showing up in PRs.

[wizarrc]

@robward-ms kudos on the transparency! That's exactly the kind of response I like to hear.

[ghost]

@robward-ms sounds aweseome! Thanks for the insights

[rldjenkins]

@robward-ms Thanks for the update - and thanks for all your work. It'll be great to get going with it.

[mxwlf]

+1 on the OData support. I already have a project in mind. How can I help or at least keep myself up to date? I'm already a MSFT Github user so I have passed the onboarding process.

[HaroonSaid]

@robward-ms - Thank you for the transparency. We can plan accordingly on our road map for changes we need to make use .net standard 2.0