WebView2 ComWrappers support

[kant2002]

Please consider ComWrappers usage for WebView2 when communicate with COM in C#.
This improve ability to trim application using WebView2 in C#, and make them hassle free for regular developers. Also seems to be built-in COM support in runtime can be disabled in .NET 6, so this still allow WebView2 operate in such environments.

Example of implementation is dotnet/runtime#54636

AB#34465573

[champnic]

Hey @kant2002 - thanks for the feature request!

Can you expand a bit more on what your scenario is and what you are hoping this solves? In your .NET app are you doing a lot of COM calls for WebView2?

Do you have more info on the COM runtime being disabled? This is the first we've heard of it. We've tried using WebView2 in a .NET 6 preview app and it worked successfully.

[kant2002]

Hi @champnic !

Can you expand a bit more on what your scenario is and what you are hoping this solves?

Personally I valuate what's missing if I compile regular application using NativeAOT. For example Hybrid Blazor app which use WebView2, Since this is experimental technology I usually avoid mention it, but a lot of ILTrim work, or ComWrappers implementations in libraries helps tremendously my scenario basically for free at the same time helping run applications using R2R.

Do you have more info on the COM runtime being disabled

You can start looking into this from here dotnet/runtime#50662 or maybe this search helps find couple other related issues https://github.com/dotnet/runtime/search?q=built-in+disabled&type=issues . You better consult dotnet team on this subject.

Other example of ComWrappers works is support of IReferenceTracker in WinUI, which does not rely on built-in COM as far as I understand things, thanks to https://github.com/microsoft/CsWinRT/

[champnic]

Thanks for the links! It looks like the runtime COM changes are optional, but we'll double-check with the .NET folks.

I'll add this scenario on our backlog, but just to set expectations it's unlikely we'll be get to this work soon. Thanks!

[rgwood]

FYI, I think I'm running into an issue with trimming that is related to this. Apparently trimming disables .NET's built-in COM support.

I have a minimal .NET 6 application that uses WebView2 and I'd like to publish it as a self-contained single file executable (so users can run it without .NET installed):

<SelfContained>true</SelfContained>
<PublishSingleFile>true</PublishSingleFile> 

That works but it produces a 61MB exe for an app whose only dependency is Microsoft.Web.WebView2.Core 😬. Trimming (<PublishTrimmed>true</PublishTrimmed>) is super effective and it gets the exe down to 12MB, but then initialization breaks at runtime:

Application: MinimalWebView.exe
CoreCLR Version: 6.0.21.35212
.NET Version: 6.0.0-preview.6.21352.12
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeLoadException
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateCoreWebView2EnvironmentWithOptions(String browserExecutableFolder, String userDataFolder, ICoreWebView2EnvironmentOptions options, ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler environment_created_handler)
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateAsync(String browserExecutableFolder, String userDataFolder, CoreWebView2EnvironmentOptions options) in Microsoft.Web.WebView2.Core.dll:token 0x600007d+0x54
...

This is not a showstopper, but it is unfortunate. It would be really nice to distribute small modern .NET apps that use WebView2.

[darkguy2008]

I'm experiencing the same problem as @rgwood . Not to mention his suggestion to use SelfContained and PublishSingleFile just bundles the app together, but it doesn't anything NativeAOT related, you can still decompile the app with ILSpy, contrary to what would happen to a trimmed, native-code assembly generated with NativeAOT.

Is there any way we can get some progress on this area? @kant2002 has already done some real progress with his ComWrappers repo, so it'd be great to unblock him or something, or at least see if we can get some more NativeAOT love in WinForms apps.

Thanks :)

---

BTW @rgwood, I found a way to deploy a single file like this:

    <PublishSingleFile>true</PublishSingleFile>
    <SelfContained>false</SelfContained>
    <PublishTrimmed>false</PublishTrimmed>
    <BuiltInComInteropSupport>true</BuiltInComInteropSupport>
    <IncludeNativeLibrariesInSingleFile>true</IncludeNativeLibrariesInSingleFile>
    <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>

You can change SelfContained to true or false and depending on the flag, you'd get either a 1Mb+ file (that requires the framework to be installed) or a 140Mb+ file without the framework installer. Quite a difference, but at least it's a single file.

We really need AOT to work though :(

[charlesroddie]

I think this issue can be closed in favour of #4800 .