You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our UWP app , We have a feature that allows a user to switch between fixed version of webview2 and the windows 11 default version of webview2.
This works well with the default option of using webview2 that comes with windows 11 - 136.0.3240.64.
If there are any issues with the default version , then user has the option to switch to the tested version available from the server.
We don't want to bundle the fixed version of webview2 libraries to the UWP app installation as the package size becomes huge and users won't install the app. We already has a bundled version in the store and we have to move away from the huge UWP package bundled with webview2.
So we have the tested version 135.0.3179.98 copied to the server as a single zip file. When user selects the fixed version option from the settings,
the webview2 zip file will be streamed and downloaded from the server and the zip file is extracted and copied to the Appdata folder.
And during the start of the app, the environment would be pointed to that folder where it is copied.
In a working environment we would be having multiple instances of webview2 runs at the same time. But in the ondemand fixedversion downloaded , webview2 instances doesn't navigated to the urls and it crashes the app after sometime and is black. I have compared the files downloaded from the server with the files in the Microsoft actual packages and all are same.
Any idea how to fix this fixed version issue?
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
135.0.3179.98
SDK Version
Microsoft.UI.Xaml -2.8.6
Framework
WinUI2/UWP
Operating System
Windows 11
OS Version
No response
Repro steps
Create a UWP app with page have multiple panels hosting the webview2 controls. Each webview2 control instances navigate to different urls.
Download the 135.0.3179.98 version of fixed version from microsoft server and extract to the app's path
Windows.Storage.ApplicationData.Current.LocalFolder.Path
Point the webview2 environment in the mainpage when the app gets loaded .
string AppPath = Path.Combine(Windows.Storage.ApplicationData.Current.LocalFolder.Path, _companyName, _appName);
DotNet-Fan
changed the title
[Problem/Bug]: Switching between FixedVersion webview2 and windows 11 webview2
[Problem/Bug]: FixedVersion webview2 and windows 11 webview2
May 10, 2025
@Navdeep-ss It doesn't work if we don't set or set the WEBVIEW2_USER_DATA_FOLDER environment variable.
You can test manually by extracting the fixedversion downloaded from microsoft site and extract to the App folder pointed by the code Windows.Storage.ApplicationData.Current.LocalFolder.Path . Then point the Webview2 component to point to this path by setting environment Environment.SetEnvironmentVariable("WEBVIEW2_BROWSER_EXECUTABLE_FOLDER", fixedPath);
@victorhuangwq I don't get any responses from @Navdeep-ss or @sivMSFT on this issue which is an important one for us .
Earlier you have responded to the below fixedversion question. So i have copied you for this. #4271
Any idea how to fix this scenario where the fixedversion would be downloaded from the server and pointed to that version?
Uh oh!
There was an error while loading. Please reload this page.
What happened?
In our UWP app , We have a feature that allows a user to switch between fixed version of webview2 and the windows 11 default version of webview2.
This works well with the default option of using webview2 that comes with windows 11 - 136.0.3240.64.
If there are any issues with the default version , then user has the option to switch to the tested version available from the server.
We don't want to bundle the fixed version of webview2 libraries to the UWP app installation as the package size becomes huge and users won't install the app. We already has a bundled version in the store and we have to move away from the huge UWP package bundled with webview2.
So we have the tested version 135.0.3179.98 copied to the server as a single zip file. When user selects the fixed version option from the settings,
the webview2 zip file will be streamed and downloaded from the server and the zip file is extracted and copied to the Appdata folder.
And during the start of the app, the environment would be pointed to that folder where it is copied.
string AppPath = Path.Combine(Windows.Storage.ApplicationData.Current.LocalFolder.Path, _companyName, _appName);
System.Environment.SetEnvironmentVariable("WEBVIEW2_USER_DATA_FOLDER", AppPath);
string fixedPath = Path.Combine(AppPath, "FixedWebView2");
Environment.SetEnvironmentVariable("WEBVIEW2_BROWSER_EXECUTABLE_FOLDER", fixedPath);
In a working environment we would be having multiple instances of webview2 runs at the same time. But in the ondemand fixedversion downloaded , webview2 instances doesn't navigated to the urls and it crashes the app after sometime and is black. I have compared the files downloaded from the server with the files in the Microsoft actual packages and all are same.
Any idea how to fix this fixed version issue?
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
135.0.3179.98
SDK Version
Microsoft.UI.Xaml -2.8.6
Framework
WinUI2/UWP
Operating System
Windows 11
OS Version
No response
Repro steps
Windows.Storage.ApplicationData.Current.LocalFolder.Path
string AppPath = Path.Combine(Windows.Storage.ApplicationData.Current.LocalFolder.Path, _companyName, _appName);
System.Environment.SetEnvironmentVariable("WEBVIEW2_USER_DATA_FOLDER", AppPath);
string fixedPath = Path.Combine(AppPath, "FixedWebView2");
Environment.SetEnvironmentVariable("WEBVIEW2_BROWSER_EXECUTABLE_FOLDER", fixedPath);
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
No, this never worked
Last working version (if regression)
No response
The text was updated successfully, but these errors were encountered: