[vNext] Even ASP.NET Core 2 Preview 1 announced, OData WebAPI vNext still no updates

[alvachien]

Just found the ASP.NET Core 2 Preview 1 has been announced officially: https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

But OData WebAPI vNext branch still not update to run on even for ASP.NET Core 1!

[hi-xiaoxin]

+1

[ethnoplex]

+1

[harsimranb]

The Microsoft.AspNet.OData assembly is available in Asp.Net Core 2.0, but there is no way to really use it as explained in the docs. Is there any kind of documentation, or is the .Net Core 2.0 support just a fluke?

[vitaliipanchenko]

+1

[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]

@harsimranb - The Microsoft.AspNet.OData assembly is not supported on ASP.Net Core. Can you point me to where it’s available?

[alexdresko]

@robward-ms I'm a developer, so I know the difficulty in responding to questions about time estimates.... but is there any sort of timeline available, even for an alpha? We're in a position where we can test an alpha, and we don't need really solid for a few months.

[robward-ms]

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]

From #939 -

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.

[alexdresko]

@robward-ms Thanks for all you've done already. I'm somewhat of a pro at overestimating, so no worries there. I'm basically holding off on anything that requires OData queries, focusing on everything else for the time being. I have a feeling our timelines are going to overlap nicely. :)

Know that your work won't go unnoticed. We're all super excited to be using OData again.

[DickvdBrink]

Instead of cross-posting to #772 and #939 and this issue (#975) - you might aswell close two of them to keep it more clear and the discussion in one place @robward-ms

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

[sorcerb]

Hello, can somebody add simple example of controller? I try start project with this Startup class. "odata/$metadata" work fine, but my simple controller:

public class ServicesController : ODataController
{
    private AccountingBaseContext db = new AccountingBaseContext();

    // GET: odata/Services
    [EnableQuery]
    public IQueryable<Services> GetServices()
    {
        return db.Services;
    }

    // GET: odata/Services(5)
    [EnableQuery]
    public SingleResult<Services> GetServices([FromODataUri] int key)
    {
        return SingleResult.Create(db.Services.Where(services => services.ServiceId == key));
    }
}

odata/Services return: {"@odata.context":"http://localhost:3592/odata/$metadata#Services","value":[ odata/Services(5) return: ERR_CONNECTION_RESET Sql query work fine, was tested with SQL Profiler.

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

@sorcerb - You can find an example in the release notes: http://odata.github.io/WebApi/#14-01-netcore-beta1.

[sorcerb]

@robward-ms, Thanks, but exapmle have some old information, step "E" :

e. Configure the OData Endpoint Open the file App_Start/WebApiConfig.cs

App_Start - it's Framework folder, not Core. It need added to Startup.cs definitely.

[robward-ms]

@sorcery - Thanks for catching that. The contents the functions were tested in AspNetCore but this code is a copy and paste from the current getting started so indeed that file name and location are wrong.