Adopt the .NET8 IPNetwork instead of .NET6+ IPAddressRange

[WeihanLi]

.NET 8 introduced the IPNetwork, maybe we could use IPNetwork instead for net8.0

• IPNetwork Struct

[raman-m]

Hello, Weihan!
Welcome to Ocelot world from YARP one! 🤣

And how to support net7.0 and net6.0 ?
As you said, this new feature is available for net8.0 only.

If you find out this interesting, who will develop? 🥲

[ks1990cn]

@raman-m before this we have existing which is doing its job till .NET 8, we would be using if we go to .Net 8, I have question on it, do @WeihanLi wants something we haven't imagined?

[WeihanLi]

Yep, I meant for .NET 8 we could use the new IPNetwork, for net6.0/net7.0 we could keep using IPAddressRange, so that we could keep our library clean and less dependencies

Greatly happy that Ocelot continues and get more active, thank you very much to you guys for making it happen

[raman-m]

You are welcomed to Ocelot world again! I know you are old contributor of our repo. ❤️

We've prepared new release after v.21:

• Release 22.0 #1805

Regarding IPNetwork... What's the benefit here? 🆗 We've migrated to use IPNetwork, but what is a benefit for Ocelot?

[ks1990cn]

Any specific reason for this suggestion? I can see IPAddressRange is supported till .Net 8.

https://www.nuget.org/packages/IPAddressRange/#supportedframeworks-body-tab

[ggnaegi]

Hello

... too late, the others replied first...

I didn't know that Microsoft was offering this feature in .NET 8, but this implementation isn't supported in .NET 7 and .NET 6, whereas IPAdressRange is...

There are lots of interesting new features introduced with .NET 7 and .NET 8, such as the new rate limiters - I'll have to check whether it's now possible to combine them -. I think @RaynaldM would also like to see the new rate limiters integrated into the solution :-)

First of all we need to define the strategy for the future in order to avoid an out-of-control architecture (preprocessors all over the place)

[raman-m]

To be fair, @WeihanLi's idea is pretty abstract...
He needs to develop his idea more and show us real code snippets.

[RaynaldM]

To introduce new Net8 features (such as rate limiting), you can use the DI with directives such as :

    public static IOcelotBuilder AddPolly(this IOcelotBuilder builder)
    {
#if NET8_0_OR_GREATER
return builder;
#elif NET7_0
return builder;
#else // Net6.0
        var errorMapping = new Dictionary<Type, Func<Exception, Error>>
        {
            { typeof(TaskCanceledException), e => new RequestTimedOutError(e) },
            { typeof(TimeoutRejectedException), e => new RequestTimedOutError(e) },
            { typeof(BrokenCircuitException), e => new RequestTimedOutError(e) },
            { typeof(BrokenCircuitException<HttpResponseMessage>), e => new RequestTimedOutError(e) },
        };
        return AddPolly<PollyQoSProvider>(builder, GetDelegatingHandler, errorMapping);
#endif
    }

In the code itself, you can also use this kind of directive, but be careful not to overuse it, as it can be a pain to maintain and test.

To switch from one .Net version to another, click here

Normally unit tests are automatically passed for each .Net version.

[raman-m]

Wow! Ray is online! 💥 Lunch time? 😉

[ggnaegi]

@raman-m @RaynaldM for features like the Rate limiters, I would go a step further for clarity, such as

#if NET7_0_OR_GREATER
            Services.TryAddSingleton<IRequestMapper, RequestMapper>();
#else
            Services.TryAddSingleton<IRequestMapper, RequestMapper>();
#endif

Trying to avoid the preprocessors in the interface implementations.

[raman-m]

Preprocessor directives won't be required if we develop native feature and encapsulate .net8.0 interfaces...
But I'm afraid, having .NET 6-7-8 multitargeting requires to have some preprocessing by compiler. Well... This is design challenge.

[RaynaldM]

" I think @RaynaldM would also like to see the new rate limiters integrated into the solution :-)"

Not only that 😃

[raman-m]

Ray, we are not your personal development team for free! 🤣 😉