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
Juste pour quelques informations, l'équipe Blazor est en train de réduire considérablement l'empreinte de l'application et de recourir à 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éthode spécifiés par une instruction de lancer unique". Cela (au lieu de supprimer complètement la méthode) signifie que l'assembly conserve une surface API complètement standard, et si vous essayez d'utiliser l'une des méthodes effacées, vous obtenez une trace de pile d'exceptions facile à comprendre qui vous indique qui a été effacé méthode que vous essayez d'appeler.
Voici ce que vous avez rencontré: Blazor est toujours au courant de 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 HttpClient une implémentation de HttpMessageHandler Blazor a la sienne: BrowserHttpMessageHandler . Et Flurl fournit un moyen facile d'échanger cela via son HttpClientFactory . Mais vous n'avez pas besoin de passer dans une instance HttpClient ou d'implémenter CreateHttpClient . Au lieu de cela, DefaultHttpClientFactory de DefaultHttpClientFactory et remplacez simplement CreateMessageHandler :
private class HttpClientFactoryForBlazor : DefaultHttpClientFactory
{
public override HttpMessageHandler CreateMessageHandler()
{
return new BrowserHttpMessageHandler();
}
}
Je recommanderais également de l'enregistrer une 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 encore expérimental et que BrowserHttpMessageHandler pourrait être obsolète dans une future version , alors attendez-vous à ce que ce ne soit qu'une BrowserHttpMessageHandler temporaire.
Réponse populaire
Actuellement dans mon aperçu 3.0 5, BrowserHttpMessageHandler n'est plus là. Voici ma correction actuelle en n'utilisant simplement aucun HttpMessageHandler . Pour autant que je sache, aucun problème ne m'arrive encore, mais je ne suis pas sûr dans tous les cas d'utilisation:
class BlazorHttpClientFactory : DefaultHttpClientFactory
{
public override HttpClient CreateHttpClient(HttpMessageHandler handler)
{
return new HttpClient();
}
public override HttpMessageHandler CreateMessageHandler()
{
return null;
}
}
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow