In software, an component is one that automatically updates itself in the background without user intervention or application restarts. Think of Google Chrome, Microsoft Edge, or Firefox. You almost never download a "Chrome 2024 Edition" installer. You simply open the browser, and it is always fresh.

So go ahead—build that desktop wrapper. Integrate that OAuth flow. Render that complex report. Let Microsoft handle the runtime. Because the web changes every day. Your app should too.

Introduction: The Heartbreak of WebView Runtimes For nearly a decade, developers building hybrid desktop applications on Windows faced a frustrating dilemma. You could either bundle a full Chromium browser (adding 80–100MB to your installer), rely on the legacy, outdated Trident engine (Internet Explorer), or depend on the user’s local, unpredictable Edge HTML engine.

<!-- MainWindow.xaml --> <Window xmlns:wv2="clr-namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2.Wpf"> <Grid> <wv2:WebView2 x:Name="webView" /> </Grid> </Window>

var options = new CoreWebView2EnvironmentOptions(); var env = await CoreWebView2Environment.CreateAsync( userDataFolder: @"C:\AppData\UserA" ); The "Evergreen WebView2" is not a niche feature; it is the default, recommended, and future-proof way to embed web content in Windows applications. Microsoft’s own guidance is clear: Unless you have a specific compliance or offline requirement, use the Evergreen distribution model.

In the Electron era, a user with five desktop apps had five separate Chromium runtimes on their SSD, each occupying 150MB. That’s 750MB of pure duplication. Each app had its own updater, its own crash reporting, and its own separate sandbox processes.