Adskilte WebView2-brukerdatamapper for ulike proxy-ruter

En proxy som leveres via AdditionalBrowserArguments, blir en del av oppstartskommandoen til WebView2-nettleserprosessen. Å redigere dette alternativobjektet senere skriver ikke om kommandolinjen til den kjørende prosessen.

For en .NET-applikasjon som oppretter en uavhengig rute, velg en brukerdatamappe som eies av applikasjonen, 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 av applikasjonen, og browser er den eksisterende ikke-initialiserte WebView2-kontrollen. Kjør initialiseringen gjennom brukergrensesnittets normale asynkrone livssyklus. HTTP-proxylisten tilbyr kandidater for oppstartsflagget når profilen skal gjøre tillatte forespørsler til offentlige nettsteder.

Et nytt alternativobjekt er ikke en ny prosess

Miljøer knyttet til den samme brukerdatamappen kan dele nettleserprosessen. Å opprette et annet objekt med den mappen er ikke en måte å tildele det motstridende proxy-flagg ved oppstart.

For samtidige policyer gjennom denne oppstartsmekanismen, bruk separate miljøer med separate mapper. Det skiller også nettstedsdataene deres; et andre miljø arver ikke automatisk innloggingstilstanden til det første.

For å gjenbruke den opprinnelige mappen med nye oppstartsinnstillinger, lukk kontrollene som deler prosessen, og koordiner avslutningen før en erstatning initialiseres. Å kvitte seg med én kontroll mens en annen holder prosessen i live, er ikke den overgangen.

Hold livssyklusen til miljøet og mappen sammen med applikasjonen. Å opprette en ny nettleserprosess for hver forespørsel kan være mye dyrere enn å vedlikeholde et lite, bevisst sett med ruter.