[vNext] Roadmap for OData WebAPI run on ASP.NET Core 1.0

[alvachien]

The ASP.NET Core 1.0 has officially released several weeks ago, the OData vNext (with alpha) still rely on 1.0 RC2 and cannot install from Nuget so far.

Does there any roadmap exist to support ASP.NET Core 1.0?

Thanks, Alva

[VikingsFan]

@alvachien we will have a discuss about the roadmap after the 6.0.0 release, thanks :)

[mterwoord]

@VikingsFan Would contributions for asp.net core support be accepted?

[VikingsFan]

@mterwoord sure, contribution are always warmly welcome.

[mterwoord]

What's the branch to pick?

[VikingsFan]

vNext branch, but now we are not actively develop in this branch, we'll have a roadmap for this after 6.0.0 release

[andygjp]

@VikingsFan when will v6 be released?

[VikingsFan]

@alvachien 2-3 weeks after OData Lib release, OData Lib 7.0.0 beta is released, rtm will release around the end of this month

[aacanakin]

@alvachien Are there any updates on release date?

[bpenggithub]

Any updates on supporting ASP.NET Core 1.0?

[xuzhg]

@bpenggithub

Please follow up https://github.com/OData/WebApi/tree/vNext

And You are welcome to share your contributions.

Thanks.

[mowali]

@xuzhg and @VikingsFan are we as of now at the rtm phase of ODATA support to Core? I'm not interested in the alpha or beta, only stable release will convince my other coworkers in the team. I downloaded the sample and played with it. Most of its methods not working (I post a question about that) and I see that the sample project is using 6.0.0-alpha1-rtm, does it mean the ODATA is already rtm!? If not, when?

[xuzhg]

@mowali The OData support to Asp.Net Core is not finished yet. The development is still going on. However such development slowed down in the past three months. I think once new resources are founded, the development will speed up.

We do hope all of you can share us your contributions on the support OData for Core. Thanks!

[candidodmv]

I'm very excited about this.

[akorchev]

Hi. Is this feature still worked on?

[marcrocny]

Hello, what is the status on this? I see a fair number of commits on vNext but there hasn't been a release for a couple of years. Is vNext branch still accepting PRs?

[genusP]

View this issue #939

[lelong37]

+100, would be awesome to get OData in ASP.NET Core :)

[akorchev]

Is there any way at least to get the OData version for net452 working with asp.net core?

[ysmoradi]

@akorchev https://github.com/ysmoradi/OwinAspNetCore

[VVildVVolf]

As I see, it is possible to build it for the dotnet core. I checked the maintenance-aspnetcore, and after removing the 451 ref (tools/ResxGenerator/ResxGenerator.csproj and src/Microsoft.AspNetCore.OData/Microsoft.AspNetCore.OData.csproj) it works for the unix projects.

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

[akorchev]

@robward-ms thank you for the update! Would this version support .NET Core 1.0 or 2.0 only?

[robward-ms]

@akorchev - Great question, we're open to feedback on this. Much of the prototype work has been done on v1 so that is certainly achievable. However, we do want to stay current with the ASP.Net platform. What would you like to see?

[bdebaere]

@robward-ms Will there be significant changes or can a project be easily converted? Where can I read up on OData with .NET Core 2? Thank you for your time.

[robward-ms]

@bdebaere - We're trying to make the change very low impact to end user projects. At the moment, we have an API that is identical to the existing API except for the namespace. A global search-replace on namespace would be required (i.e. using System.Web.OData -> Microsoft.AspNet.OData) and hopefully little else.

[nigel-dewar]

Im excited about this. I LOVEEEEEEEEEEEEEEEEEE ODATA! and I really love .net core !

[ttugates]

Any chance we can get a link to any pre-release build of OData WebApi that supports ASP.Net Core?

[robward-ms]

@ttugates - Yep but we don't have one yet. Once we get a buildable set of changes in the features/netcore branch, we'll publish it as a Nightly Nuget package on MyGet. Timing wise, we hope to have an alpha on NuGet in the next several weeks.

[chriscerk]

Thanks for the updates and all the hard work, I know it will be much appreciated.

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

[Mollaee]

Dear @robward-ms , Would it be possible for you to let us know the status of the PR and any possible ETA? I understand the task in hand is really complicated and time consuming and from what we can see in your pull requests and comments, you and your teammates are working hard at it. Thank you for your hard efforts. I'm sure your accomplishment will help a lot of development teams using Web API in many projects.

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

[egbertn]

Did anybody have a working Unit Test end to end testing (including http) and IoC? Having difficulty on initializing a unit test on an OData Controller. It always returns 404.

From the unit test it initialises with var builder = WebHost.CreateDefaultBuilder().UseStartup<Startup>().UseDefaultServiceProvider(options => options.ValidateScopes = false); ....

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { var builder = new ODataConventionModelBuilder(app.ApplicationServices, true) { Namespace = typeof(company).Namespace };

        BuildOData(builder);
        app.UseMvc(options =>
        {
            options.Count().Filter().OrderBy().Select().MaxTop(null).Expand();
            options.MapODataServiceRoute("ODataRoute", "odata", builder.GetEdmModel());
            options.EnableDependencyInjection();

            var applicationPartManager = options.ApplicationBuilder.ApplicationServices.GetRequiredService<ApplicationPartManager>();
            applicationPartManager.ApplicationParts.Clear();

            //if (controllers != null)
            //{
                var part = new AssemblyPart(new MockAssembly(new[] { typeof(CommunitiesController) }));
                applicationPartManager.ApplicationParts.Add(part);
            //}

            // Insert a custom ControllerFeatureProvider to bypass the IsPublic restriction of controllers
            // to allow for nested controllers which are excluded by the built-in ControllerFeatureProvider.
            applicationPartManager.FeatureProviders.Clear();
            applicationPartManager.FeatureProviders.Add(new TestControllerFeatureProvider());

        });

public void ConfigureServices(IServiceCollection services) {

        services.AddMvc(options =>
        {
            //options.Filters.Add();
        }).AddApplicationPart(typeof(LahDiDahController).Assembly).AddControllersAsServices();

        services.AddTransient<ILadidah, Ladidah>();

public Startup(IHostingEnvironment env)
        {
            _iHostingEnvironment = env;
            var environmentName = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Debug"; 
            var builder = new ConfigurationBuilder()
                          .SetBasePath(System.IO.Path.GetDirectoryName(AppContext.BaseDirectory))
                          .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                          .AddJsonFile($"appsettings.{environmentName}.json")
                          .AddEnvironmentVariables("ASPNETCORE_");

            if (env.IsDevelopment())
            {
            }
            Configuration = builder.Build();
        }

[robward-ms]

@egbertn - There are now UTs and E2Es for AspNetCore checked in if this helps. Could you open an issue and include the controller and url you are using as well as the configuration?

[egbertn]

Hi @robward-ms thank you. I found the reason. My controller was named with casing say: MyController while the entitytype and the route was 'my'. In the previous OData version, this was solved automatically, (without ODataRoutePrefix) in the current version, the controller had to be renamed myController to get the routing fixed.

This also fixed my unit tests.

[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

[dimkoug]

When i try to add

services.AddOData(); i get reference error

the web appication is razor pages web application in asp core 3

[egbertn]

This was a .CORE 1.0 app. I do not maintain this repo. Sorry.