[Problem/Bug]: Error after updating WebView2 to build 1.0.2277.86

[rozeboosje]

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

[victorhuangwq]

Tagging regression as it seems like a behavior that used to work

[vbryh-msft]

asked @vickiez to check on this

[oggy22]

Thank you for reporting @rozeboosje! What happens when you call the API? Does it throw?

[leonidukg]

I changed the code to this and it worked:
sVersion = Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableBrowserVersionString(null)

[rozeboosje]

@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

sVersion = Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableBrowserVersionString(browserExecutableFolder:=Nothing) (in this Solution the code is written in Visual Basic)

it builds again, and the resulting build seems to work fine. That would be acceptable if someone can confirm that this approach is correct.

[champnic]

✅ Successfully linked to Azure Boards work item(s):

• Bug 48891185

[rozeboosje]

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

GetAvailableBrowserVersionString(browserExecutableFolder:=Nothing)

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?

[leonidukg]

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.

[rozeboosje]

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.

[danlyons-softek]

It appears the issue is that there are now two GetAvailableBrowserVersionString overloads, both taking in optional parameters:

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 GetAvailableBrowserVersionString().

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)

[victorhuangwq]

Hi @leonidukg @rozeboosje @danlyons-softek, thank you all for looking into and reporting about this issue.
As mentioned in the announcement, we introduced an unintended change, and it's as identified by @danlyons-softek.

We will return it back to the previous behavior in the upcoming SDKs.