Webapi: [vNext] Port ASP.NET Web API OData to ASP.NET 5/MVC 6

[kevinchalet]

I expect Web API OData to be really painful to port given that ASP.NET 5 and MVC 6 are radically different from the previous versions, but I think it's definitely worth it (sure, that's a totally biased opinion... I'm a huge fan of OData :dancer:).

For a complete port, we'd need a .NET core version of the ODataLib and EdmLib, but targeting aspnet50 might be a reasonable objective for a first step.

I'll probably start working on a straight aspnet50 port in the next couple of days, so let me know if you wanna participate :smile:

[congysu]

@PinpointTownes
Thank you:) Let's see how we can provide .NET core version of the ODataLib and EdmLib to you. Shall we set up a phone call on this?

[kevinchalet]

@congysu thank you for your interest! :sake:

A few remarks concerning my progression:

• I almost got rid of HttpRequestMessage and HttpResponseMessage and replaced them with the new HttpContext. It was painful, but it's now done. That said, there is still a place I can't remove them from yet: in MediaTypeMapping (because Microsoft.Net.Http.Headers doesn't seem to have an equivalent for that). I'll ping @Tratcher when he's back.
• I removed the batching support from the first bits: I realize that it's of course a crucial feature, but MVC 6 doesn't support it yet, and it'll likely be implemented at the middleware level. This would need much more thinking, so I prefer removing it for now.
• I'm still undecided concerning OData routing. In the first bits, I removed the custom action selector and all the conventions to exclusively favor the attribute routing approach (that'll become the first-class citizen in MVC 6). This new version might also be a great opportunity to unify ODataRoute and Route/HttpGet attributes. The first tests using standard MVC 6 attributes are extremely encouraging, but only one EDM model per app is supported with this approach. Comments are welcome on these points :smile:

public class MyController
{
    [HttpGet("Entities")]
    public IActionResult Get()
    {
        return new ObjectResult(new[]
        {
            new MyEntity { ID = 4 },
            new MyEntity { ID = 5 }
        });
    }

    [HttpGet("Entities({id})")]
    public object Get(int id, ODataQueryOptions<MyEntity> options)
    {
        return new MyEntity { ID = id };
    }

    [HttpGet("Entities({id})/Children")]
    public object GetChildren(int id)
    {
        return new ObjectResult(new[]
        {
            new MyEntity { ID = 4 },
            new MyEntity { ID = 5 }
        });
    }
}

• MVC 6 now supports POCO controllers (i.e controllers that don't derive from the Controller base class). I'm not necessarily a fan of this feature, but I think we should support it. Of course, we'd still need a way to determine whether a controller/action is an OData one, but I wonder if we shouldn't simply replace it by the following assumption: if the OData path handler recognizes an OData path, assume that it is an OData request and that the controller that will handle the request is an OData controller, even if it doesn't derive from ODataController.
• I had to update EdmLibHelpers.GetMatchingTypes to use the callcontext static service provider exposed by KRE to retrieve an IAssemblyProvider (because you can't just use the default AssemblyProvider implemention, as it needs constructor parameters you can't easily import). This is of course an anti-pattern, but flowing an IAssemblyProvider is not option either (you can import it via ODataSerializerContext, but not from Delta<>, that relies on EdmLibHelpers.IsNullable but doesn't expose any context). I wonder if we shouldn't simply store the CLR type information directly in the EDM model (maybe via an annotation?) and stop using the loaded assemblies. Any thoughts?

private static IEnumerable<Type> GetMatchingTypes(string edmFullName)
{
    var assemblyProvider = CallContextServiceLocator.Locator.ServiceProvider.GetRequiredService<IAssemblyProvider>();

    return TypeHelper.GetLoadedTypes(assemblyProvider).Where(t => t.IsPublic && t.EdmFullName() == edmFullName);
}

• The tests will have to be updated to support xUnit 2 and its new K runner. I think we should remove Microsoft.TestCommon. Functional tests might be a nice addition.

Concerning ODataLib and EdmLib, I think that it would be easier to move to the new project.json stuff to easily support .NET, .NET Core and the different portable targets.

I'll try to share my current bits ASAP :soon:

If you want to, you can ping me on JabbR (#aspnetwebapi, #aspnetvnext or #odata)

[kevinchalet]

Gooood morning! :alarm_clock:

As promised, here are the first bits of the vNext port I worked on: https://github.com/PinpointTownes/WebApi

Of course, it's still a work in progress: tons of things have been removed (e.g OData routing or V3 support), updated, or replaced (e.g message handlers) and thousands of tests still need to be ported to xUnit 2, but things are finally starting to fall into place.

If you want to help porting the unit tests (@lewischeng-ms, I need you :smile:), don't hesitate to ping me for a write access.

That would be great if we could find a few minutes to talk about the in-depth details on the #odata room (https://jabbr.net/#/rooms/odata)

[lewischeng-ms]

@PinpointTownes Thanks! I am looking at your code and will share you with any insight from the code.

[kevinchalet]

@lewischeng-ms thanks!

A few notes:

• This is mostly a straight port: I tried to leave the code as-is when no changes were required (except serialization/deserialization, which is now async). That said, code guidelines used by the ASP.NET team have changed, and they now favor the use var everywhere approach. This makes the code more readable, and I think we should opt for var.
• Concerning the way EdmModel should be injected in the current context request, I'm still undecided. Maybe we should simply support a unique model per app for the first bits and store it in the incoming ODataOptions (that will be similar to MvcOptions) and see with the ASP.NET team if they have plans for multitenant/separated configurations support?
• I really think we should make EnableQueryAttribute less magic and remove on-the-fly EDM model creation: even if the IQueryable support is one of the most used feature of WCF/Web API OData, it's also one the most criticized aspect and a terrible brake for techies. Building an OData API should be a cautious act and we shouldn't hide the necessity to reduce the graph surface (e.g by marking critical navigation properties as non sortable, filterable or expandable).
• We should move the attributes used by Web API OData to their own project: having a separate "Models" project containing only the POCO models is a common thing in the real world, and depending on the whole ASP.NET thing to simply use the Contained/NotFilterable/Sortable/Expandable attributes is something we should try to avoid.

[kevinchalet]

@lewischeng-ms I see that you ported ODataLib and EdmLib to aspnetcore50 (now dnxcore50 btw): https://github.com/lewischeng-ms/vNext/blob/master/src/Microsoft.AspNet.OData/project.json#L3-L9

Is there a chance you could share the .nupkg? :smile:

[lewischeng-ms]

@PinpointTownes Sure. For ODataLib and EdmLib issues on vNext, let us move to https://github.com/OData/odata.net/issues/97 where I will update the latest progress there:smile:

[kevinchalet]

@lewischeng-ms @congysu don't hesitate to share your thoughts concerning the different points I mentioned :ghost:

For the "attributes" companion project, I'm not decided yet:

• Microsoft.OData.Annotations,
• Microsoft.AspNet.OData.Annotations,
• Microsoft.ComponentModel.DataAnnotations.OData,
• Microsoft.DataAnnotations.OData,
• System.ComponentModel.DataAnnotations.OData,
• System.DataAnnotations.OData.

The first one seems a good option, since it's not directly specific to ASP.NET nor Web API, which might be interesting for the ones who like sharing a portable "Models" project between their different apps.

Any thoughts?

[IDontEatSoap]

Awesome stuff Pinpoint :+1:

Is this the main force behind OData on vNext? I couldn't find anything else.

If so, do we have a dev branch here for people working on the upgrade?

Cheers

[kevinchalet]

@IDontEatSoap thanks! :family:

Is this the main force behind OData on vNext? I couldn't find anything else.

It looks like the OData and the ASP.NET teams prefer working on their own version and have a design review before touching the code (see https://github.com/aspnet/Mvc/issues/650#issuecomment-81171753). Not sure if it's a high priority item though (at least, it was clearly not when I asked David Fowler on JabbR a few weeks ago).
So my mission here is now done (I'll simply provide feedback if they want me to).

If you're interested, you can take a look at https://github.com/PinpointTownes/WebApi, but please remember that it's an early prototype - probably full of bugs - that won't reflect the final version :smile:

[IDontEatSoap]

Haha I'm not surprised. There's a carrot in a shape of a KPI somewhere for someone to chase probably.

But I am suprised to see that there's nothing being done around OData by the ASP.NET msft people... Their team blog mentions this post as an "early investigation" on OData around vNext, but without an official branch....

Architecture is definitely the first thing to define. But hey, OData is not rocket science...

Well, I just hope OData on asp.net 5 supports CLR's DateTime. If there's something we could do outside corp to shed some light inside architects minds to make it happen it would be great.

[kevinchalet]

Haha I'm not surprised. There's a carrot in a shape of a KPI somewhere for someone to chase probably.

So true :smile:
(if I was teasing, I'd even say that some people at MSFT still have trouble understanding the real definition of "an open source community", but heh, I'm not :smile:)

But I am suprised to see that there's nothing being done around OData by the ASP.NET msft people... Their team blog mentions this post as an "early investigation" on OData around vNext, but without an official branch....

:+1:
The only official branch that I know of is the experimental playground used by @lewischeng-ms: https://github.com/lewischeng-ms/vNext

I can perfectly understand they prefer working on their own port instead of using what's offered by the community, but the lack of communication is a bit worrying. Since the conference call I had with @congysu and his team, I have listed a few points that are still not commented. I'm totally convinced there's a relationship between the low adoption rate of OData and this erratic communication.

Architecture is definitely the first thing to define. But hey, OData is not rocket science...

My idea was to port the basic/primitive blocks of Web API OData (serialization, deserialization, querying support) and start reviewing the current design with a working prototype.

Well, I just hope OData on asp.net 5 supports CLR's DateTime. If there's something we could do outside corp to shed some light inside architects minds to make it happen it would be great.

:+1:
Given that they recently brought back this support in Web API OData, that would be suicidal to remove it from the vNext port.

[markdstafford]

Please let me apologize for any confusion and/or frustration we may have caused in our management of this particular contribution. Let me try to clarify a bit what's been happening behind the scenes. I apologized in advance if this is more detail than you wanted, but hey... at least you'll know what's happening.

First of all, @PinpointTownes , we really, sincerely appreciate both your enthusiasm and your desire to contribute to this repository. The biggest issue is that we frankly haven't made a firm decision as to whether our support in vNext will be a straight port or a deeper rethink of the overall architecture. OData will obviously have a presence there, we are just debating the details.

On the one hand we could do a straight port. This would obviously be ideal for existing customers, but it would come with the same overhead we have today in Web API OData. We want to improve not incrementally but exponentially. Ideally creating a REST API that follows OData conventions would be a matter of only a few lines of code. This would be tough to do with a straight port.

Another alternative would be to do a dramatic rewrite. Make things really dead simple (but keep the flexibility of Web API OData so we don't run into the cliff WCF Data Services customers ran into). This would be great for attracting new customers to OData but may be a deal-breaker for people with existing investments in Web API OData.

So part of the delay/confusion/vacillation has been that we're simply debating between these two alternatives, but most of that conversation is happening internally. :(

Here's my take on where we are. We want to find the middle ground, perhaps by bringing RESTier and Web API OData closer together or even possibly merging them into one stack. This middle ground would make it easy for existing Web API OData customers to migrate to vNext, and would make it enticing for new customers to adopt OData if all they have to do is add one or two lines of code.

Unfortunately this is ongoing thinking. The confusion you're seeing is an artifact of us having an active debate about the path to take. We're sorry that we haven't done a good enough job of communicating that to the outside community, but it's hard to know exactly what to share and what not to. Most of the world doesn't care about the minutiae of our design discussions. And we still have a lot to learn about open source - for instance, where the right place would be to have this conversation.

So. I think we need a bit of time at this point to stabilize our thinking on the path forward. Whatever direction we head, I'm super thankful that there's a version (buggy or not) that runs on vNext. Thank you for that!

And we'll try to figure out a better way to communicate exactly where we are in the process so that we don't make the same mistake again. Again, thank you, and we do hope that you stay an active part of the community.

P.S., we'll keep the support for CLR DateTime around.

[kevinchalet]

@markdstafford thank you very much for this detailed answer, it's really appreciated! :+1:

First of all, @PinpointTownes , we really, sincerely appreciate both your enthusiasm and your desire to contribute to this repository. The biggest issue is that we frankly haven't made a firm decision as to whether our support in vNext will be a straight port or a deeper rethink of the overall architecture. OData will obviously have a presence there, we are just debating the details.

On the one hand we could do a straight port. This would obviously be ideal for existing customers, but it would come with the same overhead we have today in Web API OData. We want to improve not incrementally but exponentially. Ideally creating a REST API that follows OData conventions would be a matter of only a few lines of code. This would be tough to do with a straight port.

Another alternative would be to do a dramatic rewrite. Make things really dead simple (but keep the flexibility of Web API OData so we don't run into the cliff WCF Data Services customers ran into). This would be great for attracting new customers to OData but may be a deal-breaker for people with existing investments in Web API OData.

Supporting both approaches would be ideal, actually (and would make everyone happy :smile:): advanced users should be able to use very strict conventions and apply fine-grained querying policies while beginners would indeed prefer reusing their DbContext and expose it "as-is". For me, having the core support in Web API OData and the automagical stuff in RESTier seems like a good compromise.

So part of the delay/confusion/vacillation has been that we're simply debating between these two alternatives, but most of that conversation is happening internally. :(

IMO, sharing your doubts with the community is a great thing, and will help you getting more feedback :+1:

Here's my take on where we are. We want to find the middle ground, perhaps by bringing RESTier and Web API OData closer together or even possibly merging them into one stack. This middle ground would make it easy for existing Web API OData customers to migrate to vNext, and would make it enticing for new customers to adopt OData if all they have to do is add one or two lines of code.

One concern I have with Web API OData/WCF Data Services is that simplicity hides the fact that even conventional models should be restricted to avoid data leakage or performance issues. For vNext, you could maybe choose an "opt-in" approach and create new Filterable/Sortable/Expandable attributes while still providing an option to use "opt-out" instead.

And we still have a lot to learn about open source - for instance, where the right place would be to have this conversation.

GitHub definitely seems the best place for that (thanks to its visibility), but JabbR is also useful for long discussions.

Again, thank you, and we do hope that you stay an active part of the community.

Thanks, I'll then make sure to annoy you with my feedback :smile:

[markdstafford]

For me, having the core support in Web API OData and the automagical stuff in RESTier seems like a good compromise.

Totally agree from a layering perspective. We are thinking a lot about whether they need to be distinct stacks, though.

One concern I have with Web API OData/WCF Data Services is that simplicity hides the fact that even conventional models should be restricted to avoid data leakage or performance issues. For vNext, you could maybe choose an "opt-in" approach and create new Filterable / Sortable / Expandable attributes while still providing an option to use "opt-out" instead.

This is great feedback. Tough to act on and still hold to the "you shouldn't have to be an OData expert do get value from OData" bar, but we absolutely hear you that having the right defaults is super important. This is probably a topic we need to come back to early in the design process (but after things have stabilized a bit).

GitHub definitely seems the best place for that (thanks to its visibility), but JabbR is also useful for long discussions.

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

Thanks, I'll then make sure to annoy you with my feedback

Good. ;) We could benefit from a lot more people annoying us with feedback.

[lewischeng-ms]

@PinpointTownes Deeply sorry for the very late feedback... I had carefully gone through your port these days and our team just had a separate meeting today to discuss about your work. We really appreciate that. Though your prototype is based on a different point of view, it shows great value where we found many useful insights and techniques that could be incorporated into the vNext. I would like to share some basic thoughts upon your code and comments. Just hope you wouldn't think them to be too late:) And please feel free to express more ideas and feedbacks.

• That's pretty good style to use var everywhere and even more new C# 6.0 features as long as there is no confusion introduced. They could make the code clearer and simpler. In fact I have already began to use lambda expression on property members. That's a lot easier now to write a getter-only property.
• IAssemblyProvider. I met that problem too. I agree with you that it is annoying. Simply using the service exposed by KLR to enumerate all the loaded assemblies is not graceful and inefficient. Actually in my first bits, I took a CLR type from user and just search in that assembly (is it similar to what you said?). But what if there is a user who has model types stored in several assemblies? We have to figure out each situation carefully.
• EnableQueryAttribute. I have to say you are definitely an MVC expert. It is fairly a good design to have EnableQueryAttribute only including only public properties while moving the OnActionExecuted logic to ODataQueryActionFilter. Personally I think that really fits well into the single responsibility principle.
• ODataMediaTypeInputFormatter and ODataMediaTypeOutputFormatter. When moving to vNext, they are what we have to implement in any case. Pretty much thanks for splitting the original ODataMediaTypeFormatter into these two refined components. Now we are considering three options: 1) continue to rely on ODataLib to do serialization and deserialization where I think your implementation is good enough; 2) get some context info from ODataLib and directly use Json.NET to handle serialization and deserialization; 3) 'plug' Json.NET into ODataLib. The latter two aim to improve effiency and enable more flexability.
• Attributes companion project. Personally I don't have strong opinion on that so far:P But just regarding the names, I think maybe we should avoid using Annotation there because it may get confusing when there is a totally different concept 'annotation' lying in OData domain. Maybe we should hear more from you and have a better understanding of your perspective.
• per-request model v.s. per-app model. I think your suggestion is nice but we do have a few customer scenarios that ask for per-request model. Of course we can completely implement a new service called ODataOptions (as you suggested) to store stuff that can be safely treated as global unique to the application.

Since we are still at very early stage of investigation, we are so sorry that we only have limited information to share. But we will definitely keep sharing and discuss more with the public. And we are always striving to become more open and more inclusive to the world. Thus I would just encourage you to keep doing what you think is right and what you think is worth doing even if we may have different opinions. Whether or not an early prototype or feature could finally make it into the product branch, the values of it are always there.

Again, great thanks to you and we would certainly love to see your feedback and contribution to OData in the future!

[kevinchalet]

@markdstafford

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

JabbR is definitely MSFT users/developers' lair but that doesn't prevent more general rooms (like #DDD-CQRS-ES, #Xamarin, #AngularJS or #owin) from being really popular, even for people who don't use MSFT products or technologies. TBH, I've never tried Slack, but I'd be happy to fix that if you had a link you could share. gitter.im might also be an option, but I personally find it far less interactive.

@lewischeng-ms

Deeply sorry for the very late feedback... I had carefully gone through your port these days and our team just had a separate meeting today to discuss about your work. Just hope you wouldn't think them to be too late:) And please feel free to express more ideas and feedbacks.

No problem, it's never too late, specially for a product whose design meetings have just started :smile:

IAssemblyProvider. I met that problem too. I agree with you that it is annoying. Simply using the service exposed by KLR to enumerate all the loaded assemblies is not graceful and inefficient. Actually in my first bits, I took a CLR type from user and just search in that assembly (is it similar to what you said?). But what if there is a user who has model types stored in several assemblies? We have to figure out each situation carefully.

Yeah, it's really annoying. I even had to replace IAssemblyProvider by ILibraryManager because the default implementation only looks for assemblies referencing MVC 6, which might not be the case with entities included in a shared/portable project that doesn't reference MVC 6: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/DefaultAssemblyProvider.cs#L56
It's not ideal as it loads every dependency listed in project.json into memory (and their own dependencies).

Of course, using a custom assembly provider (like this one, that uses a fixed list of assemblies: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/FixedSetAssemblyProvider.cs) might be an option, but we'd have to keep in mind that it would be shared with the rest of the MVC application, so people would have to list both their controllers assemblies and their entities assemblies.

My remark concerning the CLR type was not really about the way it should be resolved (using an assembly provider, directly using the library manager, etc.), but the place where it's done: IMHO, the CLR type resolution should be directly made in ODataModelBuilder.GetEdmModel, at startup time, where you can more easily get an ILibraryManager/IAssemblyProvider. Of course, "on-the-fly" EDM model creation would have to be removed (but it's a bad practice, IMHO).

EnableQueryAttribute. I have to say you are definitely an MVC expert. It is fairly a good design to have EnableQueryAttribute only including only public properties while moving the OnActionExecuted logic to ODataQueryActionFilter. Personally I think that really fits well into the single responsibility principle.

Thanks, sir! :smile:

ODataMediaTypeInputFormatter and ODataMediaTypeOutputFormatter. When moving to vNext, they are what we have to implement in any case. Pretty much thanks for splitting the original ODataMediaTypeFormatter into these two refined components. Now we are considering three options: 1) continue to rely on ODataLib to do serialization and deserialization where I think your implementation is good enough; 2) get some context info from ODataLib and directly use Json.NET to handle serialization and deserialization; 3) 'plug' Json.NET into ODataLib. The latter two aim to improve effiency and enable more flexability.

The third option sounds like the best of both worlds. I wonder if the second option wouldn't make the serialization/deserialization stuff far too dependent of JSON.NET, which would make ATOM support (is this even considered?) really hard to implement.

Attributes companion project. Personally I don't have strong opinion on that so far:P But just regarding the names, I think maybe we should avoid using Annotation there because it may get confusing when there is a totally different concept 'annotation' lying in OData domain. Maybe we should hear more from you and have a better understanding of your perspective.

When working on an application that includes both the OData server and the corresponding OData client (often an MVC facade), I usually prefer sharing a single portable project that contains the different entities used by the server and the client. This way, code comments and attributes can be easily reused between the different projects. Sadly, if you want to use Contained, NotFilterable or their friends, you need to reference Web API OData, which makes the entities project non portable. That would be great if you could put the attributes in a different project and make it fully portable (dnx451, dnxcore50, but also Xamarin iOS/Android, Windows Store and even Windows Phone).

per-request model v.s. per-app model. I think your suggestion is nice but we do have a few customer scenarios that ask for per-request model. Of course we can completely implement a new service called ODataOptions (as you suggested) to store stuff that can be safely treated as global unique to the application.

I realize that it's of course an important scenario, that probably needs to bring back ODataRoute and his friends. One question I have is how would you pick a specific EDM model using regular HttpGet/HttpPost/HttpPatch/HttpDelete attributes?

I also wonder if it shouldn't be handled directly by MVC or Routing.

Another option might be to bind the IEdmModel with ODataOptions and create as much options registrations as needed: a special IOptions<> (aka "options manager") would then pick the appropriate options instance depending on the request URI, on a specific header, on the vpath... Creating a whole new IEdmModelSelector might also be an option.

Since we are still at very early stage of investigation, we are so sorry that we only have limited information to share. But we will definitely keep sharing and discuss more with the public. And we are always striving to become more open and more inclusive to the world.

Wonderful, thanks! :+1:

Again, great thanks to you and we would certainly love to see your feedback and contribution to OData in the future!

Sure (I'll probably flood you with remarks concerning the odata.bind support in the next few days)

[lewischeng-ms]

@PinpointTownes

My remark concerning the CLR type was not really about the way it should be resolved (using an assembly provider, directly using the library manager, etc.), but the place where it's done: IMHO, the CLR type resolution should be directly made in ODataModelBuilder.GetEdmModel, at startup time, where you can more easily get an ILibraryManager/IAssemblyProvider. Of course, "on-the-fly" EDM model creation would have to be removed (but it's a bad practice, IMHO).

May I ask what are you referring to by saying "on-the-fly"? Do you mean the ODataConventionModelBuilder? Anyway, besides the advantage you mentioned that it is easier to get assembly provider to do assembly search at startup time, I think we can also cache the mapping result (between clr and edm types) in some place (of course it could be in the model as you suggested) to improve the efficiency of later lookup.

The third option sounds like the best of both worlds. I wonder if the second option wouldn't make the serialization/deserialization stuff far too dependent of JSON.NET, which would make ATOM support (is this even considered?) really hard to implement.

I think you are right. It could be that the second option would make serialization/deserialization too coupled with JSON.NET unless we find something as the intermediate representation like JObject and can be easily converted to/from it. For ATOM, we cannot say we would just give it up that way. But we do aim to make the data transferring more lightweight. So ATOM may be considered as an extension support aside from JSON if we choose the second option. For the third option, if we could make the ODataLib layer more "thin" (aka strip off the serialization/deserialization functionality), we would love to do that but unfortunately this is still under investigation since the logic behind the large codebase of ODataLib is so complicated...

When working on an application that includes both the OData server and the corresponding OData client (often an MVC facade), I usually prefer sharing a single portable project that contains the different entities used by the server and the client. This way, code comments and attributes can be easily reused between the different projects. Sadly, if you want to use Contained, NotFilterable or their friends, you need to reference Web API OData, which makes the entities project non portable. That would be great if you could put the attributes in a different project and make it fully portable (dnx451, dnxcore50, but also Xamarin iOS/Android, Windows Store and even Windows Phone).

I see...But I need to talk to our client colleagues next week to understand more about those scenarios involving both server and client.

I realize that it's of course an important scenario, that probably needs to bring back ODataRoute and his friends. One question I have is how would you pick a specific EDM model using regular HttpGet/HttpPost/HttpPatch/HttpDelete attributes?

This is currently done in OData routing by setting Model property of ODataProperties associated to that request. Regarding whether to use ODataRoute or simply the MVC routing, I think we may need to find that ultimate answer together:)

Another option might be to bind the IEdmModel with ODataOptions and create as much options registrations as needed: a special IOptions<> (aka "options manager") would then pick the appropriate options instance depending on the request URI, on a specific header, on the vpath... Creating a whole new IEdmModelSelector might also be an option.

That's a good idea. I guess that would definitely require ODataRoute to be there, huh? We parse the request URI, extract the headers and make choice of which controller/action to invoke, which set of 'options' to pick, and which model to pass.

Thanks:)

[ghost]

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

Yes. I think either a google group / mailing list / or a Freenode IRC channel may be better choices than jabbr or slack. All have good cross platform support and match what many other open source projects do. I'll move this portion of the discussion to another issue because it's entirely orthogonal to this discussion.

[kevinchalet]

@lewischeng-ms

May I ask what are you referring to by saying "on-the-fly"? Do you mean the ODataConventionModelBuilder? Anyway, besides the advantage you mentioned that it is easier to get assembly provider to do assembly search at startup time, I think we can also cache the mapping result (between clr and edm types) in some place (of course it could be in the model as you suggested) to improve the efficiency of later lookup.

Sorry, I should have been clearer. Here's what I mean by "on-the-fly model": https://github.com/OData/WebApi/blob/master/OData/src/System.Web.OData/Extensions/HttpActionDescriptorExtensions.cs#L36-L42 https://github.com/OData/WebApi/blob/master/OData/src/System.Web.OData/OData/EnableQueryAttribute.cs#L614

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

[lewischeng-ms]

@PinpointTownes Thanks I got what you mean:) I agree that we should not arbitrarily mix OData stuff with "pure Web API" stuff and users should always explicitly specify an IEdmModel to use EnableQueryAttribute. However we have to find a balance here. In one hand, elementary users who don't know OData concepts (e.g., EntitySet, EntityType, ...) very well yet shall be able to ramp up soon and build up a relatively satisfying service. In the other hand, advanced users can carefully "tailor" their models according to each very specfic need and pass it to Web API OData. This kind of "on-the-fly" model creation you mentioned indeed seems not to be a reasonable solution but helping users of any level to easily build models that work as they want is definitely one of our primary goals:)

[kevinchalet]

@lewischeng-ms I agree, Web API OData should be relatively easy to set up :smile:
To make the IEdmModel creation a breeze, you could consider adding new attributes to define entity sets directly on the entity class itself. The conventional model builder would then scan your assemblies and build an IEdmModel without having to manually call EntitySet.

Creating a new OData API would be as easy as calling services.AddOData() (for beginners) or services.AddOData(builder => builder.EntitySet<Product>("Products")) (for advanced users).

(as a side note, that would be great to make the conventions stuff public, so users could remove specific conventions from the default set or choose their own one)

[lewischeng-ms]

@PinpointTownes Your points are really helpful, thanks! I think it would be great if there is a graceful way to expose the magic of model building as some set and let users make smart decisions on what magic they want to apply. Of course the magic will not be limited to the given conventions anymore. Please feel free to correct me if I misinterpret your point :P

[kevinchalet]

Ding dong. Any news concerning the vNext port? :lollipop:

[lewischeng-ms]

Hi @PinpointTownes Thank you very much for your attention. This month our team members are all focusing on documentation and tooling support of OData to help the community adopt OData more easily and smoothly. We plan to formally start working on vNext in May and we will update our status by then:)

[kevinchalet]

Wonderful, thanks @lewischeng-ms :bow:

[ilmax]

Maybe this is the wrong place, if so please point me to the correct one. For odata vnext I would love to have ODataQueryOptions with enhanced support for custom mapping/aliasing.

This is useful when the entity type and the type the client uses are different (flattening/projection involved) or when exposing DTOs instead of data entities from web api controllers.

[lewischeng-ms]

@ilmax Thanks for your feedback. Actually we are considering to offer enough flexibility when constructing EDM model from the Clr types users give us in vNext. I think what you suggest can be done by this part of the work.

[jods4]

:+1: really waiting for this to happen.

[FlippieCoetser]

@lewischeng-ms, any progress to share yet? noticed you mentioned start date was in May...

[lewischeng-ms]

@FlippieCoetser We have completed an initial alpha version of it. Please see http://odata.github.io/WebApi/#07-07-6-0-0-alpha1 for detail and have a try. Any feedback would be warmly welcomed. We would like to apologize for the slow progress as the whole team was busy catching a very urgent schedule these two months. But we shall restart development on this before long. Thanks.

[FlippieCoetser]

@lewischeng-ms Great stuff! I already loaded the sample and all works well! I keep you posted.

[jods4]

@lewischeng-ms Excellent timing -- for me at least ;) You can be sure I'll try this and let you know if I encounter bugs or limitations. FYI I'm going to use it with a EF6 Oracle back-end inside ASP.NET 5 (I'm currently on beta 6).

[lewischeng-ms]

@FlippieCoetser @jods4 Thank you both for your support!

[jods4]

@lewischeng-ms I tried to include the library in my project but I couldn't get it to work. I have the impression that because the library currently references asp.net beta4, it won't work with a beta6 runtime.

BTW it could be easier if you aligned the beta labels with matching asp.net runtime. People using asp.net vnext know that it usually crashes horribly when you mix components from different beta releases, so it becomes natural to pay attention that all your references are in sync.
If you don't want to label it beta, maybe you could call it -alpha4 at least, so that it's more obvious if my list of references is correct/compatible or not.

That said I would really like to test a build updated for newer betas if you can create one!

[jods4]

@lewischeng-ms Here's some early feedback:

1. I made it works in -beta6. It was really easy as I only had to update references inside project.json and change 8 context.ActionContext.XYZ by context.XYZ (the ActionContext property is now gone and flattend). If you want I can do a PR but this is really really trivial. I also had to change the global.json but I'm unsure what _you_ would put in there.
2. Error reporting is really rough but I guess this is expected. When you get everything configured right, it seems to work.
3. I had to call app.UseOData<T>("odata") separately. When I tried to do it inside app.UseMvc(builder => builder.MapODataRoute<T>("odata")); it crashes, apparently because some assemblyResolver is null or something.
4. DefaultODataModelProvider.BuildEdmModel() is quite basic. When it goes through the public properties, it could skip those that don't implement IEnumerable<T>. It's a simple if (entityClrType == null) continue;. Currently it crashes with a NPE.
5. Otherwise it seems to work ok. Of course because only $filter works it's extremely limiting right now ;) The logical next step for me would be to implement the rest of IQueryable so that I can perform paging queries, searches, etc.

[lewischeng-ms]

@jods4 Thanks very much for your valuable feedback. Regarding the versioning problem, I think what you suggest is quite reasonable but we need to work out a more flexible solution for both of us because we have our own schedule and our progress is not strictly synced with AspNet vNext.

Of course, we warmly welcome your pull request to make it work with beta6. Please feel free to do so. We can have more focused talk on your PR then.

About app.UseOData<T> or app.UseMvc, we are still thinking of whether we want to use MVC routing or implement our own route or both. So the API now looks rough and unstable. Sorry about that:)

Upon other things you mentioned, we may consider adding to the next alpha version with higher priority. We know that using alpha versions and experiencing breaking changes are hard and annoying. But we would love to hear more feedback from early adopters like you, make it better and better. Thanks sincerely.

[a99cl208]

@lewischeng-ms Hi,

Is there any alpha/beta release train planning that has been defined, like asp.net team which seem to release a new beta each month from june to december. I ask you because the GitHub repo have no update since 2 months and i wonder if you are still working on it?

Thanks for you answers, and btw the new design i good i think, more lightweight.

[weitzhandler]

Awesome stuff going on in here!
Thanks for everyone working on this!
Any chance OData will ever become first class citizen and be integrated with WebAPI?

[jhermsen]

Hi @lewischeng-ms and @markdstafford,
Any progress on the plans or development?
Really looking forward to be using OData on ASP.Net 5 WebAPI, but currently missing to much functionality to properly use it.

[lewischeng-ms]

@a99cl208 @weitzhandler @jhermsen Really sorry for the very late response. Thank you all so much for your attention and great passion on OData Web API! Please be assured that we will absolutely not give up OData Web API on ASP.NET 5. The most important reason we are not particularly focusing on Web API for the time being is that we think the next brand-new version of OData Web API as a great oppotunity to involve the power of the community. We cannot just shut the door and do it ourselves. It is now an open world where we have no way to succeed without hearing the users' voice. On the other hand, our team is currently putting much effort on RESTier which is a turn-key solution to help users build OData services more easily. As for us, OData Web API vNext is also a critical building block if we want to make RESTier successful on ASP.NET 5. Actually the development of RESTier also helps us gradually form the shape of OData Web API vNext.

So please feel free to tell us your expectation or put forward your design proposal on OData Web API vNext. We promise to value each feedback, each idea and each pull request. And...we won't keep you wait so long!

Thanks again!

[ilmax]

@lewischeng-ms any news on this? I'm a bit worried about the absence of any information/plan about porting OData to vnext.

On the other hand, our team is currently putting much effort on RESTier which is a turn-key solution to help users build OData services more easily.

RESTier can be a turn-key solution, but IIRC is not supported on vnext and since vnext is coming close, developers start poking around with tools and OData doesn't seem to be at the party, nor any plan is shared on OData vnext.

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

Actually I'm using this approach quite often when 3rd party UI components (like grids) support OData for sorting and filtering operation, but I'm totally against ODataConventionModelBuilder usage to create a model "on the fly" and thus I end up every time creating my own model binder which gets the model from a IModelProvider service.

Hope to get any sort of info from OData team concerning vnext.
Regards

[tan00001]

@PinpointTownes:
Microsoft just ditched WCF Data Service in favor of this more "open" WebAPI OData approach, and now you think this is "really really bad"?
We can deal with an approach that is more "chaotic", as long as it delivers on its promise of being more flexible. But now with its implementers doing a tug of war towards the abandoned WCF Data Service, we are not getting any benefits for taking this path, only chaos.

Current WebAPI OData implementation is really awful. It really does not deliver much. For example, if your database catalog has multiple schemas, and you want to serve them out in different subdirectories, you have to write a lot of code to override the base code. "Default" namespace name cannot be left blank, and has to be spelled out as "Default". How tacky is that? If you try to use their client generator to deal with a few different namespaces, you are out of luck unless you want to write a lot of code of your own. All of this are on top of the fact that you will have to write a ton of controllers.

WebAPI OData v4 is a big let down. Now it is falling so far behind vnext, one has to wonder its coders are really up to the task.

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

[lelong37]

@tan00001 totally disagree, anyhow, this thread is to move OData forward, not to downplay the folks that are hard at work for vNext. OData v4 is great, and overall OData is the greatest thing thats ever happen to REST especially from a query perspective. Hat's off to the team, and I have complete confidence in the direction of where the team and the community takes vNext.

[weitzhandler]

@tan00001 I totally agree with @lelong37.

[DenisBiondic]

@lewischeng-ms - is this the repo where the implementation is developed? OData WebApi vNext and OData Web API 6.0.0 alpha1

[lewischeng-ms]

@DenisBiondic I am not sure because the link you provided pointed to my personal repo:) The team's repo is https://github.com/OData/WebApi/tree/vNext.

[lelong37]

With ASP.NET v5 RC released @ Connect, just wondering if the team has a version of vNext that will run with latest bits (RC)?

[AndiRudi]

I tried to get that to work with the following packages

"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.OData": "6.0.0-alpha1",
"Microsoft.OData.Core": "6.12.0"

But it seems that the [EnableQuery] attribute is not found?

[ghost]

Same to me as @AndiRudi wrote.
Seem like it works only with Microsoft.AspNet.Mvc 6.0.0-beta4 version.
Will OData package be updated to support rc1-final?

[YehudahA]

@AndiRudi and @qarpin , It seems that the project is dead.

[smokingkills7]

Any update when oData will be available for Asp.Net5 RC1? As mentioned by other users, the sample doesn't work with RC version. Any update on timeline would be appreciated, so that we can plan our development.

[shyambhiogade]

Hi
I am converting my project my ASP.net 4 and MVC 5 to ASP.net 5 and MVC 6. I have implented OData in my old project. i started using the source given at

https://github.com/OData/WebApi/tree/vNext

i have include the sample project and "Microsoft.AspNet.OData" project available there.

I am trying to implement, ODataRoute as shown in below code

[HttpGet]
[ODataRoute("GetSalesTaxRate(PostalCode={postalCode})")]
public IHttpActionResult GetSalesTaxRate([FromODataUri] int postalCode)
{
    double rate = 5.6;  // Use a fake number for the sample.
    return Ok(rate);
}

to be able to call the function using syntax like

GET http://localhost:38479/GetSalesTaxRate(PostalCode=10) HTTP/1.1 

i didnt find the ODataRoute in that code. can someone tell me how to achieve similar functionality using latest OData package in ASP.net 5

[lelong37]

Is there a new repo/branch for OData vNext since the rename of ASP.NET Core 1.0? Also, could we get a status from the OData team for ASP.NET Core 1.0? Much appreciated...

[shyambhiogade]

Yes, the latest beta source has that option, my old sample was from alpha branch. beta has this option in HttpGet

[peder]

I also feel that an official statement is needed on the future of the OData libraries. Is a rebranding also in order now that ASP.NET Core 1.0 is official?

[markdstafford]

Hey all - this is as official as the statement gets at this point.

We will be supporting ASP.NET Core 1.0 eventually. It's not on the roadmap right now, but +1s help us prioritize.

A major part of the problem is that the breaking changes in ASP.NET Core mean that we have a hard choice: do we put all of our effort into the version of our libraries that runs on .NET Core, or do we do less features and support both .NET Core and traditional ASP.NET?

We're not ready yet to force people to ASP.NET Core, especially since we don't know exactly when it will GA. As things get closer with them and we continue to investigate whether there's any way for us to build one stack that works on both ASP.NET and ASP.NET Core, we'll be able to make a better decision.

So for now, don't expect a lot of forward momentum on this particular issue not because it's not important, but because we're just not ready yet.

All of that said... resourcing is factoring significantly into our decision at this point. If there are a couple solid developers out there who can pony up some hours and pull requests, we'd love to discuss with you offline about making more progress. If you're able to contribute some time and help us think through a plan, I'd love it if you shoot an e-mail to [email protected] or me directly at [email protected].

Regarding branding, I personally hate the "OData" moniker. I think it misleads people from what OData actually is - a set of best practices for building REST APIs. But given that we have the protocol standardized, I'm fairly confident the window for some forms of branding have closed. You will notice, however, that RESTier doesn't have the word "OData" in it, and I personally hope to see RESTier as the basis for most new OData services in .NET. Note for people who are now having a panic attack: take a deep breath; RESTier is built directly on top of Web API OData, so don't worry about whether we're headed in a different direction or whether we're going to stop supporting Web API OData.

[markdstafford]

Final thought: we'll try to publish some guidance soon with our thinking around RESTier, Web API OData, ODataLib, and how they all fit together going forward. I think the story is pretty dang slick, and I hope other people will agree.

[DickvdBrink]

Ouch, this is a bit painful to hear. Some guidance for vNext would be appreciated;

The nightly for vNext on MyGet is quite old - is this something you guys will update when there are some nice PR's added (still under a pre-release label of course)? Because right now it isn't possible to use it and you have to build from source. I think that isn't what most developers want to do - just a guess, they might not want to use dotnet core anyway because it isn't really production ready yet.

You are talking about guidance for RESTier but how does dotnet core fit in here? Because that is what this issue is all about?

[grahamehorner]

There is still a lot of movement with regards to ASP.NET core & dotnet cli which is making life a little difficult I think before starting working on a version of the OData API for ASP.NET core a build of ODataLib for dotnet core/cli http://odata.github.io/odata.net as these are fundamental to building the OData API

[DickvdBrink]

@grahamehorner, that one is already there right? So that isn't really the problem I believe.
nuget file

http://www.nuget.org/packages/Microsoft.OData.Core/6.15.0-beta

Targets .NET Core 5, and .NET Portable

[grahamehorner]

@DickvdBrink that may be the case but given the churn ASP.NET core currently is undergoing along with the dotnet cli the Microsoft.OData.Core is targeted at version which is behind the most current and until the churn slows/rc2 is released I feel any effort may be wasted.

[robertmclaws]

Given the fact that EF Core 1.0 is not going to be feature compatible with EF 6 anytime soon, there are likely to be some issues getting OData on .NET Core _anyways_. The guidance I'm giving my customers is to stay on the current production code for OData stuff. If you want to get on MVC Core 1.0 for your front end, then you need to ship you API separately on a separate subdomain (something you should be doing anyways for scalability).

[zfkingth]

+1

[tomvanoost]

@markdstafford Could you give an update on this subject? When can we expect OData Web API support in ASP.NET Core? A bit of a time-frame would be very helpful!

[xuzhg]

@tomvanoost

As Mark said before: "We will be supporting ASP.NET Core 1.0 eventually". And yes, we (ODataTeam) have decided to make this feature going on. However, owing the lack of resource, we do hope customers like you, who love OData and are willing to see OData be successful on ASP.NET Core, can help us and share your contributions, no matter what kind of contribution: materials, designs, codes, discussions, anything. Thanks in advance.

[tachyon1337]

@xuzhg

The statement is 6 months old. For some, lack of OData support is a bottleneck for asp.net core migration. It looks like if you want to migrate to core anytime soon, you are going to have to roll your own queryable protocol.

[jondavis-ineight]

It's not on their roadmap. I guess it doesn't matter how long ago it was, they officially said it's not in their roadmap, and until they declare that it has been put on their roadmap, it's not on their roadmap.

This is frustrating. Several OSS projects are diving straight into ASP.NET Core and abandoning ASP.NET 4.x, such as Glimpse. There are features we wanted in Glimpse v2 (namely support for integrating with multiple web service app pools), which is only being built for ASP.NET Core, but our primary web services are all built upon OData v4 & EF6.

[damienpontifex]

@xuzhg @markdstafford I'd be happy to contribute code, tests, fixes etc. Is it best to start with work relating to issues on the vNext milestone and go from there?

And even though it may not be on the roadmap for the core team at the moment, will pull requests be reviewed if they are submitted? Or are resources also on hold on this front?

[dazinator]

+1

[garethsuarez]

I would think if you want to help move OData and/or Restier forward to Core compatibility, the first place to look is at helping out the EF team. With out full features in EF Core, OData Core would pretty much be limited to non production demo work anyways.

[DickvdBrink]

Why? Not everyone uses EF, so some might want to generate the queries themselves!
Or have another use case for OData (proxy OData calls to an WCF service for example - not my scenario btw ;-))

[genifycom]

It will get on their roadmap pretty quickly if they want to support FaaS through Amazon Lambda C# (i.e. Linux). Windows in the Cloud is just too expensive at the moment!

[hidegh]

How to set up ODataQueryable and OData response with MVC6 (full .NET) and ODataV4 for an on-the-fly model? By on the fly I mean any IQueryable (in memory, NHibernate, or aby other ORM, not just EF). with a bit of luck, this generic way could be then also used for EF6 and EF core.

Also important to be able to configure the query to work with:

• camelcase/pascalcase (.NET / JavaScript standards)
• or with case insensitive property names

I have tried this approach (similar worked nicely with MVC5 and OData v4) - but the GetEdmModel call fails...
ODataQueryable4FilterAttribute.zip

[DickvdBrink]

@hidegh, that question might be more appropriate on StackOverflow - as it is a question and not an issue with the OData lib itself.
It isn't related with this issue topic either is this is about .NET Core ;)

[hidegh]

[vNext] Port ASP.NET Web API OData to ASP.NET 5/MVC 6 and I actually need the info for MVC6 ;)

Btw: most of the StackOverflow answers have link back here.

[robward-ms]

Hi! Thanks to everyone for their patience. Yes, we will be releasing a version of OData WebApi that supports ASP.Net Core. We hope to have an alpha on NuGet in the next several weeks. After that, we’d like to get feedback before releasing an RTM version. If you are interested in help out, please let us know.

The current plan involves breaking changes. We want to release the ASP.Net Core version in a Microsoft namespace as opposed to the current System namespace. We decided to change the existing System namespace to a Microsoft namespace while leaving the existing APIs signature as-is. This does constitute a breaking change, albeit one we think is easy to accommodate. We’d love to get your feedback on this approach and its impact to you. If you have a different idea or just want to chime in with a pro or con, please let us know.

At a high level, the plan is to combine the code from the master branch (formerly OData60) and the maintenance-aspnetcore branch (formerly vNext) to create two version of OData WebApi from a common codebase: a ASP.Net WebApi 2 compatible version and an ASP.Net Core compatible version. Below, you’ll find some details on how we arrived at this plan. We plan to add a feature branch to the OData\WebApi repository and begin consolidating the changes there.

Feel free to chime in with thoughts and concerns regarding this plan on either this issue or a new GitHub issue. Again, thanks for your patience. – The OData Team.

---

We have examined the code in both the master branch (formerly OData60) and the maintenance-aspnetcore branch (formerly vNext) and created a design that supports both ASP.Net WebApi 2 and ASP.Net Core from a single code base. We found that the two branches share about 80% commonality and that the ASP.Net WebApi classes were intertwined with much of the common code. The design we landed on was to refactor the existing code into an ASP.Net WebApi 2-specific portion, which is tightly coupled to the ASP.Net WebApi 2-specific classes, and a common portion which has no dependency on ASP.Net. The code from maintenance-aspnetcore can then be refactored to consume the common portion and provide the ASP.Net Core-specific portion.

This design will allow us to ship both an ASP.Net WebApi 2 compatible version of OData WebApi, a.k.a. the recently release OData WebApi 6.0, for customers not interested in migrating to .Net core and an ASP.Net Core compatible version of OData WebApi for customers that do plan to migrate or build new services on ASP.Net Core. The common parts of the code can be maintained more easily for both versions which reduces the overall engineering maintenance cost. Additionally, we will be able to add new features to the ASP.Net WebApi 2 version, as well as the new ASP.Net Core version.

The design has been prototyped and mostly coded so we’re confident in the design. The next step is to begin reviewing and committing the code to refactor the existing library into two components. This will be created through a series of pull requests targeting a new feature branch. Once committed, we’ll create and publish a nightly Nuget package in MyGet.org for testing. From there, we’ll add the ASP.Net Core version and tests and publish a second nightly Nuget package in MyGet.org. The feature branch will ultimately be merged to master and we’ll ship both packages via Nuget.org.

One issue we ran into during prototyping was the best way to structure the common code. We considered packing the common code into a new Dll based on .NetStandard which can run on Net Framework 4.x as well as .Net Core. However, some of the APIs we needed would have caused a dependency on .NetStandard 1.5, which would force a dependency on .Net Framework 4.6.1 instead of 4.5. To avoid this, we decided to use a Shared Project, a VS 2015 feature that allows common code to be maintained in a single project and included in additional projects. As a result, we’re able to allow each version of the library to take a dependency on the appropriate version of .Net, which will require that the common code compiles for both frameworks and will likely use some conditional compilation, i.e. #if.

An additional issue is that we want to release the ASP.Net Core version in a Microsoft namespace as opposed to the current System namespace. The compiler does not offer a way to compile the same code in two namespaces and we didn’t like the idea of conditional compilation for the namespace. We decided to change the existing System namespace to a Microsoft namespace while leaving the existing APIs signature as-is. We have validated that only changing the using statements in the End to End tests results in a project that compiles and runs. This does constitute a breaking change, albeit one we think is easy to accommodate. We’d love to get your feedback on this approach and its impact to you. If you have a different idea or just want to chime in with a pro or con, please let us know.

The last hurdle we faced was a build system that can build and release the ASP.Net Core version of OData WebApi. .Net Core is only officially supported on VS2017 so we’ll need to not only require VS2017 for development but also lab builds that produce our Nuget packages. We’ve spent the last few months upgrading our engineering system to eliminate this hurdle. The first part of the refactor will target VS2015; VS2017 will be added as we introduce the ASP.Net Core portion.

[robward-ms]

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]

First off, thanks to everyone for your patience. I know it’s taken a while to get here. Second, thanks to everyone who downloaded and provided feedback on the Alpha/nightly packages.

I’m happy to announce the Beta1 release of Web API OData for ASP.NET and ASP.NET Core. You can find the release notes here: http://odata.github.io/WebApi/#14-01-netcore-beta1

And you’ll find the package here: https://www.nuget.org/packages/Microsoft.AspNetCore.OData/

If you find issues, please file them here on GitHub and add the [feature/netcore] tag.

This is one of five issues tracking the ASP.NET Core version of OData WebApi. To streamline communication, I’m going to close this one and leave #939 open until RTM ships. Please us #939 for following status.

[stimpy77]

Nice. Merry Christmas. ;)

[radicalapps]

I don't suppose there's a build of Restier that will work with this...?

[xuzhg]

@all

ASP.NET Web API OData 7.0 is available on Nuget.org now, you can download it from:

1. Microsoft.AspNetCore.OData is based on ASP.NET Core 2.0.
2. Microsoft.AspNet.OData is based on ASP.NET Web API.

Please try it out and let us know any problems, concerns, questions. Thanks!

Regards,
-OData Team