Support for Microsoft.AspNet.OData 7?

[developermj]

Hello, I attempted to upgrade my WebApi 2.2 (.net 4.7 framework) app to OData 7.0.1. We quickly learned that swagger no longer provided any OData routes. Are there are thoughts on updating this library to support the newer version of OData library? Is there any guidance on the work that would need to be done so I could create a PR? TIA

[extinctPencil]

Hi I did this locally, Had no real issues with simply updating the references and namespace versions {absolutely} everywhere. I had a few additional issues to resolve along the way because I was using Microsoft.AspNet.OData.Versioning. Have got something that I am happy with , Not sure am ready for A PR though

[extinctPencil]

one gotcha was to be very explicit with the namespace of the following line in Swashbuckle.OData.HttpConfigurationExtensions

private static readonly MethodInfo GetODataRootContainerMethod = typeof(Microsoft.AspNet.OData.Extensions.HttpConfigurationExtensions).GetMethod("GetODataRootContainer", BindingFlags.Static | BindingFlags.NonPublic);

[developermj]

Are you able to share your code? I’d like to test it on my odata routes.

[extinctPencil]

try https://github.com/extinctpencil/Swashbuckle.OData and let me know Has to comment out some of the Non Odata AutoRest test as the AutoTest package not avaliable for this .net version

[andyward]

I also have a fork supporting the V7 OData at https://github.com/andyward/Swashbuckle.OData . I had to fix up the AttributeRoutingStrategy as there have been some internal changes in V7 that broke this. All tests pass (although I had to disable the RESTier tests as that's not yet compatible with V7 Odata).

[tntwist]

@andyward Nice. This works fine 👍

[Zzarek]

Ive been digging through swashbubkler.odata documentation for days now

I have a .Net Framework 4.7.1, the 4.0.0beta of this, and I am using Microsoft.AspNet.OData 6, trying to upgrade to 7.1.

Currently my app works as expected, however the upgrade causes swagger to drop all of my odata queries. I've personally never implemented swashbuckler and inherited this app, so im still not familiar with all the moving pieces.

For myself and others: What should I actually be using? This library? Something else? In all the swashbuckle libraries, its pretty hard to tell what has what I want. Is the only way to do it to pull @andyward s fork? Is there any intent to merge eventually?

[Zzarek]

To answer my own question - Apparently Swashbuckle.Odata.Core is Andys Fork.

[andyward]

Yes, it appears that https://www.nuget.org/packages/Swashbuckle.OData.Core/ is based off my fork. But it wasn't me that packaged it - and I've got no publish rights. Bear in mind it's slightly out of date so doesn't contain my updates to 7.1.0 OData. I suppose I could set up a semi-official Nuget/Myget feed if there was much interest.

The main reason you'd want to use my fork (or that package) is if you need functionality / fixes in the latest v7 Odata library and were unable/unwilling to migrate your wider system to .net core. If you can use ASP.NET core then Swashbuckle.Odata is really no use to you as it seems pretty tightly bound to WebAPI on netframework (or at least, supporting both platforms concurrently will be painful)

Some background for people asking about .net core support (#154):

OData v7 was major update with fundamental changes that enabled a single OData codebase to support ASP.Net Core in addition to what it always was built on: ASP.NET WebAPI on netframework. So you could run Odata on net core finally. Obviously, ASP.NET and ASP.NET Core are quite different architectures and interfaces so there's actually 2 different OData implementations (sharing a lot of logic): Microsoft.AspNet.OData and Microsoft.AspNetCore.OData, each in their own nuget package.

In developing OData v7 it seems Microsoft rationalized a load of namespaces to bring things into a Microsoft namespace - which is obviously a breaking change for any consumers, like this library. Fortunately there are very few significant changes at the code level. So namespaces and a few fixups are basically all I fixed up in my fork. It won't magically make this library work on ASP.net core

How things were
===============

netframework <- ASP.NET WebAPI <- Swashbuckle \
                         |                     |  <- Swashbuckle.OData  [This repo]
                         -----   OData v6  ---/ 

.net core brave new world
=========================

netframework <- ASP.NET WebAPI <- Swashbuckle \
                         |                     |  <- Swashbuckle.OData.Core  [My fork]
                         -----   OData v7  ---/ 
                         |
netcore      <-  ASP.NET Core <- Swashbuckle.Core  <- [n/a]

If you want to support for OData Swagger docs on .net core, I suspect you're either building something on Swashbuckle.Core, or as other have pointed out there's some OData Swagger support in the Microsoft Versioning repo

Hope that's useful.

[Zzarek]

Thanks for the write up. The nuget based on your fork solved my problems, I would of course be interested in updating your changes via nuget, but that is a lot of work on your end for just one guy with a fringe case.

I briefly debated .NET Core, but in the case of this application, I don't think that is a realistic goal, unless i choose to do it outside of company hours. It would almost be a total rewrite. There are 12 projects in the solution, and i think about 6 different .,Net framework targets among them. There were over 30 nuget packages that were different versions across the app when i inherited it. If you've ever seen a sitcom where two characters decide to split a room in half - this app is the personification of it. And im serious, i think the devs could not come to an architecture agreement and ended up each doing it their own way.

Minor complaints aside, This write-up was super informative about what is going on, and makes sense why it was so hard to find what i was looking for.