# OData Web API keeps OData v4 alive on ASP.NET and ASP.NET Core

> The OData/WebApi repository is the server side library that turns ASP.NET Web API and ASP.NET Core endpoints into OData services, and its branch layout is the clearest evidence that the ecosystem spans three generations of protocol and two generations of hosting stack.

**OData/WebApi** — OData Web API: A server library built upon ODataLib and WebApi

- Repository: https://github.com/OData/WebApi
- Website: https://docs.microsoft.com/odata
- Stars: 864 · Forks: 466
- Language: C#
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/odata-webapi

## A thin server layer over ODataLib and ASP.NET Web API

OData Web API, also referred to as ASP.NET Web API OData, is a server library that sits on top of two other things: ODataLib, the .NET implementation of the OData protocol, and Web API, the ASP.NET framework for HTTP services. That division of labour is the whole design. The protocol work, query option parsing, entity data model handling and serialization, lives in ODataLib. The HTTP hosting, routing, dependency injection and content negotiation, lives in Web API. This repository supplies the layer that binds the two together so that a controller or an endpoint class becomes an OData service. The intended reader of that arrangement is a .NET developer who already understands ASP.NET and now needs the OData conventions, and the repository is published by the OData organisation with the ASP.NET Web API OData package name.

## The branch list is the map of three protocol generations

The most useful thing in the README is its branch list, because it tells you exactly which lineage you are adopting. The master branch is the active development branch, is the most actively iterated, publishes the package Microsoft.AspNet.OData, and targets the ODataLib v7.x releases, which contain breaking changes against ODL v6. The release branch holds the codebase up to the most recently stable Web API release, with 6.0 as the latest release version on that line. The maintenance-aspnetcore branch covers the ASP.NET Core version under the package name Microsoft.AspNetCore.OData. The maintenance-V4 branch is based on ODL 6.x and implements the ODataV4 protocol, with 5.10 as its latest maintenance release, and maintenance-V3 is based on ODL 5.x, implements ODataV3, and ships as Microsoft.AspNet.WebApi.OData at 5.7. Reading that list before you pick a branch saves a lot of confusion about which package name to reference.

## Archive branches that look active but are not

Several branches exist purely as archives, and the README is explicit about it. The maintenance-dnx branch is the early prototype built on the original ASP.NET Core, the DNX era, published under the name Microsoft.AspNet.OData. It exists for archive purposes only, is not active, does not accept contributions, and has exactly one release. The odata-v5.3-rtm, v2.0-rtm, v3-rtm, v3.1-rtm and v3.2-rtm branches are described the same way: maintenance branches for previous RTMs, project archives only, contributions not accepted. The gh-pages branch holds the old documentation source, tutorials and guides, and the README redirects you to the Microsoft documentation for anything current. This pattern is the practical hazard of an old, widely forked repository: the branch you find through a search result or an old blog post may be a dead end, and the only reliable check is the package name plus the protocol version it targets.

## Building and testing hinge on strong name signing

The build is driven by a command script, and the test story has a specific precondition that trips up newcomers.

```sh
build.cmd
```

Each solution contains test projects and they use the xUnit runner nuget package. The important detail is that the tests will not run correctly unless SkipStrongNames is enabled, so the README asks you to run this first.

```sh
build.cmd EnableSkipStrongNames
```

To turn it back off:

```sh
build.cmd DisableSkipStrongNames
```

The same condition explains the Visual Studio instructions. If the test cases do not appear in the test explorer, the reason given is that the assemblies are delay signed and the private key is missing, so xunit will not load them, and the fix is the same EnableSkipStrongNames command. Running the end-to-end tests needs a command prompt running as administrator, or the solution opened with administrator rights in Visual Studio.

## Three build.cmd modes decide how much you run

The script has distinct verbs rather than a single build with switches. Running build.cmd with no arguments builds the projects, runs the unit tests and runs the OData end-to-end tests. The quick verb builds the project and runs the unit tests only, which is the right choice for a fast edit and test cycle on a machine where you do not want administrator rights. The EnableSkipStrongNames and DisableSkipStrongNames verbs toggle the signing behaviour described above, and are needed once per environment rather than per run. The repository layout backs this up: build.cmd and build.ps1 sit at the root next to the sln/ directory of solutions, the src/ tree of the library, the test/ tree, and tools/ for the supporting scripts. There is also a WebApiOData.Performance.msbuild file at the root, which indicates a performance measurement target in the build system.

## Nightly packages land on MyGet feeds, not on NuGet

Nightly builds are published to MyGet rather than to nuget.org, and there are two feeds because the v6 and v7 lines are separate. The v7.x.x packages go to the MyGet.org webapinetcore feed and the v6.x.x packages to the webapinightly feed, and the README gives the corresponding feed URLs for connecting a NuGet client to each. It also links a query URL for each feed that returns the four most recent packages with their id and version, which is the quickest way to confirm whether a nightly was actually published before you point a build at the feed. The practical implication is that a CI pipeline can consume nightly builds of this library without waiting for a public release, but it means your build depends on a third party feed that is outside the normal nuget.org trust and version pinning model.

## Where an OData service is the wrong shape for the job

OData is not a free upgrade from REST. The library gives you a query language, $filter and $orderby style query options, a metadata document describing the entity data model, and conventions for entity sets, navigation properties and projections. If your consumer is a hand written client that makes a handful of GET requests, that machinery is overhead rather than benefit, and a plain ASP.NET Core controller is less code, fewer conventions to learn and a smaller surface. The second limit is the .NET hosting model. The classic ASP.NET Web API line and the ASP.NET Core line are different packages with different hosting, different dependency injection and different middleware, so a library that supports both does so through separate branches and separate package names, and you pick one. The third limit is documentation. The repository does not carry the documentation itself, it points to the Microsoft documentation site, and the gh-pages branch is explicitly labelled as the old source. Anyone needing offline reference will find the repository thin on that front.

## Reporting, samples and the licence terms

Security issues and bugs go to the Microsoft Security Response Center by email, with a stated expectation of a response within 24 hours and a follow up if that does not arrive. The same instructions appear in the SECURITY.md file at the repository root, and the MSRC PGP key information lives on the Security TechCenter page. Samples are kept in a separate repository, the ODataSamples Repro, with ASP.NET Core samples in the WebApiCore folder and ASP.NET Classic samples in the WebApiClassic folder, and the repository itself also carries a samples/ directory with four ASP.NET sample web projects, including endpoint and OData samples for ASP.NET Core 3x. The project has adopted the .NET Foundation Contributor Covenant Code of Conduct, and contributions follow the guidance in .github/CONTRIBUTION.md. The licence is listed as a custom one that GitHub cannot classify, with the terms in License.txt at the repository root, so anyone embedding this in a commercial product should read that file rather than assume MIT.

## Conclusion

OData Web API suits a .NET team that has to expose an existing ASP.NET or ASP.NET Core application as an OData service and wants the query and metadata conventions handled by a library rather than by hand. It is the wrong choice for a greenfield project that only needs a REST API, because OData adds a query language and a metadata document that a plain controller does not, and it is the wrong choice for a team unwilling to read the Microsoft documentation, since the repository's own documentation is a redirect to that site. Before adopting it, confirm which branch line matches your protocol target, since the master branch targets ODataLib v7.x while the maintenance branches cover v6, v4 and v3, run build.cmd EnableSkipStrongNames before the test suite, and check the licence terms in the repository root. The last push was on 2026-09-23, with v7.8.1 released on the same day.

## FAQ

### What is OData Web API and which package should I use?

OData Web API is a server library built upon ODataLib and Web API that exposes ASP.NET and ASP.NET Core applications as OData services. The master branch publishes Microsoft.AspNet.OData for the ODataLib v7.x line, while the ASP.NET Core maintenance branch publishes Microsoft.AspNetCore.OData.

### Why do my OData Web API tests not run in Visual Studio?

The README explains that the test cases will not appear in the test explorer when the assemblies are delay signed and the private key is missing, so xunit will not load them. The fix is to run build.cmd EnableSkipStrongNames, and the end-to-end tests additionally need a prompt running as administrator or the solution opened as Administrator.

### Where are the nightly builds of OData Web API published?

Nightly NuGet packages are uploaded to MyGet rather than nuget.org. The v7.x.x packages go to the webapinetcore feed and the v6.x.x packages to the webapinightly feed, and the README links a query URL for listing the most recent packages on each feed.

### Which OData protocol versions does the OData Web API repository support?

The master branch targets the ODataLib v7.x releases, the release branch holds the stable 6.0 line, the maintenance-V4 branch is based on ODL 6.x and implements the ODataV4 protocol, and maintenance-V3 is based on ODL 5.x and implements ODataV3. Older branches such as maintenance-dnx and the various RTM branches are archive only.

### How do I report a security issue in OData Web API?

Security issues and bugs should be reported privately by email to the Microsoft Security Response Center at secure@microsoft.com, with a stated expectation of a response within 24 hours. The same instructions are in the SECURITY.md file in the repository root.

## Sources

- [Issues](https://github.com/OData/WebApi/issues)
- [OData/WebApi on GitHub](https://github.com/OData/WebApi)
- [Project website](https://docs.microsoft.com/odata)
- [README](https://github.com/OData/WebApi/blob/master/README.md)
- [Releases](https://github.com/OData/WebApi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/odata-webapi