PolySharp VS Polly

Great improvements.

There is PolySharp project that enables you to use most of C#11 features in legacy .NET Framework: https://github.com/Sergio0694/PolySharp - Seems that C#12 features are planned to be implemented: https://github.com/Sergio0694/PolySharp/issues/78

I'm using PolySharp where I'm stuck with .NET Framework 4.6 and I don't have any issues.

Hope one day I'd see concise syntax for catch and/or try expressions: https://github.com/dotnet/csharplang/discussions/2734 - but there is a lot of resistance.

You can go one step further and add https://github.com/Sergio0694/PolySharp to your project and you can use new C# 8+ features that don't require the new runtime (like file scoped namesapces, nullable annotations etc).

Is there a reason you're trying to reinvent PolySharp?

You can still use C# 11 (with PolySharp), and you can still get a huge amount of new APIs via the various packages on NuGet that target .NET Standard 2.0. Plus you just get the usual .NET type system and BCL, which are still very good even if when using a framework from a few years ago.

Or the PolySharp NuGet package, which uses source generators to polyfill the language features you're actually using.

Here's some: - MVVM Toolkit - PolySharp - ComputeSharp

Well using PolySharp, of course! 😄

⚠️ Because PolySharp uses source generators, it doesn't work with the package.config file as stated in this issue. The issue says we need to use the SDK style .csproj, but just changing from package.config to Package Reference worked for me.

Some features like records and range require additional boilerplate classes to be added to become usable. You can DIY that or use PolySharp. Some features like static abstract members, default interface methods, etc require runtime support and can't be used.

In our applications, we should wrap all requests to remote services in code that implements a retry policy that follows one of the strategies I listed earlier. If you are a .NET developer like myself, you may be familiar with the Polly library. Golang has a library called Retry, and there are numerous third-party libraries for Python and Java.

Another question that rises is, would it be better to use some HttpClient package to handle the requests, like Refit in combination with Polly. But then again, it seems Refit also uses the HttpClient factory, which was a bad thing according to the previous?

D'Oh! Sorry, not PolySharp. I meant Polly. Too many similarly-named libraries!

Everywhere I've worked with AGs, we've worked with the application team to add retry logic to help make things a bit more seamless to end users. There are libraries out there that can make this pretty easy - Polly is one that I've used a few times, but there are others.

Fallacy 1: The network is reliable. If system 2 works perfectly well, but is not accessible for service 1 due to network issues, service 2 is still unavailable. This is why timeouts, service breakers and retry policies exist. A great tool for .NET to handle common network issues is Polly, but even when using a tool like this, the network is still not completely reliable.

I see. Then I don't have any better idea right now, but I do want to suggest that if your script is mostly API calls and you want to be able to deal with failures then take a look at the polly library: https://github.com/App-vNext/Polly

Runs in containers nicely, has good integration with Kafka, RabbitMQ, gRPC, etc. for Microservices communication. Implements resiliency patterns you'd want in Microservices via Polly. Has a decent Dependency Injection framework built in by default.

It's in no way hidden. But I use Polly all the time.

Depending if the sender or the reciever is down, you can also try Polly http://www.thepollyproject.org/