[NET] Remove unnecessary files from output folder

[Symbai]

Description
I've published a WPF .NET5 app within VS and enabled single file mode. For publishing I had to provide a target runtime (win-x64). In my project I've specified a platformtarget x64 for release mode.

After I've published the app the following files are created:

-- App.exe
-- App.pdb
-- WebView2Loader.dll
-- x86
---- WebView2Loader.dll
-- x64
---- WebView2Loader.dll
-- arm64
---- WebView2Loader.dll

Why is there an x86, arm64 folder and two WebView2Loader.dlls when my application is 64bit exclusively? They shouldn't get copied to publish folder.

Version
SDK: 0.9.628-prerelease
Runtime: Canary 87.0.644.0
Framework: WPF
OS: Win10

DotNet

Host (useful for support):
  Version: 5.0.0-rc.1.20451.14
  Commit:  38017c3935

.NET SDKs installed:
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.301 [C:\Program Files\dotnet\sdk]
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100-preview.8.20417.9 [C:\Program Files\dotnet\sdk]
  5.0.100-rc.1.20452.10 [C:\Program Files\dotnet\sdk]

Repro Steps

1. Create a project with webview2
2. Create a publish profile with settings as in the screenshot below
3. Publish to folder
   Screenshots
   
   

AB#29511846

[champnic]

Thanks for filing! We're tracking this on our end and will take a look.

[cgeier]

@Symbai The Microsoft.Web.WebView2.targets determines:

-- WebView2Loader.dll
-- x86
---- WebView2Loader.dll
-- x64
---- WebView2Loader.dll
-- arm64
---- WebView2Loader.dll

The WebView2Loader.dll file is required for WebView2 to work with .NET. I imagine that the multiple versions exist because of #314 and #252. Take a look at the following files:

• %UserProfile%.nuget\packages\microsoft.web.webview2\0.9.628-prerelease\build\Microsoft.Web.WebView2.targets

• %UserProfile%.nuget\packages\microsoft.web.webview2\0.9.628-prerelease\build\native\Microsoft.Web.WebView2.targets

• <solution folder>\packages\Microsoft.Web.WebView2.0.9.628-prerelease\build\Microsoft.Web.WebView2.targets

• <solution folder>\packages\Microsoft.Web.WebView2.0.9.628-prerelease\build\native\Microsoft.Web.WebView2.targets

You could modify the Microsoft.Web.WebView2.targets files if you only want one WebView2Loader.dll file. Or you could just delete the ones you don't need. Please see #431 for more information about these files. One (or more) of the posts shows how to modify these files.

[champnic]

Thanks @cgeier for the added context and the workarounds!

When a specific platform is targeted (as opposed to AnyCPU) our default targets file shouldn't be copying over the unnecessary bits. We'll work to get this fixed.

[Symbai]

Or you could just delete the ones you don't need

That's not a fix, just a workaround. The files are getting recreated on every time I publish the files. So I have to delete them over and over and over again.

Modifying the files is not a fix either. As soon as I update the nuget package its lost.

A fix is to detect if the user publishes in AnyCPU. If not, only include the files which are relevant.

[bddckr]

I've tried to work around this for now by doing a <Content Remove="... but I've run into multiple issues as MSBuild doesn't support wildcards in the Remove and it doesn't allow referencing item metadata in conditions. That is, I didn't want to hardcode the full path to the files to exclude/remove...

There's probably a better way to do this, but this is what I'm using for now:

<Project>
    <PropertyGroup>
        <!-- ... -->
    </PropertyGroup>
    <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk.WindowsDesktop" />
    <!-- ... -->
    <ItemGroup>
        <PackageReference Include="Microsoft.Web.WebView2" Version="1.0.674-prerelease" GeneratePathProperty="true" />
    </ItemGroup>
    <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk.WindowsDesktop" />

    <!-- Remove WebView2 native files we do not need. Only keep the x64 file. -->
    <ItemGroup>
      <Content Remove="$(PkgMicrosoft_Web_WebView2)\runtimes\win-x86\native\WebView2Loader.dll" />
      <Content Remove="$(PkgMicrosoft_Web_WebView2)\runtimes\win-arm\native\WebView2Loader.dll" />
    </ItemGroup>
</Project>

Note that I'm using the Import element here instead of the Sdk attribute on Project (see the docs on this). That way the Content gets removed, otherwise the removal is done too late as it gets overridden later again. Alternatively you could do this in a Directory.Build.targets etc.

[kirsan31]

For WinForms 1.0.674-prerelease I see this extra folders (strictly x86 build):

In root folder I have only:

Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.WinForms.dll
Microsoft.Web.WebView2.Wpf.dll

No WebView2Loader.dll.

My questions:

• Is Microsoft.Web.WebView2.Wpf.dll needed for WinForms?

• In *.deps.json WebView2Loader.dll is bind to runtimes/win-x86/native/WebView2Loader.dll. The problem is that our app must run normally with no WebView2 runtime installed and we can't ship additional folders inside root folder (unnecessarily). Our workaround for now is to include nuget package with ExcludeAssets="Native" (remove runtimeTargets from deps.json and runtimes folder from root). And with editing Microsoft.Web.WebView2.targets we can achieve proper dll in root folder and absent of root x86 x64 and arm64. But I think edit WebView2.targets is not a good approach. Any advice how to do it proper way?

[champnic]

@kirsan31

1. No, Wpf.dll is not needed for Winforms.
2. WebView2Loader.dll is a native binary compiled to a specific architecture (x86 or x64, etc.), so you'll need multiple versions unless you know and are only building for one arch. We're working on a change to remove duplicate and unused copies of WebView2Loader.dll (ie. only include x86 on x86 builds).

Could you explain what you mean by "app must run normally with no WebView2 runtime installed" and are your requirements around extra folders only if they are unnecessary?

[kirsan31]

Thank you @champnic

No, Wpf.dll is not needed for Winforms.

So, Microsoft.Web.WebView2.Wpf.dll must not be copied to output in WinForms.

Could you explain what you mean by "app must run normally with no WebView2 runtime installed"

Sorry for a bit confusing here. It was written while I was thinking that WebView2Loader.dll is shipped with Edge installation. When you have WebView2Loader.dll runtimeTargets entry in deps.json and have not this dll - the app will not run. So, my point was that app must start normally without WebView2Loader (no runtime installed), and you can't use WebView2. But than I figure out that WebView2Loader not shipped with runtime installation :( And in that case, my remark does not make sense.

We're working on a change to remove duplicate and unused copies of WebView2Loader.dll (ie. only include x86 on x86 builds).

Am I understand right, that when we explicitly target for example WinForms x86 , we will only have this in output (no folders):

Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.WinForms.dll
WebView2Loader.dll // x86

Or something else?

[champnic]

You're right, I've added a note to our bug to also limit WPF/Winforms.dll when the other is used. Current design is that WebView2Loader.dll would still be in a runtimes... folder. This matches Nuget guidance for architecture specific runtime files:
https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders

Is there a reason you can't have folders?

[kirsan31]

Is there a reason you can't have folders?

We have complex on the fly version management (user can switch between version on the fly in any direction with almost no limits). And this apply strict restrictions on app folder structure. Of corse we can add subfolders, but each of them must be processed separately. So it's more ease for us to simple put WebView2Loader.dll in the root folder. It's can be done with many ways, so no mind. I just wanted to know what to prepare for ...
Thank you.

[pagoe-msft]

Hi Everyone,

This was addressed in the 1.0.707-prerelease version.

[Symbai]

I've tried 1.0.707 and didn't closed the issue because it is NOT fixed. At least for me, if I publish my x64 WPF app. I still see x86 and arm64 folders with WebLoader.dll's in it 🤷‍♂️

[kirsan31]

@pagoe-msft
Need to be reopened. Nothing changed here (for the better).
1.0.707-prerelease, WinForms x86:

In *.deps.json Microsoft.Web.WebView2.Wpf.dll is must have too.

The only change from previous behavior is that runtimes folder now populating with additional win10 binaries 😕

Must be (if take into account what @champnic said above about runtimes folder):

WinForms

[runtimes]
Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.WinForms.dll

WPF

[runtimes]
Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.Wpf.dll

P.s. Nice technique to manual reference any dll from nuget package content are described here.

[kirsan31]

/cc @champnic @pagoe-msft

[champnic]

Verified the issue still repros, sorry about that!

[Eilon]

I have a similar problem but perhaps it's slightly different, you can find details here: #709

Due to some issue in WebView2's build targets the native DLLs either cause NuGet build warnings (#710) or you get extra DLLs package into your own NuGet package. I think it's slightly different from this bug here but the root cause could very well be the same.

[Symbai]

Just want to confirm that 1.0.721-prerelease does NOT fix the issue. On publish, arm64 and x86 folder is still created although the application targets x64 exclusively.

[kirsan31]

@Symbai

Just want to confirm that 1.0.721-prerelease does NOT fix the issue. On publish, arm64 and x86 folder is still created although the application targets x64 exclusively.

The funny thing is that you don't need the x64 directory either 😄 It's not using, WebView2Loader.dll is taking from runtimes folder.

[champnic]

This should now be fixed in 1.0.781-prerelease. Please give it a try and let us know if you run into any remaining issues. Thanks!

[billybooth]

We're still seeing both the Wpf.dll and Winforms.dll getting copied to output in the 1.0.790-prerelease. Our runtimes directory is good now, but we were expecting not to have the Wpf.dll copied to output for a .NET Framework WinForms project with the closure of this issue:

Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.WinForms.dll
Microsoft.Web.WebView2.Wpf.dll

[champnic]

@billybooth I've just opened that as a separate issue to make it easier to track and opened a new bug on our backlog. Thanks!