Question
Après la mise à jour de Blazor de 0.5.1 (avec Flurl actif) à 0.6.0, les appels via flurl génèrent une exception:
WASM: [Flurl.Http.FlurlHttpException] Call failed. Cannot invoke method
because it was wiped. See stack trace for details.
Le projet crée un HttpClientFactory qui obtient le HttpClient de Blazor pour être utilisé par Flurl:
Créez FlurlClient avec HttpClient (http) de Blazor à l'aide de HttpClientFactoryForBlazor:
IFlurlClient c = new FlurlClient() { Settings = new Flurl.Http.Configuration.ClientFlurlHttpSettings { HttpClientFactory = new HttpClientFactoryForBlazor(http) }};
Utilisez le FlurlClient (c) par exemple via la méthode d'extension de Flurl "IFlurlRequest.WithClient (c);"
private class HttpClientFactoryForBlazor : Flurl.Http.Configuration.IHttpClientFactory
{
private readonly HttpClient httpClient;
public HttpClientFactoryForBlazor(HttpClient httpClient)
{
this.httpClient = httpClient;
}
public virtual HttpClient CreateHttpClient(HttpMessageHandler handler)
{
return this.httpClient;
}
}
Il semble donc que cette approche ne fonctionne plus.
Est-ce que quelqu'un sait comment faire fonctionner Flurl avec Blazor 0.6.0?
Call-Stack c'est:
WASM: [Flurl.Http.FlurlHttpException] Call failed. Cannot invoke method because it was wiped. See stack trace for details. GET http://srv01.servicegrid.eu:4455/API/Status?forceLoadDbs=False blazor.webassembly.js:1:32098
WASM: at Flurl.Http.FlurlRequest.HandleExceptionAsync (Flurl.Http.HttpCall call, System.Exception ex, System.Threading.CancellationToken token) <0x26945b8 + 0x001c2> in <c38761af4558433f81b1691eb86a1548>:0 blazor.webassembly.js:1:32098
WASM: at Flurl.Http.FlurlRequest.SendAsync (System.Net.Http.HttpMethod verb, System.Net.Http.HttpContent content, System.Threading.CancellationToken cancellationToken, System.Net.Http.HttpCompletionOption completionOption) <0x2665d30 + 0x005e6> in <c38761af4558433f81b1691eb86a1548>:0 blazor.webassembly.js:1:32098
WASM: at Flurl.Http.FlurlRequest.SendAsync (System.Net.Http.HttpMethod verb, System.Net.Http.HttpContent content, System.Threading.CancellationToken cancellationToken, System.Net.Http.HttpCompletionOption completionOption) <0x2665d30 + 0x0079a> in <c38761af4558433f81b1691eb86a1548>:0 blazor.webassembly.js:1:32098
WASM: at Flurl.Http.HttpResponseMessageExtensions.ReceiveJson[T] (System.Threading.Tasks.Task`1[TResult] response) <0x26a2180 + 0x000d6> in <c38761af4558433f81b1691eb86a1548>:0 blazor.webassembly.js:1:32098
WASM: at DotNetFabrik.FlurlExtensions.FlurlRequestExtensions.HandleWebApiExceptions[T] (System.Threading.Tasks.Task`1[TResult] task) <0x26a43f8 + 0x000e2> in <8c1e6df9d3f545cd831ff49915df2d85>:0 blazor.webassembly.js:1:32098
WASM: at DotNetFabrik.FlurlExtensions.FlurlRequestExtensions.HandleWebApiExceptions[T] (System.Threading.Tasks.Task`1[TResult] task) <0x26a43f8 + 0x00264> in <8c1e6df9d3f545cd831ff49915df2d85>:0 blazor.webassembly.js:1:32098
WASM: at BlazorCoreDMSTools.CommunicationService.CommunicationService.SetTokenAsync (System.String token, System.String database, System.String serverUri) <0x260dc60 + 0x00d9e> in <cb925648b50340888772566fbaeac465>:0
Réponse acceptée
Pour mémoire, l’équipe Blazor est en train de réduire considérablement l’empreinte de l’application, et a recours à des mesures inhabituelles pour le faire. En un mot, ils l'ont réduit d'environ 20% en "effaçant" HttpClientHandler .
wipe signifie "remplacer les corps de méthodes spécifiés par une instruction de projection unique". Faire cela (au lieu de supprimer complètement la méthode) signifie que l’assemblage conserve une surface d’API complètement standard et si vous essayez d’utiliser une des méthodes effacées, vous obtenez une trace de pile d’exceptions facile à comprendre qui indique méthode que vous essayez d'appeler.
C'est ce à quoi vous vous heurtez: Blazor connaît toujours HttpClientHandler à des fins de compilation, mais HttpClientHandler une exception d'exécution si vous (ou dans ce cas une bibliothèque compatible) essayez de l'utiliser.
Mais HttpClient doit envelopper une implémentation de HttpMessageHandler Blazor a son propre: BrowserHttpMessageHandler . Et Flurl fournit un moyen simple d’échanger cela via son HttpClientFactory . Mais vous n'avez pas besoin de transmettre une instance HttpClient ou d'implémenter CreateHttpClient . Au lieu de cela, DefaultHttpClientFactory de DefaultHttpClientFactory et substituez simplement CreateMessageHandler :
private class HttpClientFactoryForBlazor : DefaultHttpClientFactory
{
public override HttpMessageHandler CreateMessageHandler()
{
return new BrowserHttpMessageHandler();
}
}
Je recommande également d'enregistrer cette fois globalement au démarrage de l'application, plutôt que chaque fois que vous créez un FlurlClient :
FlurlHttp.Configure(settings =>
{
settings.HttpClientFactory = new HttpClientFactoryForBlazor();
});
Il convient également de noter que Blazor est toujours expérimental et que BrowserHttpMessageHandler pourrait être obsolète dans une version ultérieure. BrowserHttpMessageHandler vous donc à une BrowserHttpMessageHandler temporaire.
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow