WindowBase 4.0/5.0 mismatch when using recent versions of WebView 2 Control

[KlausLoeffelmann]

Steps to repo:

• Create a new WinForms App, target anything between .NET 8 and .NET 10 Preview.
• Add the latest WebView2 package to you project:

  <ItemGroup>
    <PackageReference Include="Microsoft.Web.WebView2" Version="1.0.3179.45" />
  </ItemGroup>

• Recompile and observe the build output/error window.

This is probably merely an annoyance, but a big one, especially for those customers who warn as error. Googling this, it also seems to annoy quite some folks at this point, and also some of them were allegedly even blocked when they had problems to pack or create installers. (That, I could no repo though.)

So. The WindowBase 4.0 we're having here, what do we need it for exactly (especially in the WinForms case, when we're not using ElementHost)?

It's a type-forwarder, basically, is it not?

If that's the case, couldn't we just for .NET 8+ have that in the same version 5.0? Or do we need it in version 4.0 for scenarios, we're we'd add references to NETFX assemblies?

@dsplaisted, @ericstj and @JeremyKuhne FYI.

[dsplaisted]

It looks like WebView2 is compiled against version 5.0.0.0 of WindowsBase? Where does that come from?

[ericstj]

The versioned WindowsBase comes from WPF (5.0.0.0 for net5.0, 6.0.0.0 for net6.0 and so on). The 4.0.0 is just a facade that's in NETCore.App (with just a couple type forwards).

I think you need to specify UseWPF here to get the updated version.

We can't change the 4.0.0.0 version since WPF's copy needs to win over it. Why doesn't the package force the WPF references to be added to the project?

[paul1956]

@ericstj specifying UseWPF True does fix that issue but causes the wrong OpenFileDialog to be used and they are not API compatible. I can force the correct one by fully specifying the one I want but then I get the warning below and I have no control over SkiaSharp.

Found version-specific or distribution-specific runtime identifier(s): tizen-armel, tizen-x86. Affected libraries: SkiaSharp. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

[ericstj]

@paul1956 can you elaborate more about which is the "right" and "wrong" OpenFileDialog? Is this because setting UseWpf adds WPF references to the project and changes name resolution? (if I guessed right, just confirm, if wrong then please share a repro to demonstrate)

FWIW it looks to me like microsoft.web.webview2\1.0.3179.45\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll is a WPF control. I would imagine this sort of behavior is expected when trying to reference a WPF control from a Windows Forms project.

I had a closer look at what this package is doing and it seems it has build targets that include both the Winforms and WPF assemblies, regardless of the project type.

    <!-- Regular .NET 5+ apps should point to $(NugetRoot)\lib_manual\net5.0-windows10.0.17763.0\ for WPF.dll, and regular .NET Core 3.0 for Core.dll and Winforms.dll. -->
    <When Condition="'$(WebView2UseWinRT)'!='true' And '$(TargetFramework)'!='' And $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net5.0'))">
      <ItemGroup>
        <Reference Include="$(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll" />
        <Reference Include="$(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.WinForms.dll" />
        <Reference Include="$(NugetRoot)\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll" />
      </ItemGroup>
    </When>

    <!-- Regular .NET apps should point to $(NugetRoot)\lib_manual\netcoreapp3.0\ -->
    <When Condition="'$(WebView2UseWinRT)'!='true' And '$(TargetFramework)'!='' And $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'netcoreapp3.0'))">
      <ItemGroup>
        <Reference Include="$(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.Core.dll" />
        <Reference Include="$(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.Wpf.dll" />
        <Reference Include="$(NugetRoot)\lib_manual\netcoreapp3.0\Microsoft.Web.WebView2.WinForms.dll" />
      </ItemGroup>

So this seems to be a bug in that package. It should probably honor which frameworks the project actually references when adding these, or the user's UseWindowsForms|UseWpf properties.

I can workaround this problem as follows - just add this to the project that references Microsoft.Web.WebView2

  <Target Name="_removeUnusedWebView2" BeforeTargets="ResolveAssemblyReferences">
    <ItemGroup>
      <Reference Remove="@(Reference->WithMetadataValue('FileName', 'Microsoft.Web.WebView2.WinForms'))" Condition="'$(UseWindowsForms)' != 'true'" />
      <Reference Remove="@(Reference->WithMetadataValue('FileName', 'Microsoft.Web.WebView2.Wpf'))" Condition="'$(UseWpf)' != 'true'" />
    </ItemGroup>    
  </Target>

I'm not sure where to file issues on this package, but this should likely go to them.

[paul1956]

@ericstj yes. WinForms and WPF expose identically named Dialogs but they have different arguments (WinForm has more) but name resolution picks WPF which seems like a separate bug. I have other projects that specify using both and have never encountered this before but the other projects are not in active development.

[KlausLoeffelmann]

@ericstj:

Why doesn't the package force the WPF references to be added to the project?

I do not know. You mean the WebView2 package in this case, right?

[KlausLoeffelmann]

@ericstj yes. WinForms and WPF expose identically named Dialogs but they have different arguments (WinForm has more) but name resolution picks WPF which seems like a separate bug. I have other projects that specify using both and have never encountered this before but the other projects are not in active development.

Could you solve this just by defining the namespace for that class? Or are the namespaces also the same? I forgot the exact class names, but like

Imports FileOpenDialog = System.Paul.Klaus.Eric.FilesAndOtherFunstuff.FileOpenDialog;

[KlausLoeffelmann]

OMG, @paul1956, I am sorry!
I need to write more VB again - forgive me! 😄

[merriemcgaw]

@KlausLoeffelmann can you please file an issue with WebView2 team and give them these details? I'll help you find the contact.

[ericstj]

@ericstj yes. WinForms and WPF expose identically named Dialogs but they have different arguments (WinForm has more) but name resolution picks WPF which seems like a separate bug. I have other projects that specify using both and have never encountered this before but the other projects are not in active development.

Could you solve this just by defining the namespace for that class? Or are the namespaces also the same? I forgot the exact class names, but like

Imports FileOpenDialog = System.Paul.Klaus.Eric.FilesAndOtherFunstuff.FileOpenDialog;

Yeah, I think the name overlaps between WinForms and WPF are all in type name only and can be resolved by fully qualifying the types. I suspect this is pretty impactful to a codebase that just used one or the other - so forcing them to do this just to use the WebView2 control is probably not the right thing to do.

[paul1956]

@ericstj yes this only impacts a codebase that uses either WPF or WinForms if they use both they already hit this even without WebView2 and addressed it as recommended by @KlausLoeffelmann. This isn't VB specific. It's only applications that only use 1 framework plus WebWiew2 and has warnings set as errors and tries the UseWPF true workaround. Without warnings as errors it's just an annoying warning and the application works as expected.

[levicki]

@ericstj yes. WinForms and WPF expose identically named Dialogs but they have different arguments (WinForm has more) but name resolution picks WPF which seems like a separate bug. I have other projects that specify using both and have never encountered this before but the other projects are not in active development.

Could you solve this just by defining the namespace for that class? Or are the namespaces also the same? I forgot the exact class names, but like

Imports FileOpenDialog = System.Paul.Klaus.Eric.FilesAndOtherFunstuff.FileOpenDialog;

How would that solve anything? WPF reference shouldn't be added to begin with if UseWPF is false or not present in the .csproj.

[paul1956]

@levicki agreed it makes the binary significantly larger.

[ericstj]

I found a pretty active issue in the WebView2 repo and offered to help... Let's see if we can get that to happen.

[levicki]

@ericstj There's another issue with WebView2 and .Net — selecting Static still creates a copy of WebView2Loader.dll in runtimes in addition to one in root of bin folder. It's a bloody mess.