[Problem/Bug]: WebVIew Dependencies still not working correctly

[RickStrahl]

What happened?

This is related to issue #4749 but I'm posting a new issue since this is a bit different.

The problem is this:

As in the previous issue the concern is that transient dependencies are getting lost. What's different now is that I'm seeing the problem with multi-nested dependencies forcing to explicitly add references to the WebView control to child dependencies.

Here's the scenario I have:

• A component library that references WebView WPF control - latest SDK reference
• A top level application that references the above library (Works! - it sees WebView references)
• Several addins that have project references to the Top level application (Doesnt work - WebView2 can't resolve)

In order to get this to work I now have to:

• Explicitly add a WebView reference to every one of my Addin projects that uses it

Ok that wouldn't be so bad except:

1. I have quite a few addin projects
2. Each project ends up with the binaries and runtime native folders

#1 is a hassle as each project now has to be updated with each WebView release. Part of the reason for creating the Westwind.WebView library for me is that it consolidates a single reference to the WebView.

#2 is worse - if I add explicit reference it generates all the compilation artifacts that aren't needed because the main binary already has it. It seems like the various MS Build exclude and build directives meant to restrict output files do not work due to the funky MS Build settings used for the WebView SDK library.

Worst of all this used to work up until 1.0.2600 series. Somewhere in there the change was thrown in and the
1.0.2600 releases no longer work as the old versions did.

Addin Project Setup (project where references don't pass to)

For reference here's how my addin projects reference the top level application:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <Version>3.4</Version>
    <TargetFramework>net9.0-windows</TargetFramework>    
    <UseWPF>true</UseWPF>

    <!-- force into addin folder explicitly. don't copy assemblies referenced by parent project -->
    <OutDir>$(SolutionDir)MarkdownMonster/bin/$(Configuration)/$(TargetFramework)/Addins/OpenAi</OutDir>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

  <!-- Inside of an add - referencing parent application project which refs WebView class library
  This project has a reference to Westwind.WebView which in turn as reference to Micrsoft.WebView2.Wpf

       * Westwind.WebView   
       * MarkdownMonster    -  works here
       * OpenAIAddin        -  WebView not found    
  -->
  <ItemGroup>
    <ProjectReference Include="../../MarkdownMonster/MarkdownMonster.csproj">
      <Private>false</Private>
      <IncludeAssets>compile</IncludeAssets>      
    </ProjectReference>

  </ItemGroup>

Expected

Behavior like all other assemblies that pass through dependencies from any downstream library to the top level application and all addins. It works for all other dependencies,, but not for the WebView DLLS.

Markdown Monster v3.5.0.16
x64 • .NET 9.0.0-rc.2.24473.5
Microsoft Windows 10.0.22631
WebView Runtime:1.0.2849.39
WebView Sdk: 1.0.2849.39

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

1.0.2849.39

SDK Version

1.0.2849.39

Framework

WPF

Operating System

Windows 11

OS Version

10.0.22631

Repro steps

..

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Regression in newer SDK

Last working version (if regression)

1.0.2592.51

[oggy22]

Hi @RickStrahl! Can you please try with the latest prerelease SDK https://www.nuget.org/packages/Microsoft.Web.WebView2/1.0.2895-prerelease? It might have been fixed there. If not, we will take a closer look.

[oggy22]

My follow-up question is also does it repro when it's not addins? In other words that is when you have regular WPF standalone apps. Unfortunately for (office) addins we have very little test coverage around the SDK.

[RickStrahl]

Latest preview release has the same issue:

It works in first level dependencies.

These aren't Office addins. These are custom application addins that are plain .NET code. Addin only in the sense how they are used and to the effect that the compilation has some special dependency inheritance requirements.

The issue in a nutshell is that the transient dependency is not passed to the second level project reference. It works in the first level dependency, but not the second one.

Not sure I have an easy way to replicate that scenario another way. This is a compile time issue - basically the transitory assemblies are not being found at compile time and the project can't resolve the assembly.

Part of the issue here may be that this the Addin -> Top Level app reference is a project reference with assets withheld and set only to compile time:

    <ProjectReference Include="../../MarkdownMonster/MarkdownMonster.csproj">
      <Private>false</Private>
      <IncludeAssets>compile</IncludeAssets>
    </ProjectReference>

Using the above configuration fails.

It does work if I remove the extra asset settings to keep the runtime assets out of my output folder as that duplicates the entire binary dependency tree into the addin output folder. But this is not the desired behavior for obvious reasons, because these addins shouldn't pull all the runtime gunk of the parent project into the addin folder. That's what these directives are there for.

IOW, it looks like the WebView is using some MSBUILD settings that are incompatible with those private asset settings above.

Further all other packages and assemblies and controls and code that use them work just fine with this scenario, as did Microsoft.Web.WebView up until 1.0.24xxx. I have many other dependencies and controls that are passing through just fine so this behavior is not normal nor expected.

I suspect this has to do with the recent changes related to the fact that the native assemblies were not being deployed in transient scenarios, since that all happened around the same timeframe. I reported that issue initially and that started the original issue off to start with.

The current problem seems to be a sideeffect of whatever happened during that fix.

Workaround: Yeah, but it sucks!

There is a workaround, which is that I basically have to explicitly add a reference to the Microsoft.Web.WebView2 to each and every project that uses it.

So I add it to my top level project and each of my addin projects (3) and I have to keep each one up to date and in sync.

This is in opposition in the way this is supposed to work:

• I have a common WebVIew Project that has a WebView reference
• That is the only WebView Reference I need
• The transient refence is available in all referenced projects

FWIW - this is the way it had been working until 1.0.24xx, when the native runtime issues started showing up first, which was then fixed, followed by this multi-level transient issue.

[RickStrahl]

If you want a repro scenario I can give you or anybody working on this access to the project I'm referencing here. I think @champnic has access already to the Markdown Monster project.