Cédric Luthi

Rebased again on master. Still crossing my fingers that this pull request might get some attention. 🤞

Freshly rebased on the `dev` branch, still crossing my fingers that this might get some attention. Ping @odinserj. The failing test on AppVeyor (Ubuntu only, passes on Windows) seems completely...

I just hit this same issue, also thinking that Refit might be the culprit. For me it did not take half a minute, just a few seconds (but very noticeable...

I think it was a good call to prefer `Microsoft.Data.SqlClient` over `System.Data.SqlClient` if both are installed in e243711e76b987e1952e4a0b05b7683305c9ad0a. Now, I went to great length in #2011 to use only reflection...

I have opened #2011 which addresses the problem by not taking a hard dependency on either `System.Data.SqlClient` or `Microsoft.Data.SqlClient`. This also solves the issue with `Hangfire.SqlServer.SqlCommandBatch` which is now compatible...

I just opened #1317 which is very closely related but goes a little bit further by exposing the full `RestMethodInfo` and also provides new `HttpRequestMessageOptions.InterfaceTypeKey` and `HttpRequestMessageOptions.RestMethodInfoKey` properties to ease...

> Seems this is an issue people seem to have a difference of opinion hence why I liked **my configurable approach**... :( If I understand correctly, you are talking about...

The issue (before this pull request) is that if you want to explicitly _always_ include a header in the cache key (e.g. the `Range` header) and the server returns a...

> OK apologies for not reviewing it earlier. No need to apologise, you get to choose your own pace! > Now if you are saying that the server sends wrong...

This pull request specifically addresses **uncaught** exceptions but of course it seems worth also handling caught exceptions! Do you think caught exceptions should also include the full call stack?