Here’s a bold statement: The future of OData .NET is here, but it’s not without its controversies. Microsoft has just shipped OData .NET (ODL) 9.0.0 Preview 3, the latest step in modernizing this essential library. But here’s where it gets controversial: while the update promises safer defaults, cleaner APIs, and tighter spec compliance, it also introduces breaking changes that could leave some developers scratching their heads. Is this a step forward or a leap into uncharted territory? Let’s dive in.
This preview builds on earlier 9.x iterations, focusing on aligning with the OData specification and addressing developer feedback. For instance, action query execution now uses SingleOrDefault() semantics for nullable references, reducing those pesky null-related exceptions. Sounds great, right? But this is the part most people miss: legacy serialization constructors tied to ISerializable are gone, which means no more build warnings on modern SDKs—but also potential headaches for those still relying on older code. Similarly, the CsdlTarget concept is out, and obsolete return type accessors are deprecated in favor of newer EDM interfaces. These changes are a double-edged sword: they streamline the library but require careful migration.
One of the most significant updates is the enforcement of structured type deserialization for untyped values, bringing runtime behavior closer to the official OData JSON format. Untyped numeric values now default to specific CLR numeric types, though a compatibility flag is available for legacy results. This is a win for consistency, but it’s also a breaking change that demands attention. Upgrading from the stable 8.x line to 9.x? Proceed with caution. Developers need to review nullable return handling, expected JSON shapes, and any dependencies on removed APIs. And remember, since 9.x is still in preview, it’s not recommended for production without thorough testing.
But here’s the bigger picture: the OData ecosystem is evolving rapidly. ASP.NET Core OData packages have already moved into their own 9.x+ series, with stable releases like Microsoft.AspNetCore.OData 9.4.x. This signals a parallel advancement of service-side and client-side stacks, but it also raises questions: Are we moving too fast? Will developers be able to keep up?
Here’s a thought-provoking question for you: As OData .NET pushes toward runtime compatibility with .NET 8/9/10 and relies more on platform-built APIs, are we sacrificing backward compatibility for progress? Let us know your thoughts in the comments.
For those eager to contribute or stay updated, the OData/odata.net GitHub repository and the official OData blog are your go-to resources. Follow them for preview announcements, migration guides, and roadmap updates as we inch closer to the stable 9.0 release.
About the Author: Edin Kapić
