Separat WebView2-användardatamappar för olika proxy-rutter

En proxy som tillhandahålls via AdditionalBrowserArguments blir en del av startkommandot för WebView2-webbläsarprocessen. Att redigera det alternativobjektet senare skriver inte om kommandoraden för den körande processen.

För ett .NET-program som skapar en oberoende rutt väljer du en användardatamapp som ägs av programmet innan kontrollen initieras:

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 är en skrivbar mapp som valts av programmet, och browser är den befintliga icke-initierade WebView2-kontrollen. Kör initieringen via användargränssnittets normala asynkrona livscykel. HTTP-proxylistan erbjuder kandidater för startflaggan när profilen ska göra tillåtna förfrågningar till offentliga webbplatser.

Ett nytt alternativobjekt är inte en ny process

Miljöer som är kopplade till samma användardatamapp kan dela webbläsarprocessen. Att skapa ett annat objekt med den mappen är inte ett sätt att tilldela det motstridiga proxyflaggor vid start.

För samtidiga policyer via denna startmekanism använder du separata miljöer med separata mappar. Det separerar också deras webbplatsdata; en andra miljö ärver inte automatiskt den förstas inloggningsstatus.

Om du vill återanvända den ursprungliga mappen med nya startinställningar stänger du kontrollerna som delar dess process och samordnar avstängningen innan en ersättare initieras. Att göra sig av med en kontroll medan en annan håller processen vid liv är inte den övergången.

Behåll livscykeln för miljön och mappen hos programmet. Att skapa en ny webbläsarprocess för varje förfrågan kan vara mycket dyrare än att underhålla en liten, medveten uppsättning rutter.