A rate limiting package for .NET

Two new interesting packages are coming to .Net: System.Threading.RateLimiting and Microsoft.AspNetCore.RateLimiting.

A very good introductory article can be found here: https://devblogs.microsoft.com/dotnet/announcing-rate-limiting-for-dotnet/.

Even if this package is announced as a new feature of version 7.0, System.Threading.RateLimiting is a .Net runtime package targeting :

  • .Net Framework 4.6.1,
  • .Net Standard 2.0,
  • .Net 6.0,
  • .Net 7.0

making it a solution for all needs (It’s use is not restricted to http requests handling). The aforementioned article shows how to use it in DelegatingHandler to limit outgoing http requests but it an edge case.

Main use is obviously for processing incoming http requests. For this usage, a .Net 7.0 Microsoft.AspNetCore.RateLimiting package is also provided by Microsoft. It’s mainly a rate limiting middleware hiden behind policies. Policies are named configurations of rate limiters usable in http pipeline branches.

The design of the API seems extensible and clean, it will have to be seen in use. The only regret is that Middleware is only available for .Net 7, a non-LTS release.

How to prevent End of Life warning when building for deprecated .Net versions

With increasingly rapid evolutions of Framework, it is sometimes desirable to remain, for some projects, with deprecated versions of .Net.

It must be a conscious decision of the risks but you must be able to say “I accepted this risk and I don’t want to be bothered by these warnings anymore”.

One solution is to set precisely the version number of the SDK used for that compilation by using a global.json file. Doing so ensure you also use same deprecated SDK.

But you could prefer to use a more recent SDK while building for an ancient target.

And without warning. That’s exactly what CheckEolTargetFramework permit us to do: it’s a MSBuild property that can be set to to false to prevent warning NETSDK1138.

More on this subject on Fixing build warning NETSSDK1138 when building projects with end-of-life .NET frameworks.

Azure App Configuration and dynamic reloading

Azure App Configuration (still in preview) is a very simple way of uploading appsettings.json to azure. Add nuget Microsoft.Extensions.Configuration.AzureAppConfiguration and a call to extension method AddAzureAppConfiguration. Then only a single connection string is required to acces it (bbest practice is to set it into environment variable).

Pretty cool with a better granularity than key vault (granularity at file level instead of entry level).

A Watch method is available to implement 30 seconds reload on specifics parts. A better option should have been to use a WebHook called on each changes (perhaps an incoming evolution).

ASP.NET Blog | Configuring a Server-side Blazor app with Azure App Configuration