Adskilte WebView2-brugerdatamapper til forskellige proxy-ruter

En proxy, der leveres via AdditionalBrowserArguments, bliver en del af WebView2-browserprocessens startkommando. Redigering af dette indstillingsobjekt senere omskriver ikke den kørende proces' kommandolinje.

For en .NET-applikation, der opretter en uafhængig rute, skal du vælge en brugerdatamappe, som applikationen ejer, før kontrollen initialiseres:

var options = new Microsoft.Web.WebView2.Core.CoreWebView2EnvironmentOptions
{
    AdditionalBrowserArguments = "--proxy-server=http://proxy.example:8080"
};
var environment = await Microsoft.Web.WebView2.Core.CoreWebView2Environment
    .CreateAsync(userDataFolder: profileFolder, options: options);
await browser.EnsureCoreWebView2Async(environment);

profileFolder er en skrivbar mappe valgt af applikationen, og browser er den eksisterende ikke-initialiserede WebView2-kontrol. Kør initialiseringen gennem brugergrænsefladens normale asynkrone livscyklus. HTTP-proxylisten tilbyder kandidater til startflaget, når profilen skal foretage tilladte anmodninger til offentlige websteder.

Et nyt indstillingsobjekt er ikke en ny proces

Miljøer, der er knyttet til den samme brugerdatamappe, kan dele browserprocessen. Oprettelse af endnu et objekt med den mappe er ikke en måde at give det modstridende proxy-flag ved opstart.

For samtidige politikker via denne opstartsmekanisme skal du bruge separate miljøer med separate mapper. Det adskiller også deres webstedsdata; et andet miljø arver ikke automatisk det førstes logintilstand.

For at genbruge den oprindelige mappe med nye opstartsindstillinger skal du lukke de kontroller, der deler dens proces, og koordinere nedlukningen, før en erstatning initialiseres. At frigøre én kontrol, mens en anden holder processen i live, er ikke den overgang.

Hold miljøets og mappens livscyklus sammen med applikationen. Oprettelse af en ny browserproces for hver anmodning kan være meget dyrere end at vedligeholde et lille bevidst sæt ruter.