Error when trying to create a new instance of SendGridClient()
System.IO.FileLoadException: Could not load file or assembly 'Polly, Version=5.2.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
at SendGrid.Helpers.Reliability.RetryDelegatingHandler.ConfigurePolicy()
at SendGrid.SendGridClient.CreateHttpClientWithRetryHandler() in C:\Users\ethomas\Documents\GitHub\sendgrid-csharp\src\SendGrid\SendGridClient.cs:line 198
at SendGrid.SendGridClient..ctor(HttpClient httpClient, SendGridClientOptions options) in C:\Users\ethomas\Documents\GitHub\sendgrid-csharp\src\SendGrid\SendGridClient.cs:line 107
at SendGrid.SendGridClient..ctor(String apiKey, String host, Dictionary`2 requestHeaders, String version, String urlPath) in C:\Users\ethomas\Documents\GitHub\sendgrid-csharp\src\SendGrid\SendGridClient.cs:line 137
Sample code used:
class Program
{
static void Main(string[] args)
{
var apiKey = "API_KEY_HERE";
var client = new SendGridClient(apiKey);
}
}
Already trying to install Polly from NuGet, 5.2 non-signed, 5.2 signed, 5.3 non-signed, 5.3 signed. all don't work. Clean project, rebuild, all failed.
Solved by downgrading sendgrid library version to 9.5.2
@wildanr I think it can be solved by by adding the below dependency in the .nuspec file for Sendgrid 9.6.0 <dependency id="Polly" version="5.2.0" /> under <dependencies>
@dylan-asos were you referring to this dependency?
Please don't do this stupidity. Polly doesn't do binding redirects properly, has 2 separate dlls that might be needed and more.
Why the heck can't this client be a simple rest wrapper that uses standard HttpClient and nothing else? This is trivial and yet you've made a complete mess of it.
(and for the record it's incredibly bad practice by any definition to add new dependencies for a minor version!)
@JohnGalt1717,
I think you are right, I needed to make this a major version bump.
With regards to the added functionality, what would you suggest? I don't really want more dependencies either, but I think this is useful functionality that has been requested across all our SDKs.
I'll be looking back at this later today.
Thank you so much for taking the time drop in with this valuable feedback!
With Best Regards,
Elmer
What functionality requires polly?
@JohnGalt1717 Transient fault handling, achieved by this PR.
@thinkingserious the Azure Storage SDK has a pretty decent timeout & retry policy setup, but they rolled their own. It could be a good reference if this functionality should be built-in to the library. It's also Apache 2.0 licensed so most of the code could be copied over as long as a copyright notice stays with it.
None of my email is sent in real-time, instead a message is added to a Storage Queue and then processed/sent from an Azure WebJob. If a send fails it'll try again automatically and then after X times it'll move it to the poison queue and move on. Because of this I don't need a retry policy on the SendGrid client and I don't want another dependency that isn't going to be used.
It's pretty simple to create exactly what this is doing in your code:
`try
{
var response = await _Client.PostAsync("url", content);
if (response.IsSuccessStatusCode)
{
//Your good
}
else
{
//It was rejected by the server. This is not a timeout this is a throw something to the user.
}
}
catch (Exception ex)
{
if (ex is WebException || ex is HttpRequestException)
{
if (retryCount < 2)
{
retryCount++;
//Sleep your thread right here for a random amount of time multiplied by the retryCount
goto retry;
}
}
throw;
}`
This is with the default HttpClient that is built into C# that would also allow you to get rid of the other HttpClient that you have separately as yet another nuget package that I fail to understand why you're rolling your own when it's built into the framework.
The same will work just fine with WebRequests too.
This is EXACTLY what entityframework does on Azure with transient failures. It's a count up delay and you let your users set the max-retry count and you're done and no silly dependencies for no reason.
Now if you could just get rid of the absolutely stupid use of dynamic and strongly type everything the way everyone in the C# and not script kiddie world works life would be good. There are less than 5 reasons to ever use the dynamic keyword in C# and absolutely NONE of them are applicable to SendGrid.
Thanks @xt0rted, that's very helpful feedback!
@JohnGalt1717, with regards to dynamic typing, I believe you must be referring to a previous version of this SDK. This version is strongly typed.
Based on the feedback so far, here is my proposal:
With Best Regards,
Elmer
That's a good start.
@JohnGalt1717 May I suggest you have a look at StrongGrid which is an alternative C# client for SendGrid's API (disclaimer: I'm the author). The main differences with SendGrid's own client are:
HTTP 429 along with proper backoff to respect their documented rate limiting logicASP NET Core, NetCore app in addition to .net 4.5.2Let me know if this is helpful
Jericho
Hello Everyone!
Thanks again for the great and fast feedback!
I have:
@dylan-asos has offered to rework the original PR without including the dependency to Polly (awesome!). I believe that with the pointers and feedback given here and on that thread, we will end with a great solution.
When @dylan-asos opens that PR, I'll ping the interested parties here on that thread.
With Best Regards,
Elmer
Most helpful comment
Solved by downgrading sendgrid library version to 9.5.2