Here’s a bold statement: The future of OData .NET is here, and it’s packed with changes that could reshape how developers work with this powerful library. But here’s where it gets controversial: while Microsoft’s latest preview promises safer defaults and modern APIs, it also introduces breaking changes that might leave some developers scratching their heads. Let’s dive in.
Microsoft has just shipped OData .NET (ODL) 9.0.0 Preview 3, the newest iteration in its ongoing effort to modernize the OData .NET client and core libraries. This release isn’t just about polishing the edges—it’s a significant step toward aligning the library with the latest OData specifications and making it more developer-friendly. The focus? Safer default behaviors, a cleaner runtime API, and tighter compliance with the OData spec as the team gears up for a stable 9.x release. You can check out the details here.
And this is the part most people miss: While the current stable release of the core OData .NET libraries (like Microsoft.OData.Core) remains on the 8.4.x line on NuGet, with version 8.4.3 being the latest stable package GitHub link, the 9.x series is still in preview. This means the 8.4.x line, which supports OData v4/v4.01, is still widely used in production. The 9.x releases, however, are where the action is—but they’re not quite ready for primetime yet Preview 3 link.
Preview 3 builds on the conventions introduced in earlier 9.x previews but tightens things up based on developer feedback and closer alignment with the OData specs. Here’s what’s new:
- Action query execution now uses SingleOrDefault() semantics for nullable references. This reduces unexpected exceptions for null responses while keeping strict checks for non-nullable values—a win for both safety and predictability.
- Legacy serialization constructors tied to ISerializable have been removed, eliminating those pesky build warnings on modern SDKs.
- The CsdlTarget concept is gone, and obsolete return type accessors have been deprecated in favor of newer EDM interfaces. Think of it as spring cleaning for your codebase.
- Obsolete APIs around the ReturnType property on IEdmOperation have been fully replaced with the newer IEdmOperationReturn abstraction, streamlining how you work with operation returns.
These changes aren’t just cosmetic. They’re part of a broader push toward runtime compatibility with .NET 8/9/10, lower memory allocation patterns (like adding ReadOnlySpan
Here’s where it gets interesting: One of the most significant behavioral changes in Preview 3 is the enforcement of structured type deserialization for untyped values. No more ReadUntypedAsString toggles—this brings runtime behavior into closer alignment with the official OData JSON format OData JSON format link. Additionally, untyped numeric values now default to inferring specific CLR numeric types, with a compatibility flag for legacy results (numbers parsed as decimal).
But here’s the catch: Upgrading from the stable 8.x line to the 9.x preview NuGet packages isn’t a walk in the park. Developers need to treat it as a breaking change, reviewing nullable return handling, expected untyped JSON shapes, and any reliance on removed legacy APIs. Since the 9.x releases are still in preview, they’re not recommended for production use without thorough testing. Proceed with caution!
The broader OData ecosystem is evolving too. For instance, the ASP.NET Core OData packages have moved into their own 9.x+ series, with stable releases like Microsoft.AspNetCore.OData 9.4.x NuGet link. This signals that both service-side and client-side OData stacks are advancing in parallel, giving developers more flexibility and power.
If you’re eager to contribute feedback or stay in the loop on stabilization plans, follow the OData/odata.net GitHub repository GitHub link and the official OData blog OData blog link. These are your go-to sources for preview announcements, migration guidance, and roadmap updates as we inch closer to the stable 9.0 release.
Now, here’s a thought-provoking question: With all these changes, is Microsoft moving too fast, or is this exactly what developers need to stay ahead in a rapidly evolving tech landscape? Let us know in the comments—we’d love to hear your take!
About the Author
Edin Kapić
