Improving how WebView2 runtime is detected

[lubos]

WebView2 runtime no longer creates required registry keys unless it's installed by administrator.

MicrosoftEdge/WebView2Feedback#2030

This commit changes how WebView2 runtime is detected so instead of registry keys we simply call new GetAvailableBrowserVersionString method.

[cwensley]

Hey @lubos thanks for the PR!

Well that is rather annoying that they changed how it is detected. Is this new method available on the old versions of WebView2? E.g. would it fail if they had an older version of the webview2 runtime installed, or just simply get them to install the new version?

As for the failure, it's due to MS breaking API's on their Xamarin.Mac/macos stuff for .NET 6 so no worries about that one. I'll have to resolve it to get nuget packages out though.

[lubos]

would it fail if they had an older version of the webview2 runtime installed, or just simply get them to install the new version?

I see. We could test if registry keys are present and if not, only then check what GetAvailableBrowserVersionString function returns. That would be safe approach but I think this should be a job of GetAvailableBrowserVersionString function to check registry keys to be backwards compatible if needed. We should just call GetAvailableBrowserVersionString and not worry about registry checking at all. Microsoft docs say we can either do registry check or this function. It doesn't say we should do both so I think we shouldn't.

I'm happy to use pre-release nuget of Eto.Forms and run this approach in production. From my limited testing, GetAvailableBrowserVersionString is enough.

[cwensley]

Looks like it'll just work as this is part of the helper library that you distribute with your app, not the installed runtime.

Thanks for the PR! A fresh CI pre-release nuget should be ready soon.