-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Problem/Bug]: Error after updating WebView2 to build 1.0.2277.86 #4352
Comments
Tagging regression as it seems like a behavior that used to work |
asked @vickiez to check on this |
Thank you for reporting @rozeboosje! What happens when you call the API? Does it throw? |
I changed the code to this and it worked: |
@oggy22 I don't even get to call the API, the Visual Studio IDE complains and my build fails. @leonidukg Yes, I can confirm that when I change the call to
it builds again, and the resulting build seems to work fine. That would be acceptable if someone can confirm that this approach is correct. |
✅ Successfully linked to Azure Boards work item(s): |
Hello folks, thanks so much for looking into this issue. In the meantime, however, it looks like adding a null valued parameter to the call avoids the problem
or passing in null as per @leonidukg comment in C# Can you confirm that that's a valid workaround or should I refrain from using this build altogether? |
I didn't understand why null is not passed by default at all. And why they changed this behavior. Perhaps this point was just not tested in the new release. |
Well.... yeah, if it's ok to call GetAvailableBrowserVersionString with a null parameter I would think that they could create an overload with no parameters at all as, indeed, there used to be? That's why I'd like to know whether it's ok to change a previous call to GetAvailableBrowserVersionString with no parameters to one with a null parameter. If it's ok, well, it's a minor nuisance to change the call in our code, but no big deal. If not, I know I can't do any builds with this version, and I'd either have to revert back to the previous one or wait for a solution. |
It appears the issue is that there are now two public static string GetAvailableBrowserVersionString(string browserExecutableFolder = null)
public static string GetAvailableBrowserVersionString(string browserExecutableFolder = null, CoreWebView2EnvironmentOptions environmentOptions = null) Optional parameters work in practice by re-hydrating the optional parameters at the call site with their default values. Hence, both overloads are valid targets when you call I see two solutions: Change the second overload to require the new parameter: public static string GetAvailableBrowserVersionString(string browserExecutableFolder = null)
public static string GetAvailableBrowserVersionString(CoreWebView2EnvironmentOptions environmentOptions, string browserExecutableFolder = null) or combine the two overloads into a single method signature with two optional parameters: public static string GetAvailableBrowserVersionString(string browserExecutableFolder = null, CoreWebView2EnvironmentOptions environmentOptions = null) |
Hi @leonidukg @rozeboosje @danlyons-softek, thank you all for looking into and reporting about this issue. We will return it back to the previous behavior in the upcoming SDKs. |
What happened?
This call is no longer working:
sVersion = Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableBrowserVersionString()
Can you advise as to what I need to change this to?
I can get it to rebuild when I add browserExecutableFolder:=Nothing to the parameters but is that sufficient?
Importance
Blocking. My app's basic functions are not working due to this issue.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
No response
SDK Version
1.0.2277.86
Framework
WPF
Operating System
Windows 11
OS Version
No response
Repro steps
try to rebuild code with the above statement after upgrading to latest NuGet package
Repros in Edge Browser
Not Applicable
Regression
Don't know
Last working version (if regression)
No response
AB#48891185
The text was updated successfully, but these errors were encountered: