WebApi 🚀 - .NET Core Support - IN PROGRESS

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 on 14 Mar 2017

@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

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

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

Thank you !

hi-xiaoxin on 14 Mar 2017

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.

AlanWong-MS on 14 Mar 2017

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

hi-xiaoxin on 15 Mar 2017

+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 on 2 Apr 2017

❤5

@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 on 4 Apr 2017

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

mrns on 6 Apr 2017

@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 on 6 Apr 2017

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

```c#
public static IEdmModel GetConventionModel()
{
var builder = new ODataConventionModelBuilder();
builder.EntitySet("Customers");
builder.EntitySet("Orders");

return builder.GetEdmModel();
}
```

mrns on 7 Apr 2017

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

```c#
app.UseMvc(builder => builder.MapODataRoute("odata", model));

```

mrns on 13 Apr 2017

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?

anton-abyzov on 2 Jun 2017

😕1

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

AlanWong-MS on 2 Jun 2017

👍1

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

raffaeler on 26 Jul 2017

👍1

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

hi-xiaoxin on 15 Aug 2017

👍20

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?

gordon-matt on 15 Aug 2017

👍24

+1

Daniel-Glucksman on 16 Aug 2017

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!

AlanWong-MS on 16 Aug 2017

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

statler on 28 Aug 2017

👍3

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.

robward-ms on 29 Aug 2017

👍15

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 on 30 Aug 2017

👍2

@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 on 31 Aug 2017

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

ysmoradi on 31 Aug 2017

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

robward-ms on 6 Sep 2017

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

rendmath on 7 Sep 2017

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

ysmoradi on 7 Sep 2017

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

robward-ms on 7 Sep 2017

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

lelong37 on 11 Sep 2017

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

robward-ms on 11 Sep 2017

@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

tonysneed on 11 Sep 2017

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

robward-ms on 11 Sep 2017

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

tonysneed on 11 Sep 2017

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

ghost on 21 Sep 2017

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?

robward-ms on 21 Sep 2017

👍1

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.

rogerfar on 21 Sep 2017

👍10 ❤3 🎉3

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.

BruceHunter on 22 Sep 2017

👍3 ❤1

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

toxik on 22 Sep 2017

👍3

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.

ghost on 22 Sep 2017

👍1

@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

grahamehorner on 22 Sep 2017

true, its just an assumption

ghost on 22 Sep 2017

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

lelong37 on 28 Sep 2017

👍14

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
.

cohenomri on 28 Sep 2017

Any updates on when the alpha will be ready?

gordon-matt on 2 Oct 2017

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

cohenomri on 2 Oct 2017

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

rldjenkins on 4 Oct 2017

👍2

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.

robward-ms on 5 Oct 2017

👍11 🎉2

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

wizarrc on 5 Oct 2017

👍4

@robward-ms sounds aweseome! Thanks for the insights

ghost on 5 Oct 2017

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

rldjenkins on 5 Oct 2017

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

mxwlf on 5 Oct 2017

@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

HaroonSaid on 6 Oct 2017

@robward-ms - Could you please let us know the tentative date by when we can expect ALPHA version? Thank you.

kspbhat on 23 Oct 2017

👍14

I'm currently running about 2 weeks behind where I wanted to be. I had planned to start rolling out AspNetCore PRs the week of Oct 16th but they are starting this week instead. 2 PRs to come before AspNetCore code, then it will be in a couple of PRs.

Similar to my comment before, the early stages of those PRs probably won't be functional, I think it might take another week (now week of Nov 6th) to get a functional AspNetCore product in features/netcore. I'm hoping to have an Alpha around the 13th but I may again be too optimistic in getting this code through review and committed.

As of now, the AspNet product is again functional in feature/netcore. We have a build setup and producing nightly packages, you will find the nightly for the AspNet version (NOT AspNetCore) there now: https://www.myget.org/feed/Packages/webapinetcore. When the AspNetCore alpha is ready, it will start showing up here as well.

robward-ms on 31 Oct 2017

👍8 🎉4

Sorry for asking, I currently am in the process of learning the ASP.NET Core stack and still need to wrap my head around a lot of the new things.

I have next to no experience with the old ASP.NET framework, regardless I wanted to get started with OData in ASP.NET Core.

Can I for the time being use the Microsoft.AspNetCore.OData v1.1.0-alpha1 version from NuGet to experiment and learn OData? Is this the version associated with the maintenance-aspnetcore
branch of this repo?

I suppose I'd need to do some migration work as soon as you publish an Alpha package of the feature/netcore branch which wouldn't concern me much since I just use it to learn OData right now.

schnerring on 31 Oct 2017

@ebeeb I would be cautious about that NuGet package. It does not appear to be Microsoft sanctioned as far as I know.

robertmclaws on 31 Oct 2017

@robward-ms Keep up the good work and thank you for the updates!

zoeysaurusrex on 31 Oct 2017

@ebeeb , @robertmclaws is right. While the package is named "Microsoft.AspNetCore.OData", it not actually a Microsoft published package. I believe the code used to build it is a fork from this repo, and it kinda looks like maintenance-aspnetcore, but I can't say for certain if it will help you in this case.

I can say that there is a fair bit of code going into features/netcore that comes from maintenance-aspnetcore but it will not be backwards compatible. I've tried pretty hard to keep the existing API signatures for AspNet in the AspNetCore version but a few things have changes due to API differences between AspNet in the AspNetCore.

robward-ms on 31 Oct 2017

I hvae read the whole thread, but still needs a clarification.

When Odata for ASP.NET Core is published, it will work on .Net full framework only or it could also be run based on .Net Core too? I am going to use OData on a Linux machine that only has .Net Core not .Net full framework.

afsharm on 1 Nov 2017

@afsharm Odata for ASP.NET Core work on netstadard

genusP on 1 Nov 2017

Thank you @genusP for your reply. From net-standard guide, I know that both .Net Core 2.0 and .Net Full Framework 4.6.1 implement .Net Standard 2.0. Which version of net-standard do you mean?

afsharm on 1 Nov 2017

For ASP.NET Core 1.x netstandard1.6 and netstandard2.0 for ASP.NET Core 2.x

genusP on 1 Nov 2017

@robward-ms Thanks for the clarification. Regardless, I'm going to use the Microsoft.AspNetCore.OData package then or try to compile the maintenance branch myself. Backwards compatibility is not really an issue for me and for experimenting only. "Migrating" the demo code will just be a learning experience for me :) Like migrating my Demos from AspNetCore 1.1 to 2.0 was.

Keep up the good work 👍

schnerring on 1 Nov 2017

what I really don't get is why that strict focus to EF? OData is a protocol, it can do a lot, but basically having it for just querying would be fantastic - and having the possibility to query any IQueryable would be even better.

now this was possible via MVC5 API: with a small "fix" just using the EnableQuery attribute we could have OData queries and odata-like output: https://gist.github.com/hidegh/565522d6fab71f2042fc0e145d4ddb8e also case-insensitive mode was possible, althoug for just camleCase a but more code was necessary: https://gist.github.com/hidegh/6f94a671c9a9df05aa02b7baedab051a - still any of the above code was not using EF.

now for MVC6 (full DNX support via 1.0.0-rtm-00015 and now core2.0 suport for 1.0.0-alpha1) the https://www.nuget.org/packages/Microsoft.AspNetCore.OData/ was a nice shot. I was trying to get it work by the simple way, without luck. So only the more complex solution was working for me (full dnx 4.6.*) https://gist.github.com/hidegh/5268a456a170d99e4be6cd0b4692d3c1

so what I do see: we got a nice standard here, but there's no lightweight implementation for it (not to mention missing config if we don't want to have ODataController in MVC5) and so we can't use it for the most basic situations (query) [especially not in MVC6]...

[I still do remember those custom filter I have created with generic type and queryable extensions...]

hidegh on 6 Nov 2017

@genusP , @afsharm - From today's commit, you can see I'll be targeting AspNetCore 2.x using NetStandard 2.0.

robward-ms on 7 Nov 2017

🎉1

@hidegh - I'm a bit confused by your comment, WebApi does work with IQueryable and is not solely focused on EF.

It looks like from your gist's that you are looking for an OData implementation using just an ActionFilter?

robward-ms on 7 Nov 2017

@hidegh If you need (like me) to use the OData syntax outside the context of a web app, you may want to look at my request: https://github.com/OData/WebApi/issues/1054

raffaeler on 7 Nov 2017

@robward-ms Hi, Rob. Yes. Exactly. I do wanna use OData without "extra" configuration (separate odata controller/route). I know OData is capable of much more, but let's admit, basic CRUD operations can be made without OData on a WebAPI. The querying (tables) is the major repetitive work on every project and here is where OData can really shine.

Also what I miss is the way to configure ConventionalModelBuilder (to use camel case) when you just have something like this:

With just such a config:

@raffaeler Actually we do solve both similar issues (even if I do have a focus on WebAPI). Since what odata querying is about is: parsing, applying the parsed values to an IQueryable and returning the result (with count) in an OData like structure (this should be a separate attribute in WebAPI and a separate aspect ~ AOP ~ to run in other kind of solutions).

[final thoughts: it's really a fine community, after contributing with some notes on the EF core, I'm happy to see that this "forum" and people here are so constructive!]

hidegh on 7 Nov 2017

Aren't most of these issues related to RESTier, rather than to OData/WebAPI, strictly speaking?

As far as we are concerned, a port of RESTier to .NET Core is the one and only reason we're following the migration of this library with so much enthusiasm.

rendmath on 7 Nov 2017

@rendmath No, RESTier is an another layer above OData, where based on some URL conventions you get a full CRUD model (simplicistic view). So for RESTier the EF-layer (a way to do writes) is a must.

My proposal is only about querying (reading), with no write operation. As I said it's just parsing the query and applying those values to an IQueryable :D

hidegh on 7 Nov 2017

Frankly, I don't understand why getting Restier on NetCore is such a big deal. You should NOT be building your web APIs into your web apps, you should keep them separate for scalability. I have 9 Restier services in production right now on .NET 4.6.2, being used by .NET Core apps. Separation of concerns, people!

The ONLY benefit you'll get on .NET Core is throughput, or Linux hosting. But Restier still has way too many bugs to worry about cross-platform at the moment.

I just want a shipping version of Restier that is complete, well documented in readable English, doesn't break on $count, and doesn't rely on unit tests to be developer samples.

robertmclaws on 7 Nov 2017

👎1 👍1

@robertmclaws I don't know anything about Restier, but I _can_ tell you that having separate apps is not always an option. It's rarely even a necessity, as most apps don't need to scale.

alexdresko on 7 Nov 2017

@robertmclaws actually the issue is not Core or Full .NET framework with .NET Standard 2 you should be able to be compatible with both. Currently the issues are MVC5 (MVC and WebAPI) layer vs. MVC6 layer (architecture, topology). Both API and RESTier is dependent on the MVC version.

I do share your opinion on scaling, this is why:

OData lib should be build as .NET standard
OData query and OData save should be splitted (especially in the non RESTier version)...
...Both MVC5 and MVC6 standard (so core and full) should be supported. Since RESTier is also "API" and routing (another layer above OData)they both need support for MVC5 (Api) and MVC6...

@alexdresko I haven't used RESTier, but try to look at it as an extension/layer over OData, which simply enables you to do CRUD operations, with some standardized URLs (by conventions) without extra code. I do really prefer querying and custom create/update/delete ... but must admit, RESTier and it's URL conventions should be used in any API Routes (some people are really bad at creating meaningful URL names :D)

hidegh on 7 Nov 2017

@hidegh I understand what the current issues are. As I mentioned, I have 9 Restier apps in production.

OData lib is ALREADY built as .NET Standard.
No, OData query and OData save should not be "split". They're both part of the same resource.
MVC 6 is not actually a thing.

Microsoft is already working on a version that works on ASP.NET 4 and ASP.NET Core 2. So I'm not sure why everyone here is arguing the benefits for it when it is already happening. Just have some patience.

Regarding your issue with boilerplate code, that's what Restier is for. Restier = WCF Data Services ++. If you don't like the way they do it, you should build your own framework. But honestly, the URL and query structure are already part of an open standard, so good luck getting people to use something else.

Straight up, just being honest, it sounds like you need to read the spec and understand the tooling a bit better, because the way you phrased your post on the "strict focus on EF" shows that you don't really understand how WebAPI+OData works... yet you're trying to explain it incorrectly to everyone else.

robertmclaws on 7 Nov 2017

@robertmclaws OData is .NET standard, right, know it - and OData itself is OK. Do you have any direct/live links on the OData MVC6 integration from Microsoft?

Here we are in the OData/WebAPI forum. And while we got a Microsoft.AspNet.OData for MVC5 WebAPI we still not have other than a Microsoft.AspnetCore.OData for MVC6 with a single contributor (reason people are asking MVC6 support here are related to MVC integration, not directly with the OData lib). BTW: right for this kinda of integration have I suggested the split between core with query and write operations on the solution over that MVC layer (what most coders would use from OData is querying first - to remove any repetitive or custom code just to have filterable tables) - just to have something at hand sooner - and IMO querying over an IQueryable<> (since I did in the past custom code for it) is much more simpler than the rest...

hidegh on 7 Nov 2017

@hidegh yes, I am also already using oData out of context, but currently you still have unwanted dependencies and the code must "simulate" a web call to make the transformation from string to expression happnen ... too bad.
But I really hope the team is working in the direction to totally decouple these pieces and allowing to use the various oData pieces indpendently from asp.net(traditional or core). This is why I opened that issue (and another one to make expression trees better looking and with no use of private types).
Good luck ;)

raffaeler on 7 Nov 2017

@robertmclaws I agree with you that getting RESTier on .NET Core is not, by itself, such an important goal. Our actual hope is that, once OData is moved to .NET Core, Microsoft will dedicate more resources to RESTier, and finally get us to a stable and well-documented v1.0.

rendmath on 9 Nov 2017

@robertmclaws i've had a private conversation, and must admit, @raffaeler is right, basic OData lib is not able to "extract expressions from an odata string. It is not even enough to easily create a model with the ConventionalModelBuilder. Once you add the reference to the Microsoft.Aspnet.OData, you get a lot of unwanted dependencies (and lose the opportunity to run on netcore).".

hidegh on 9 Nov 2017

@rendmath I believe that is the plan. They're moving up the stack: revising, refactoring, and prepping for .NET Core support. Once that is in place, a shipping Restier should be able to run on either platform.

It may take a little extra engineering work to get there, though. And a LOT of extra documentation work.

robertmclaws on 9 Nov 2017

👍1

odata

hi-xiaoxin on 10 Nov 2017

👍1

@xiaoxin1983 there is no mvc6?

alexzaytsev-newsroomly on 10 Nov 2017

@xiaoxin1983 This is an interesting conceptual design, but there are a lot of mistakes. MVC6 is not a thing it should be MVC5, WCF is not supported anymore, neither are XML payloads. Restier should be right next to MVC5, and cover both MVC 5 And MVC Core.

Instead of "others" you might consider replacing that with "POCOs", as really you can query over any object, doesn't matter how that object is materialized.

HTH!

robertmclaws on 10 Nov 2017

MVC6 has been renamed to just MVC for AspNetCore and so far has aligned with the versions for AspNetCore. My understanding is that the version has reset as it's a different (core) product. In Nuget it's referred as Microsoft.AspNetCore.Mvc.Core 2.0.0.

wizarrc on 10 Nov 2017

Guys, all these conceptual things are very nice and important. But. Here we are, simple programmers, who still can not use ASP.NET Core because OData support is not here yet. I'm now starting 3rd project in a row and I have to select the old ASP.NET just because of lack of OData support. Is not this shame?

Why not you release something working for us, simple people. Something ugly in design, but working. Then you can spend all time you need polishing designs.

I know all I'm saying here is not very polite. But. Situations like this one are what may result in CORE endeavor failing. It is really-really strange that MS does not understand this simple fact.

dmytro-gokun on 10 Nov 2017

👍1

@dmytro-gokun First, I think you mean WebApi support for OData as OData does work with dotnet core. The main problem is that MVC and WebApi merged into one product for ASP.Net Core. WebApi for OData relied heavily on an architecture that no longer exists in the core products and has to be redesigned. It would be very costly to have designed this earlier when the product was changing, and I'm sure they didn't want to delay the shipping of dotnet core to align these products. I know I didn't.

I personally looked at the early ports of OData WebApi to ASP.NET core and made it work for my own project but it was very buggy and a mess IMO. You could have done that yourself if you wanted to. There was even unofficial Nuget packages out there that took snapshots of their progress if you were brave. So yes, you can do that but I wouldn't recommend it.

wizarrc on 10 Nov 2017

Hi , yes i make a mistake , i was thinking mvc5, but typed mvc6 .

i think odata lib or odata webapi can be a framework ,then it can connect many data provider like ef, and connect many http request provider like aspnetcore. it just provide exchange power:

transfer data ( json -> edmObject -> clr object）
transfer metadata ( xml -> edmModel -> IModel（efcore）
transfer expression（querystring -> edmExpression -> lambdaExpression）

and then odata provide some default Implements（aspnetcore ,efcore）

FYI

hi-xiaoxin on 10 Nov 2017

~~Alright guys, I'm sorry to have to do this, but I'm locking this conversation for now, as it is distracting from the work that is being done.~~ Unlocking the thread but changed the title of the issue. I would close this bug, but the work is not actually done yet.

For like the 5000th time, OData for .NET Core is _in progress right now_, and ALMOST FINISHED.

Imagine the engineering that is going on right now, building a system that is compatible with two disparate frameworks. Microsoft isn't updating ANYTHING ELSE in ASP.NET 5.2.3, _except for this_.

So instead of whining that you've had to use the "old" ASP.NET for OData stuff (when in a cloud-based world, you should be splitting your APIs from your UI code ANYWAYS) try spending a few minutes cheering on the team getting the work done.

Because Microsoft could have very easily killed this project and left us all high and dry.

robertmclaws on 10 Nov 2017

👍17 🎉3 ❤2

@robertmclaws you make a good point with regards UI & API separation; but I would be very surprised if Microsoft killed the project given the number of there products using OData both internally/externally and in azure ;)

I believe we all know that the Microsoft Teams are working hard to achieve this, I'm wondering if all the development will be open source ? if so would it be of benefit to allow the community to help with development/testing/documentation etc.

grahamehorner on 10 Nov 2017

@grahamehorner You shouldn't be surprised. It almost happened. And the work _already is_ open source, it's happening on other branches in this repository.

robertmclaws on 10 Nov 2017

👍1

Just wanted to drop a shoutout to @robertmclaws @robward-ms and all the other folks working to make this possible. I've been in the saddle so many times before, being part of a group that was reassembling a 747 mid-flight. You gals and guys working on this are fantastic. Keep it up!!!

zoeysaurusrex on 13 Nov 2017

👍9 ❤2

Hello there,

just a little tactical whine to make sure if it's almost finished like for the past half-year.

Cheers.

JanKonopka on 21 Nov 2017

❤4 😕2 🎉2 👍2

odata .net core will drop on Christmas Monday, December 25.. Microsoft loves to do stuff like that..

AlexanderBatista on 21 Nov 2017

👎2 👍1

Hi Guys,
It would be great if we know the approximate time for the beta version. Thanks for your hard work!

KrzysztofPajak on 21 Nov 2017

👍5 ❤3 🎉3 😄3

@AlexanderBatista, it is reliable information or your assumption?

djuuuuus on 22 Nov 2017

😄2

@djuuuuus It's definitely not reliable information, and if @AlexanderBatista made an assumption, it's a poor one. I've been in this business 20 years, and AFAIK Microsoft has never dropped bits on the holidays; they are always OOF for the last two weeks of the year. There may be occasional exceptions for Windows Insider builds, but not usually. Some teams save up their vacation time and take the whole month of December off.

If it's not out by December 15th, it won't be out until January 15th, at the earliest. That's pretty standard for Microsoft stuff.

@KrzysztofPajak As for timelines, you should set your expectations that it will be out in mid-January. If they get to it sooner, great. But the next 4 days are a holiday, then you have 15 working days until Christmas. Watching the work that is being done, I just don't think it will be ready by then.

Trust me, you want them to be as thorough about this as possible. And we need a robust enough Beta to be able to track down and fix bugs.

Once again, this is not official communication, just my educated observations from getting every single GitHub e-mail about this project, HTH!

robertmclaws on 22 Nov 2017

👍4

Just wanted to say I am eagerly awaiting Odata for .net core.

TonyValenti on 28 Nov 2017

Do I have to compile this or is there a build I can Nuget?

On Thu, Nov 30, 2017 at 6:38 AM Yan notifications@github.com wrote:

Beta odata net core https://github.com/OData/WebApi/tree/feature/netcore

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

>

Tony Valenti

TonyValenti on 30 Nov 2017

@djuuuuus Doesn't know what he's talking about. There is no beta, yet.

alexdresko on 30 Nov 2017

👍2

@alexdresko @djuuuuus has dashed my hopes :'( not nice when everyone is working flat out to have someone post an untruth about a work-in-progress getting release in any form; especially during a period when a lot of the team is having a holiday period

grahamehorner on 30 Nov 2017

You guys are taking the obvious sarcasm way too seriously.

Kudos to the team working on this, its a complex project. There is a little bit of over promise and under deliver regarding ETA here, but the team is trying to leave you a little hope, due to being just as eager to get it out the door. Its a shame they get bit by trying to be more transparent.

If we want something to really complain at Microsoft about for dropping the ball, it would be a Xaml designer for Xamarin Forms and SkiaSharp. I don't see anywhere near that level of negligence with odata.

dapug on 30 Nov 2017

@djuuuuus - https://github.com/OData/WebApi/tree/feature/netcore is a bit less than Alpha at this point, the current PR (#1138) helps that quite a bit though.

@TonyValenti - for https://github.com/OData/WebApi/tree/feature/netcore, you have to compile it yourself at this point. However, without the current PR (#1138), it's not terrible functional.

@dapug - Thanks for the support.

@robertmclaws is spot-on w.r.t. to scheduling. We don't plan to release over Christmas.

Sorry I've been silent for a while, The current PR, #1138, will bring OData for AspNetCore to an Alpha state. I've got more than 60% of the UTs running but not passing all tests (as of right now, 183 failed & 5146 pass). My plan is to commit #1138 tomorrow morning, then put another PR with some cleanup (FxCop + doc comments) and Nuget packaging. I plan to commit that tomorrow (maybe the weekend) as well and start publishing the Alpha on myget: https://www.myget.org/feed/Packages/webapinetcore

My current plan is to release an Alpha on MyGet by Monday Dec 4th and a Beta version of AspNetCore on Nuget on Dec 15th.

robward-ms on 30 Nov 2017

👍11 🎉5 ❤3

@robward-ms I can’t say it enough, you and everyone involved in this effort rock. Cannot thank you enough. As a show of support, when the beta drops I’m going to give up my Saturday to try and build something functioning to help certify it.

zoeysaurusrex on 30 Nov 2017

👍6

@wmccullough @robward-ms I’ll be doing something also as a learning/testing excersie when the beta drops 🤔 😎 as I’ve got a few odata client components that have integration tests with classic asp.net odata which I’ll be updating and will feedback

grahamehorner on 30 Nov 2017

@robward-ms Thank you very much for your great work and also for the information you provided regarding the timeline. Knowing these dates, we can move forward and plan our projects more accurately. I really appreciate it.

Mollaee on 1 Dec 2017

👍2

The AspNetCore alpha package is available here: https://www.myget.org/F/webapinetcore/

Feel free to file issues but please mark them as AspNetCore, either with [feature//netcore] in the title (like #1134) or by applying the feature/netcore label.

There is no docs or samples yet, here is an example Startup class:

public class Startup
{
    public Startup() {}
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOData();
        services.AddSingleton<SampleContext>();
    }

    public void Configure(IApplicationBuilder app)
    {
        IEdmModel model = GetEdmModel(app.ApplicationServices);
        app.UseMvc(routeBuilder => routeBuilder.MapODataServiceRoute("name", "prefix", model));
    }

    private static IEdmModel GetEdmModel(IServiceProvider serviceProvider)
    {
        var builder = new ODataConventionModelBuilder(serviceProvider);
        ...
        return builder.GetEdmModel();
    }

robward-ms on 2 Dec 2017

👍3

For anyone having problems with the myget URL mentioned above... Here you go: https://www.myget.org/F/webapinetcore/

gordon-matt on 2 Dec 2017

I created a new project to try this out and only 1 ODataController. However, I keep getting a NotImplementedException on startup. The stack trace is as follows:

    Microsoft.AspNet.OData.FromODataUriAttribute.get_BindingSource()
    Microsoft.AspNetCore.Mvc.ModelBinding.BindingInfo.GetBindingInfo(IEnumerable<object> attributes)
    Microsoft.AspNetCore.Mvc.Internal.DefaultApplicationModelProvider.CreateParameterModel(ParameterInfo parameterInfo)
    Microsoft.AspNetCore.Mvc.Internal.DefaultApplicationModelProvider.OnProvidersExecuting(ApplicationModelProviderContext context)
    Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.BuildModel()
    Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.GetDescriptors()
    Microsoft.AspNetCore.Mvc.Internal.ControllerActionDescriptorProvider.OnProvidersExecuting(ActionDescriptorProviderContext context)
    Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.UpdateCollection()
    Microsoft.AspNetCore.Mvc.Internal.ActionDescriptorCollectionProvider.get_ActionDescriptors()
    Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.GetTreeRouter()
    Microsoft.AspNetCore.Mvc.Internal.AttributeRoute.RouteAsync(RouteContext context)
    Microsoft.AspNetCore.Routing.RouteCollection+<RouteAsync>d__9.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Builder.RouterMiddleware+<Invoke>d__4.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Authentication.AuthenticationMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware+<Invoke>d__4.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware+<Invoke>d__7.MoveNext()

Even if I remove the new code in the Startup class, the error continues.

gordon-matt on 2 Dec 2017

If you need further details, here you go:

My ODataController:

public class PublicUserApiController : ODataController
    {
        private readonly ApplicationDbContext context;

        public PublicUserApiController(ApplicationDbContext context)
        {
            this.context = context;
        }

        public virtual IEnumerable<PublicUserInfo> Get(ODataQueryOptions<PublicUserInfo> options)
        {
            var settings = new ODataValidationSettings()
            {
                AllowedQueryOptions = AllowedQueryOptions.All
            };
            options.Validate(settings);

            var query = context.Users
                .Select(x => new PublicUserInfo
                {
                    Id = x.Id,
                    UserName = x.UserName
                });

            var results = options.ApplyTo(query);
            return (results as IQueryable<PublicUserInfo>).ToHashSet();
        }

        public virtual async Task<PublicUserInfo> Get([FromODataUri] string key)
        {
            var entity = await context.Users.FindAsync(key);
            return new PublicUserInfo
            {
                Id = entity.Id,
                UserName = entity.UserName
            };
        }
    }

    public class PublicUserInfo
    {
        public string Id { get; set; }

        public string UserName { get; set; }
    }

And the Startup class:

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.AddDbContext<ApplicationDbContext>(options =>
                options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

            services.AddIdentity<ApplicationUser, IdentityRole>()
                .AddEntityFrameworkStores<ApplicationDbContext>()
                .AddDefaultTokenProviders();

            // Add application services.
            services.AddTransient<IEmailSender, EmailSender>();

            services.AddOData();

            services.AddMvc();
        }

        // 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.UseBrowserLink();
                app.UseDatabaseErrorPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }

            app.UseStaticFiles();

            app.UseAuthentication();

            var edmModel = GetEdmModel(app.ApplicationServices);

            app.UseMvc(routes =>
            {
                routes.MapODataServiceRoute("OData_Kore_Web", "odata/kore/web", edmModel);

                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }

        private static IEdmModel GetEdmModel(IServiceProvider serviceProvider)
        {
            var builder = new ODataConventionModelBuilder(serviceProvider);

            builder.EntitySet<PublicUserInfo>("PublicUserApi");

            return builder.GetEdmModel();
        }
    }

All I did was create a new ASP.NET Core app with the "Individual User Accounts" option for authentication and then added the ODataController and made the few changes in the Startup class as above. Oh, and I also updated all nuget packages to the latest if that makes any difference. That should be about it really. Nothing weird.

gordon-matt on 2 Dec 2017

@gordon-matt - the FromODataUriAttribute is on the TODO list, it's not implemented yet: https://github.com/OData/WebApi/blob/feature/netcore/src/Microsoft.AspNetCore.OData/FromODataUriAttribute.cs

I filed this issue: #1142

Also, thanks for the correct link for subscribers, the link I used is for owners. I update my original message with your link.

robward-ms on 2 Dec 2017

hi there, im glad there is finally an pre alpha to to try +1.

i have one issue:

using swagger fails InvalidOperationException: No media types found in Microsoft.AspNet.OData.Formatter.ODataInputFormatter.SupportedMediaTypes

Edit:

this is solved:
EnableQueryAttribute throws while triing to get IEdmModel from DI
returning ok() with IQueryable throws while triing to get ODataSerializerProvider

i had to remove this from my controller:
[Route("odata/Companies")]
after removing the attribute swagger has more problems:
Multiple actions matched. The following actions matched route data and had all constraints satisfied:
Playground.core.Controllers.CompaniesController.GetSingleCompany (Playground.core)
Playground.core.Controllers.SitesController.GetSingleSite (Playground.core)

and finally:

should the namespace really be Microsoft.Aspnet.Odata id expected Microsoft.AspnetCore.Odata

If you need repro here is my code: https://github.com/JanEggers/Playground/tree/odata

anyway really good work keep PR comming!

JanEggers on 2 Dec 2017

@JanEggers - I looked at your repo, I wanted to clarify: commit 5b50b08aaa7c819af5473e3571b73ebcf04fe0b8 fully fixes the issues you were seeing?

For the namespace, yep we're planning on a single namespace for both products and landed on Microsoft.Aspnet.Odata for back-compat reasons: back-compat is increased if shared and AspNet use a single namespace, making a 6->7 upgrade a NS change only and partial classes need to also use the shared NS so I went with Microsoft.Aspnet.Odata wholesale.

We have considered dual namespaces but that would require that the common code has #if for using's & namespaces and increases the likelihood that making a change in shared core REQUIRES editing both AspNet and AspNet core projects; it's possible to make a shared code change in only one project now and use the command-line build to verify the other change without opening both projects. In short, dual namespaces will increase code maintenance cost.

I'd love to get some feedback on the NS issue.

robward-ms on 2 Dec 2017

fully fixes the issues you were seeing?

nope. using /swagger still produces InvalidOperationException: No media types found in Microsoft.AspNet.OData.Formatter.ODataInputFormatter.SupportedMediaTypes

im currently looking at https://github.com/rbeauchamp/Swashbuckle.OData maybe i can provide a pullrequest there to support AspnetCore.Odata

JanEggers on 3 Dec 2017

@JanEggers - Ah, I do have a bit more work in Formatting. including refactoring and media type mappings. You may be seeing a limitation of the Alpha. I filed #1144

robward-ms on 4 Dec 2017

thx again for your efforts

JanEggers on 4 Dec 2017

@JanEggers I have been looking at your OData branch of your playground application and was wondering if you have come across any errors/issues around using "$select", "$count" and "$top".

Here are some example URL's and errors I am getting:

http://localhost:63980/odata/TestResult?$count=true

{
    "@odata.context": "http://localhost:63980/odata/$metadata#Edm.String",
    "value": "The query specified in the URI is not valid. Unable to resolve service for type 'Microsoft.AspNet.OData.Query.DefaultQuerySettings' while attempting to activate 'Microsoft.AspNet.OData.Query.Validators.CountQueryValidator'."
}

http://localhost:63980/odata/TestResult?$top=1

{
    "@odata.context": "http://localhost:63980/odata/$metadata#Edm.String",
    "value": "The query specified in the URI is not valid. No service for type 'Microsoft.AspNet.OData.Query.DefaultQuerySettings' has been registered."
}

http://localhost:63980/odata/TestResult?$select=Id

I get a stack trace

System.ArgumentException: The type 'Edm.String' is not an entity type. Only entity types support $select and $expand.
Parameter name: context

When hitting the following URLs It works as expected e.g.

http://localhost:63980/odata/TestResult

{
    "@odata.context": "http://localhost:63980/odata/$metadata#TestResult",
    "value": [
        {
            "TestId": 0,
            "ParticipantId": 8,
            "StartedAt": "2017-12-04T13:16:24Z",
            "EndedAt": "2017-12-04T13:16:30Z",
            "Id": 0,
            "DeletedOn": null
        },
        {
            "TestId": 0,
            "ParticipantId": 9,
            "StartedAt": "2017-12-04T13:16:24Z",
            "EndedAt": "2017-12-04T13:16:30Z",
            "Id": 1,
            "DeletedOn": null
        }
    ]
}

After some googling I added the following to the StartUp file

        private static IEdmModel GetEdmModel(IServiceProvider serviceProvider)
        {
            var builder = new ODataConventionModelBuilder(serviceProvider);
            var es = builder.EntitySet<TestResult>(nameof(FDbContext.TestResult));
            builder.EntityType<TestResult>()
            .Count().Filter().OrderBy().Expand().Select(); //This line is aaded for $select, $count,$filter, $top and $select
            return builder.GetEdmModel();
        }

I then added

    [Count]
    [Select]
    [Filter]

To the TestResult class.

I am using the following setup

Dotnet Core on Windows (2.0.0)
Microsoft.AspNetCore.OData (v7.0.0-Nightly201712020210)
Entity Framework

I have had a look at the following links and tried them and still no difference.

https://stackoverflow.com/questions/39515218/odata-error-the-query-specified-in-the-uri-is-not-valid-the-property-cannot-be
http://odata.github.io/WebApi/#13-01-modelbound-attribute
Has anyone else seen issues like this?

lemex92 on 4 Dec 2017

@robward-ms Thank you so much for all the hard work this holiday season. great work and thanks regarding the timeline. I think everyone here really appreciates the work being done

AlexanderBatista on 4 Dec 2017

👍5 🎉1

@lemex92 i just verified your findings and jup all queries are not working because DefaultQuerySettings are not registered.

it will take some time to get all the goodness back to working state

JanEggers on 4 Dec 2017

Awesome, For now, I think we are just going to use the .NET Framework for our OData API and use .NET Core for the rest of our application.

Once .NET Core has the full OData functionality we will switch back. Do you have any recommendations/resources on sharing our data/model project between .net core and standard .net?

lemex92 on 4 Dec 2017

Am I screwing up my config somehow? I keep getting an error related to ODataQueryOptions binding.

'''
InvalidOperationException: Could not create an instance of type 'Microsoft.AspNet.OData.Query.ODataQueryOptions`1[[Proj.Data.Entities.Resource, Proj.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]'. Model bound complex types must not be abstract or value types and must have a parameterless constructor.
'''

kyse on 4 Dec 2017

Nope, it's not you, it's me. I'll have a PR & build for it in a bit.

robward-ms on 4 Dec 2017

Thanks, glad to see this making headway. I appreciate you an your work here. :)

kyse on 4 Dec 2017

@kyse - Thanks for testing and your patience. I had to lines of code in ODataRouteBuilderExtensions.cs that I thought were not needed but when missing caused about 1300 test failures. I don't have tests in feature/netcore yet so I'm trying to keep feature/netcore and my dev branch (where I have about 70% of the UTs passing) synced manually. #1148 converges them and resolves this issue with a temporary fix. I'll have a new package on MyGet later today.

robward-ms on 4 Dec 2017

👍1

@kyse - This fix is in Nightly201712042322 on MyGet.

robward-ms on 5 Dec 2017

I think what I'm seeing is more related to ODataQueryOptions constructor not ODataOptions, doesn't appear your changes helped me. I didn't see anything related to model binding in your example above, I've got to be missing something obvious.

kyse on 5 Dec 2017

@kyse - Do you have a larger call stack or sample?

robward-ms on 5 Dec 2017

System.InvalidOperationException: Could not create an instance of type 'Microsoft.AspNet.OData.Query.ODataQueryOptions`1[[Proj.Data.Entities.Resourcec, Proj.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]'. Model bound complex types must not be abstract or value types and must have a parameterless constructor.
   at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder.CreateModel(ModelBindingContext bindingContext)
   at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder.<BindModelCoreAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.<BindModelAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeInnerFilterAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeNextResourceFilter>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeFilterPipelineAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.SpaServices.Webpack.ConditionalProxyMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.SpaServices.Webpack.ConditionalProxyMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext()

Is

kyse on 5 Dec 2017

@kyse - Can you share your controller code?

robward-ms on 5 Dec 2017

using System.Collections.Generic;
using System.Linq;
using Proj.Data;
using Proj.Data.Entities;
using Microsoft.AspNet.OData;
using Microsoft.AspNet.OData.Query;

namespace Proj.Server.Controllers.odata
{
    public class ResourceController : ODataController
    {
        private readonly ApplicationDbContext _context;

        public ResourceController(ApplicationDbContext context)
        {
            _context = context;
        }

        public virtual IEnumerable<Resource> Get(ODataQueryOptions<Resource> options)
        {
            var settings = new ODataValidationSettings()
            {
                AllowedQueryOptions = AllowedQueryOptions.All
            };
            options.Validate(settings);

            var query = _context.Resources;

            var results = options.ApplyTo(query);
            return (results as IQueryable<Resource>).ToHashSet();
        }

        // Pending FromODataUri implementation - https://github.com/OData/WebApi/issues/1142
        //public virtual async Task<ApplicationUser> Get([FromODataUri] string key)
        //{
        //    var entity = await _context.Users.FindAsync(key);
        //    return new ApplicationUser
        //    {
        //        Id = entity.Id,
        //        UserName = entity.UserName
        //    };
        //}
    }
}

kyse on 5 Dec 2017

@kyse - Thanks. It caused by ODataQueryParameterBindingAttribute not being implemented, I filed #1149.

ODataQueryOptions is marked with that attribute to get it from dynamically from the request. Since it's not yet implemented, AspNetCore looks for it in the dependency injection container, hence the failure.

robward-ms on 5 Dec 2017

Thanks for all the work you're doing. I'm having issues trying to get anything at all to work though. Using my example in a comment above, I kept getting a 404. I updated to the latest fix that you deployed and now it's an HTTP 500 error instead. This is the message:

InvalidOperationException: Could not create an instance of type 'Microsoft.AspNet.OData.Query.ODataQueryOptions1[[OData_Test.Controllers.OData.PublicUserInfo, OData_Test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]'. Model bound complex types must not be abstract or value types and must have a parameterless constructor.`

That class is not abstract and I don't see a problem with the constructor, since I haven't specified any and it would thus use a default constructor:

public class PublicUserInfo
{
    public string Id { get; set; }
    public string UserName { get; set; }
}

EDIT: Sorry for duplicate error... I just noticed @kyse has the exact same error

gordon-matt on 5 Dec 2017

Hi All,
I have a desktop app (not a web app) that is using EF Core and is exposing lots if its data through an HTTPListener. How would I expose an OData endpoint using an HTTPListener?

TonyValenti on 6 Dec 2017

Hi,
I can't use specific form attribute "FromBody" in ODataController. After sent request my parameter always has null.

KrzysztofPajak on 12 Dec 2017

Class track changes "Delta" doesn't work in ODataController.

KrzysztofPajak on 12 Dec 2017

@KrzysztofPajak -

The "FormBody" issue is fixed in the latest PR but it's not checked in yet: #1157

For Delta, could you file an issue?

robward-ms on 12 Dec 2017

Just got the latest version. I no longer have the InvalidOperationException regarding the parameterless constructor, but now there is a new exception instead, as follows:

SocketException: The attempted operation is not supported for the type of object referenced
System.Net.IPAddress.get_Address()

Stack Trace:

    System.Net.IPAddress.get_Address()
    Microsoft.Extensions.Internal.PropertyHelper.CallNullSafePropertyGetter<TDeclaringType, TValue>(Func<TDeclaringType, TValue> getter, object target)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationEntry.get_Model()
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitChildren(IValidationStrategy strategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitComplexType(IValidationStrategy defaultStrategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitChildren(IValidationStrategy strategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitComplexType(IValidationStrategy defaultStrategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitChildren(IValidationStrategy strategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitComplexType(IValidationStrategy defaultStrategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitChildren(IValidationStrategy strategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitComplexType(IValidationStrategy defaultStrategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitChildren(IValidationStrategy strategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.VisitComplexType(IValidationStrategy defaultStrategy)
    Microsoft.AspNetCore.Mvc.ModelBinding.Validation.ValidationVisitor.Visit(ModelMetadata metadata, string key, object model)
    Microsoft.AspNetCore.Mvc.Internal.DefaultObjectValidator.Validate(ActionContext actionContext, ValidationStateDictionary validationState, string prefix, object model)
    Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder+<BindModelAsync>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider+<>c__DisplayClass0_0+<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker+<InvokeInnerFilterAsync>d__14.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+<InvokeNextResourceFilter>d__22.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
    Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted)
    Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+<InvokeFilterPipelineAsync>d__17.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+<InvokeAsync>d__15.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Builder.RouterMiddleware+<Invoke>d__4.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Authentication.AuthenticationMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware+<Invoke>d__4.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware+<Invoke>d__6.MoveNext()
    System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware+<Invoke>d__7.MoveNext()

gordon-matt on 13 Dec 2017

@gordon-matt - Could you open a new issue and possible supply a link to a repo project?

robward-ms on 13 Dec 2017

@robward-ms Thanks for the response. If you look at my post from 12 days ago you will find all you need right there (very basic usage). Let me know if you still prefer a separate issue to be opened and I'll be happy to do so.

EDIT: I just uploaded the test project. Here's the link: OData_Test
To see the problem, just run it and browse to: /odata/PublicUserApi

gordon-matt on 13 Dec 2017

@gordon-matt - I did look back and scanned the code again and did not see anything that looks out of place. Yes, please file an issue so we can track it's status somewhere other than here, since this issue will likely get closed once the Nuget package is available. From then on, issues will be the best place to track things.

robward-ms on 14 Dec 2017

@robward-ms Done as requested. See Issue #1165

gordon-matt on 14 Dec 2017

Time for a status update. 15 days ago I said:

My current plan is to release … a Beta version of AspNetCore on Nuget on Dec 15th.

Well, it’s the 15th but sadly I don’t think the code is ready for Beta. I’m done with all the code that I know needs to be written except for Batching (it’s in progress). However, I don’t have good validation yet. I’m close enough to getting E2E test running that I think I’ll be done next week.

A few folks have picked up the Alpha and reported back, mostly with issues. Some of those have been fixed but not all. There has not been a lot of feedback saying ”It works great!” so some other form of validation is needed for Beta.

I do have unit tests running, about 90% with ~ 2% fail rate. There are about 7600 UTs so that’s just under 900 tests that are either not running or failing. Since UTs are not great at measure real world scenarios and 900 tests is kind of a lot of tests, the UTs don’t provide good validation at this point.

My plan has been to get the E2E test suite running on AspNetCore. I’ve been working on the E2E tests all week and last night I was able to get one running for AspNetCore, which is promising. However, I don’t have enough of them running to get any real validation of the code.

In short, the code is written and checked in, it certainly has bugs but the total number is still a bit of a mystery. Until I clear that up, a Beta would just be an Alpha with a different name.

robward-ms on 16 Dec 2017

👍12

@robward-ms do you have plans to address #1054 and #1055 in the upcoming beta?
Specifically the #1054 it would be hard to do later.

raffaeler on 16 Dec 2017

@robward-ms great update thanks, really good to have this type of info about the development; keep up the good work guys and gals. Is there any plan on the roadmap for optimisation and performance testing with the kestrel team for TecEmpower benchmarks?

grahamehorner on 16 Dec 2017

👍3

This is one of the best progress reports I’ve ever seen. Reports like this
make us deeply appreciate your effort and completely back your decision to
not release a beta quite yet.

Great job on the progress thus far.

On Sat, Dec 16, 2017 at 4:49 AM Grahame Horner notifications@github.com
wrote:

@robward-ms https://github.com/robward-ms great update thanks, really
good to have this type of info about the development; keep up the good work
guys and gals. Is there any plan on the roadmap for optimisation and
performance testing with the kestrel team for TecEmpower benchmarks?

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

>

Tony Valenti

TonyValenti on 16 Dec 2017

👍5 ❤2

Hi,
I am trying to do some test with the package but just getting error:

`An unhandled exception occurred while processing the request.
InvalidOperationException: No service for type 'Microsoft.AspNet.OData.Formatter.Serialization.ODataSerializerProvider' has been registered.
Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
Stack Query Cookies Headers
InvalidOperationException: No service for type 'Microsoft.AspNet.OData.Formatter.Serialization.ODataSerializerProvider' has been registered.
Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider)
Microsoft.AspNet.OData.Formatter.Serialization.ODataSerializerProviderProxy.GetODataPayloadSerializer(Type type, HttpRequest request)
Microsoft.AspNet.OData.Formatter.ODataOutputFormatterHelper.GetClrObjectResponsePayloadKind(Type type, bool isGenericSingleResult, Func getODataPayloadSerializer)
Microsoft.AspNet.OData.Formatter.ODataOutputFormatterHelper.CanWriteType(Type type, IEnumerable payloadKinds, bool isGenericSingleResult, IWebApiRequestMessage internalRequest, Func getODataPayloadSerializer)
Microsoft.AspNet.OData.Formatter.ODataOutputFormatter.CanWriteResult(OutputFormatterCanWriteContext context)
Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.SelectFormatterNotUsingContentType(OutputFormatterWriteContext formatterContext, IList formatters)
Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.SelectFormatter(OutputFormatterWriteContext formatterContext, MediaTypeCollection contentTypes, IList formatters)
Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.ExecuteAsync(ActionContext context, ObjectResult result)
Microsoft.AspNetCore.Mvc.ObjectResult.ExecuteResultAsync(ActionContext context)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+d__19.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+d__24.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResultExecutedContext context)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+d__22.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(ref State next, ref Scope scope, ref object state, ref bool isCompleted)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+d__17.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker+d__15.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Builder.RouterMiddleware+d__4.MoveNext()
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware+d__7.MoveNext()

Show raw exception details
System.InvalidOperationException: No service for type 'Microsoft.AspNet.OData.Formatter.Serialization.ODataSerializerProvider' has been registered.

at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)

at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredServiceT

at Microsoft.AspNet.OData.Formatter.Serialization.ODataSerializerProviderProxy.GetODataPayloadSerializer(Type type, HttpRequest request)

at Microsoft.AspNet.OData.Formatter.ODataOutputFormatterHelper.GetClrObjectResponsePayloadKind(Type type, Boolean isGenericSingleResult, Func`2 getODataPayloadSerializer)

at Microsoft.AspNet.OData.Formatter.ODataOutputFormatterHelper.CanWriteType(Type type, IEnumerable1 payloadKinds, Boolean isGenericSingleResult, IWebApiRequestMessage internalRequest, Func2 getODataPayloadSerializer)

at Microsoft.AspNet.OData.Formatter.ODataOutputFormatter.CanWriteResult(OutputFormatterCanWriteContext context)

at Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.SelectFormatterNotUsingContentType(OutputFormatterWriteContext formatterContext, IList`1 formatters)

at Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.SelectFormatter(OutputFormatterWriteContext formatterContext, MediaTypeCollection contentTypes, IList`1 formatters)

at Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor.ExecuteAsync(ActionContext context, ObjectResult result)

at Microsoft.AspNetCore.Mvc.ObjectResult.ExecuteResultAsync(ActionContext context)

at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.d__19.MoveNext()

--- End of stack trace from previous location where exception was thrown ---