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.
A Visual Studio 2017 and 2019 extension showing if methods are able to be inlined or not: https://github.com/szehetner/InliningAnalyzer
A good article on .Net Core runtime compatibility, including standard compatibility (same major version with higher or equal minor version) and some ways to force runtime selection (–fxversion, .runtimeconfig.json).
A funny post where we learn :
- the importance of docker multi-stage builds,
- the existance of an ultra miminal doker image called scratch ,
- that golang can produce pretty small binaries,
- that asm is really King.
Tiny Container Challenge: Building a 6kB Containerized HTTP Server!
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.
Interacting with APIs: REST and GraphQL | Google Cloud Blog
Short and concise: the minimum needed to introduce GraphQl to a non-developer audience that knows REST!
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