WPF+UWP from 1.0.1661.34 to 1.0.1777-prerelease Exception

[xiakan]

Description WPF+UWP
Upgrading from1.0.1661.34 to 1.0.1777-prerelease ,throw an exception

Version SDK: 1.0.1661.34 Runtime: NET.Core 3.1 Framework: WPF OS: Win11

AB#44611801

[novac42]

Thanks for reaching out. I've assigned this to a dev that can help follow up on this.

[xiakan]

Look forward to your reply

[xiakan]

@novac42 Is anyone responding to this question?Look forward to your reply

[plantree]

Hi @xiakan,

Could you provide the code that is causing the problem?

[xiakan]

@plantree https://github.com/xiakan/WPFAndUWPDemo.git Please change the platform to x64 during runtime,Thanks

[plantree]

Hi @xiakan,

Thanks for your demo. I'll check ASAP.

[novac42]

This one seems to be a UWP related issue. Adding another dev to look into it.

[david-risney]

Apologies, how do you make the error occur? Can you show the code that is running when the exception occurs?

[xiakan]

There will be exceptions when running after re pulling the code. Thanks.

[xiakan]

May I ask if you see the wrong place?

[xiakan]

@david-risney May I ask if anyone is tracking this issue?

[xiakan]

@novac42 Do you still have developers to track this issue?

[plantree]

Apologies, how do you make the error occur? Can you show the code that is running when the exception occurs?

Hi @xiakan,

If you could provide some core code or a complete .sln project, that would be helpful.

[xiakan]

@plantree https://github.com/xiakan/WPFAndUWPDemo.git Please change the platform to x64 during runtime,Thanks

[plantree]

@plantree https://github.com/xiakan/WPFAndUWPDemo.git Please change the platform to x64 during runtime,Thanks

I'm so sorry for my forget.

Hi @david-risney, this is the demo project. I have tested it, and it might be a WinRT related.

[xiakan]

So what's the solution?

[david-risney]

Thanks, let me try this again.

[david-risney]

The reason for the exception with 1.0.1777 is that WinRT code in XAML is trying to load Microsoft.Web.WebView2.Core.dll but it is finding the .NET DLL rather than the WinRT DLL in the Debug folder.

In the WebView2 nuget package there is a Microsoft.Web.WebView2.Core.dll for .NET and Microsoft.Web.WebView2.Core.dlls for WinRT in different paths within the nuget package. XAML is using WinRT so needs to load the WinRT one, but the .NET one has been copied to the Debug folder and is what WinRT is trying to load, which does not work. In 1.0.1661.34 the correct DLL is in the Debug folder.

I have tried it with recent SDKs and I find it is only not working in 1777:

WebView2 SDK version	Working
1.0.1661.34	✅
1.0.1774.30	✅
1.0.1777-prerelease	❌
1.0.1829-prerelease	✅

Your solution has the application project using .NET and the class library dependency project using WinRT which is how I think it is confusing the WebView2 SDK package and copying the incorrect DLL, but this seems to only be an issue in 1777. Hopefully you can use 1829 with no issue.

[xiakan]

Other class libraries in our project use Microsoft. Web. WebView2. Wpf. WebView2. When updated to 1.0.1829 pre release, an exception will be thrown as follows:

May I ask how to solve the exception thrown above? This problem has been bothering me for a long time and I hope to receive a response. Thanks

[david-risney]

This sounds like the opposite issue. This could perhaps happen if you have a copy of the WinRT Microsoft.Web.WebView2.Core.DLL in your debug folder and .NET is trying to load the .NET Microsoft.Web.WebView2.Core.DLL. The issue is trying to mix both .NET and WinRT WebView2 usage in the same solution. Offhand I would think it should be possible, but I don't think we've validated this in particular.

@champnic do you know if we've made any changes around this area in recent nuget packages? I diffed the targets of different versions and didn't see anything obvious.

[champnic]

No changes in this space as far as I'm aware. Sounds like this might just be a scenario (.NET + UWP) that we haven't validated, and doesn't look fully supported yet. Could be chance or timing or something that's causing it to load one first, and then break when it's the wrong version for elsewhere. It might also be limited to the prerelease versions? @xiakan does the latest release SDK still work, or is that broken for you as well? And if you go back to 1.0.1661.34 does it start working again?

[xiakan]

@champnic Returning to 1.0.1661.34, it will start working again, but every upgrade will cause trouble. The version of Microsoft. UI. Xaml. Controls. WebView2 in the project cannot be higher than Microsoft Web. WebView2. Wpf. WebView2, currently Microsoft Web. WebView2. Wpf. The SDK for WebView2 is only available at 1.0.1724 pre release, so Microsoft. UI. Xaml. Controls. WebView2 cannot be updated to the latest version.

[xiakan]

@david-risney Please consult, in the NET Core 3.1+UWP scenario, attempting to load web page content will flash white, followed by loading content, which is obvious under black themes. https://github.com/xiakan/WPFAndUWPDemo.git

[champnic]

Thanks for checking. I've added this bug to our backlog.

For the white flash, you can set the default background color so that instead of white you can show black, or transparent, or some other dark color that matches the theming. On UWP you need to use the environment variable documented here: https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/icorewebview2controller2?view=webview2-1.0.1774.30#get_defaultbackgroundcolor

[xiakan]

Thank you for your prompt reply. If it's fixed, let me know, okay?

Additionally, I am using Microsoft. UI. Xaml. Controls. Webview2, and there is no defaultBackgroundColor attribute here. How to set the default background color for Microsoft. UI. Xaml. Controls. Webview2?

[champnic]

It's the environment variable section in the doc I linked: "This value may also be set by using the WEBVIEW2_DEFAULT_BACKGROUND_COLOR environment variable. There is a known issue with background color where setting the color by API can still leave the app with a white flicker before the DefaultBackgroundColor takes effect. Setting the color via environment variable solves this issue. The value must be a hex value that can optionally prepend a 0x. The value must account for the alpha value which is represented by the first 2 digits. So any hex value fewer than 8 digits will assume a prepended 00 to the hex value and result in a transparent color. get_DefaultBackgroundColor will return the result of this environment variable if used. This environment variable can only set the DefaultBackgroundColor once. Subsequent updates to background color must be done through API call."

In UWP you can use Environment.SetEnvironmentVariable("WEBVIEW2_DEFAULT_BACKGROUND_COLOR", "0xFFRRGGBB"); with your desired RGB values.

[plantree]

Hi @xiakan,

I have tried by Visual Studio 2019 locally, and it seems fine.

Before using 1.0.1777-prerelease, please clean the bin\ and .vs\ first. If there is still a problem, please take a screenshot about bin\Wonderbar\x64\Debug. Thanks.

[xiakan]

@plantree I have tried this project before, but I can't. https://github.com/xiakan/WPFAndUWPDemo.git

[xiakan]

If you have time, you can give it a try.Thanks.

[plantree]

These files should not exist since you don't use it.

Which Visual Studio are you using? 19 or 22? Try to use 19.