NuGet validation fails with 1.6 references due to unexpected included webview2loader.dll

[michael-hawker]

          Got a report from building with 1.6-stable against our latest 1.6-preview2 bits with this error:

1>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5321,5): error MSB3030: Could not copy the file "C:\Users....nuget\packages\communitytoolkit.winui.animations\8.2.240909-build.1181\lib\net8.0-windows10.0.22621\CommunityToolkit.WinUI.Animations\runtimes\win-x64\native\WebView2Loader.dll" because it was not found.

looks like a path problem:

Wrong
C:\Users....nuget\packages\communitytoolkit.winui.animations\8.2.240909-build.1181\lib\net8.0-windows10.0.22621\CommunityToolkit.WinUI.Animations\runtimes\win-x64\native\

Correct
C:\Users....nuget\packages\communitytoolkit.winui.animations\8.2.240909-build.1181\lib\net8.0-windows10.0.22621.0\CommunityToolkit.WinUI.Animations\runtimes\win-x64\native
Note the missing .0 in the TFM part of the path, should be net8.0-windows10.0.22621.0 but was net8.0-windows10.0.22621.

Talking with @Arlodotexe it sounds similar (though different) to the issue Morten had reported in Labs here: CommunityToolkit/Labs-Windows#569

Though with all the WebView changes between preview1 and stable, we may just want to have them reproduce once we have a 1.6 build to try. Still an issue in 1.6 stable, seems like a regression in the platform.

Originally posted by @michael-hawker in #205 (comment) - Internal Platform Tracking Issue

[michael-hawker]

Platform has asked us to try something, then we can pass to WebView2 team.

From Scott: I'd suggest your team experiment with hacking up your WebView2 nuget cache locally to get things working, then pass your mods back to Ogi. Specifically, these elements in build\common.targets: <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-<arch>\native\WebView2Loader.dll" ...>

It sounds like you may have experimented with setting WebView2NeverCopyLoaderDllToOutputDirectory=true, per Sergio, but not clear whether that was effective? If it was, and you just want it to be on by default, I'd try applying the opt out not just to UseUwpTools, but to all C#/WinRT apps:

  <PropertyGroup>
    <WebView2NeverCopyLoaderDllToOutputDirectory Condition="'$(WebView2NeverCopyLoaderDllToOutputDirectory)' == '' And '$(WebView2EnableCsWinRTProjection)' == 'true'">true</WebView2NeverCopyLoaderDllToOutputDirectory>
  </PropertyGroup>

[michael-hawker]

Update we needed new package, WebView2 was published yesterday with the property:
NuGet Gallery | Microsoft.Web.WebView2 1.0.2792.45

Note: that you'll need to do your experiment in a targets file, not a props file. Most importantly, after the WebView2 targets file is processed, to ensure WebView2EnableCsWinRTProjection is set (since you have it in your condition). Look at a binlog to ensure you have it correct.

@Arlodotexe do we have an applicable targets hook we could use for this somewhere or would we have to create one?

There may also be instead a <WebView2LoaderPreference>None</WebView2LoaderPreference> but not sure if that's part of WebView package or if we need to wait for next update of WASDK. Also seems odd to have to explicitly include latest WebView2 to exclude part of it... @Sergio0694 could you clarify if we should just wait for an update to the WASDK before making another attempt?

[Sergio0694]

That's in the WebView2 package, but you should just be able to use WebView2NeverCopyLoaderDllToOutputDirectory now with the new versions that are published today. I'd suggest just using that actually, since it's meant specifically for this scenario.