Cannot disable the default API versioner when upgrading from .NET Core 2.2 to 3.1

Question

I'm currently going through the process of upgrading from 2.2 to 3.1.

In doing so .NET's default api-versioner is running along side ours despite adding the code to remove this:

Is there a new way to register a custom versioner or is there a new approach to removing .NET's default one after calling 'AddApiVersioning'.

        services.AddControllers(opts =>
        {
            opts.Filters.Add<DatedApiVersionFilter>();
        });

        // add standard asp.net core versioning mechanism
        services.AddApiVersioning(o =>
        {
            o.ApiVersionReader = new HeaderApiVersionReader(PlatformVersioningOptions.VersionHeaderName);
            o.DefaultApiVersion = new ApiVersionDate(2020, 1, 31);
            o.AssumeDefaultVersionWhenUnspecified = true;
        });

        // removing the default api version policy        
        services.Remove(services.Single(s => s.ImplementationType == typeof(DefaultApiVersionRoutePolicy)));
        services.TryAddEnumerable(ServiceDescriptor.Singleton<MatcherPolicy, DatedApiVersionMatcherPolicy>());
        services.AddSingleton<IDatedApiVersionResolver, DatedApiVersionResolver>();

score 1 · Accepted Answer · answered Sep 30 '20 at 09:04

1

I've managed to solve this by removing the call to 'services.AddApiVersioning()'.

It seems in .NET Core 3.1 adding the filter with the new 'AddControllers' extension is enough to kick off our versioning policy for any endpoint decorated with the filter.

Final implementation:

        services.AddControllers(opts =>
        {
            opts.Filters.Add<DatedApiVersionFilter>();
        });

        services.TryAddEnumerable(ServiceDescriptor.Singleton<MatcherPolicy, DatedApiVersionMatcherPolicy>());
        services.AddSingleton<IDatedApiVersionResolver, DatedApiVersionResolver>();

answered Sep 30 '20 at 09:04

Wilcko

158
8

I'm kind of curious why you need to roll your own policy. Was there some capability that API Versioning wasn't providing? – Chris Martinez Oct 06 '20 at 19:06
Hi Chris, It due to the fact we've built our own versioning policy using dates. This is for ease of use for developers integrating with us. They can specify a version of '2020-10-09' and it will automatically roll back to the most recent version. This is especially useful when we have one microservice call another – Wilcko Oct 09 '20 at 12:06
Interesting... Dates are supported for an API version and there are some extension facilities that would probably achieve your goal. _Auto-magically_ giving a client anything other than what they asked for is potentially dangerous and unpredictable. The server can't and shouldn't assume the client can necessarily handle anything new or old. Sounds like you have a closed ecosystem, however, so perhaps you can get away with it there. – Chris Martinez Oct 09 '20 at 18:20
As an alternative to blindly going forward or backward, there are at least two additional mechanisms that could be used with API Versioning. If you _report_ the API versions and a client asks for a version that is no longer available, it _may_ be able to make the right choice based on versions reported by the server. A client might also preflight and occasionally poll an endpoint with `OPTIONS` to see which versions are available. Adaptive clients are fine, but they should make the decision; otherwise, you probably don't need versioning and can just use network routing policies. – Chris Martinez Oct 09 '20 at 18:25

Cannot disable the default API versioner when upgrading from .NET Core 2.2 to 3.1

1 Answers1