System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431

cgeier · 2020-09-11T23:31:29Z

Description
I receive the following error: System.NullReferenceException: 'Object reference not set to an instance of an object.' when Debugging as "Any CPU" or "x86" on Windows 10 64-bit. It works if I debug as "x64".

I have all of the following MS Edge (development) versions installed:

MS Edge Beta: 86.0.622.11 (%ProgramFilesx86%\Microsoft\Edge Beta\Application\msedge.exe)
MS Edge Dev: 87.0.634.0 (%ProgramFilesx86%\Microsoft\Edge Dev\Application\msedge.exe)
MS Edge Canary: 87.0.637.0 (%UserProfile%\AppData\Local\Microsoft\Edge SxS\Application\msedge.exe)

I installed Beta first, then Dev, then Canary. When I run my WinForms program with a WebView2 control on it, and try to Debug it using with "Any CPU", I receive the following error: System.NullReferenceException: 'Object reference not set to an instance of an object.'

I receive a similar result if I use "x86"

Version
SDK: 0.9.628.0-prerelease
Runtime: Beta: 86.0.622.11; Dev: 87.0.634.0; Canary: 87.0.637.0
Framework: WinForms
OS: Win10 ReleaseId: 2004 CurrentBuild: 19041 (64-bit)

Stack Trace:
System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=Microsoft.Web.WebView2.WinForms
StackTrace:
at Microsoft.Web.WebView2.WinForms.WebView2.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.AssignParent(Control value)
at System.Windows.Forms.Control.ControlCollection.Add(Control value)
at System.Windows.Forms.Form.ControlCollection.Add(Control value)
at WebView2Test.Form1.InitializeComponent() in D:\Program Dev 2019\WebView2Test\WebView2Test\Form1.Designer.cs:line 50

Repro Steps:

Create a new WinForms project
Add WebView2 NuGet package to project
Add WebView2 control to Form1

Test 1: (Any CPU)

On menu, select Project.
Click Build. Platform target: Any CPU; Prefer 32-bit is checked
On menu, select Debug.
Select Start Debugging.

Test 2: (x86)

On menu, select Build.
Select Configuration Manager
Active Solution platform: <New...>
Type or select the new platform: x86; Copy settings from: Any CPU; Create new project platforms is checked
Click OK
Click Close

On menu, select Debug.
Select Start Debugging.

Here's the demo project: WebView2Test.zip. It's just a WebView2 control on Form1.

AB#29286853

champnic · 2020-09-12T03:11:07Z

If you downgrade the SDK to 579-prerelease do you still see the issue?

cgeier · 2020-09-12T03:29:46Z

I downgraded to 0.9.579-prerelease to test it. The issue doesn't exist in 579-prerelease, only when I install 0.9.628.0-prerelease.

cgeier · 2020-09-12T03:53:57Z

Looks like I found a workaround (similar to #263 and #228). I replaced the following files in Microsoft.Web.WebView2.0.9.628-prerelease with the ones from Microsoft.Web.WebView2.0.9.579-prerelease and it works.

Microsoft.Web.WebView2.0.9.628-prerelease\build\Microsoft.Web.WebView2.targets
Microsoft.Web.WebView2.0.9.628-prerelease\build\native\Microsoft.Web.WebView2.targets

Forgot to mention that I'm using VS 2019 (version: 16.7.3).

champnic · 2020-09-12T04:38:19Z

I've got a repro and I think I know what's wrong. I've opened a bug to track the fix on our end. For now, please use the 579-prerelease SDK, copy the targets like you've done, or use x64 for development. Thanks!

champnic · 2020-09-12T05:22:03Z

Looks like another workaround is to uncheck "Prefer 32 bit" under project Properties > Build > Prefer 32-bit.

cgeier · 2020-09-12T19:13:13Z

I came up with a fix. It's been tested on WinForms for AnyCPU (Prefer32Bit), AnyCPU, x64, and x86 for both C# and VB .NET. It's also been tested with C# WPF.

*Note: When running a WPF program as AnyCPU (Prefer32Bit) or x86, the test program didn't generate any errors. It just didn't work. Once the changes listed below were made, the program worked.

Update the code in both of the following files:

Microsoft.Web.WebView2.0.9.628-prerelease\build\Microsoft.Web.WebView2.targets
Microsoft.Web.WebView2.0.9.628-prerelease\build\native\Microsoft.Web.WebView2.targets

It looks like both files are the same. So do the following in both files:

We'll use "EffectivePlatform", so first remove the comment: EffectivePlatform is not used for .NET projects.

Original:

  <!-- The Platform property is Win32 or x64 for C++ projects. Convert to Win32 to x86 to match our directory structure.
    EffectivePlatform is not used for .NET projects.
    See conditions: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2019
    and PropertyGroup: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
  -->

Updated:

  <!-- The Platform property is Win32 or x64 for C++ projects. Convert to Win32 to x86 to match our directory structure.
    See conditions: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2019
    and PropertyGroup: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
  -->

Next, update the "EffectivePlatform" code:

Original:

  <PropertyGroup>
    <EffectivePlatform>$(Platform)</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Win32'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU'">x86</EffectivePlatform>
  </PropertyGroup>

Updated:

  <PropertyGroup>
    <EffectivePlatform>$(Platform)</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Win32' Or '$(Platform)' == 'x86'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU' And $(Prefer32Bit) == 'true'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'true'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU' And $(Prefer32Bit) == 'false'">x64</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'false'">x64</EffectivePlatform>
  </PropertyGroup>

There's one more section of code that needs to be updated (also change "sytle" to "style" in the comments). Since there's more code here, I'll highlight the changes. Both the original and updated code are below.

Remove architecture from "Link":

Remove "x86\" from: <Link>x86\%(Filename)%(Extension)</Link>
Remove "x64\" from <Link>x64\%(Filename)%(Extension)</Link>
Remove "arm64\" from : <Link>arm64\%(Filename)%(Extension)</Link>

Add Condition to "Content":

Add Condition="$(EffectivePlatform) == 'x86'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll">
Add Condition="$(EffectivePlatform) == 'x64'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll">
Add Condition="$(EffectivePlatform) == 'arm64'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm64\native\WebView2Loader.dll">

Here's the code:

Original:

  <!-- Copy each arch DLL to sub folders when project is in .NET framework.
    Microsoft.Web.WebView2.Core.dll handles picking up right DLL at runtime under those sub folders.
    For SDK sytle project, check for TargetFramework. For msbuild style, check to make sure project is not C++ and TargetFrameworkVersion equal to v after trim all number and dot.
    https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019#target-framework-and-profile
  -->
  <ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll">
      <Link>x86\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll">
      <Link>x64\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm\native\WebView2Loader.dll">
      <Link>arm64\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

Updated:

  <!-- Copy each arch DLL to sub folders when project is in .NET framework.
    Microsoft.Web.WebView2.Core.dll handles picking up right DLL at runtime under those sub folders.
    For SDK style project, check for TargetFramework. For msbuild style, check to make sure project is not C++ and TargetFrameworkVersion equal to v after trim all number and dot.
    https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019#target-framework-and-profile
  -->
  <ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
	<Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x86'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'arm64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

*Note: These changes weren't tested with "arm64".

Here's the complete Microsoft.Web.WebView2.targets file that works: Microsoft.Web.WebView2.zip

cgeier · 2020-09-12T19:37:07Z

For anyone interested in seeing the values of $(Platform) and $(EffectivePlatform), used during the build process, one needs to change the verbosity for the build process to "Diagnostic".

VS/2017 / VS 2019:
On menu, select Tools
Select Options
Expand Projects and Solutions
Select Build and Run
For MSBuild project build output verbosity, set to Diagnostic

In the output, search for "Platform" and/or "EffectivePlatform". When done, one can change verbosity back to "Minimal" (if desired).

cgeier · 2020-09-15T14:08:37Z

For anyone reading this, when installing the WebView2 NuGet package, it looks like the following process occurs:

If %UserProfile%\.nuget\packages\microsoft.web.webview2\<version> folder doesn't exist, the package files/folders are downloaded and saved to this location.

The necessary files/folders are copied from %UserProfile%\.nuget\packages\microsoft.web.webview2\<version> to <solution folder>\packages\Microsoft.Web.WebView2<version>, including Microsoft.Web.WebView2.targets.

Update the code in both of 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

If one has installed/updated, WebView2 0.9.628 package in one's project/solution before modifying the "targets" files, one needs to either uninstall and reinstall it, or for each project/solution, that has version 0.9.628, update the following files

<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

To see the Path being used:

On menu, select View
Select Solution Explorer
Expand <project name>
Expand References

Click on one of the following files and look at the Path property:

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

cgeier · 2020-09-20T19:16:10Z

@champnic For 32-bit (Any CPU Prefer 32 bit) and x86, WebView2 appears to be looking in the "x64" folder for the 32-bit version of "WebView2Loader.dll", instead of the "x86" folder.

Any CPU - Prefer 32 bit:

Executable Path: "bin\Debug\Test.exe"

Existing Files:

bin\Debug\x64\WebView2Loader.dll (64-bit)
bin\Debug\x86\WebView2Loader.dll (32-bit)
bin\Debug\WebView2Loader.dll (32-bit)

Results:

If "bin\Debug\x64\WebView2Loader.dll" 64-bit file is deleted, and "bin\Debug\WebView2Loader.dll" 32-bit exists, then 32-bit works. It appears that "bin\Debug\WebView2Loader.dll" 32-bit is being used, because "WebView2Loader.dll" file wasn't found in "bin\Debug\x64".
If "bin\Debug\x64\WebView2Loader.dll" is replaced with 32-bit version of WebView2Loader, then 32-bit works. Regardless of whether or not "bin\Debug\WebView2Loader.dll" exists.
If "bin\Debug\x64\WebView2Loader.dll" 64-bit file exists, and "bin\Debug\WebView2Loader.dll" 32-bit exists, then 32-bit doesn't work-it throws System.NullReferenceException.

x86:

Executable Path: "bin\x86\Debug\Test.exe"

Existing Files:

bin\x86\Debug\x64\WebView2Loader.dll (64-bit)
bin\x86\Debug\x86\WebView2Loader.dll (32-bit)
bin\x86\Debug\WebView2Loader.dll (32-bit)

Results:

If "bin\x86\Debug\x64\WebView2Loader.dll" 64-bit file is deleted, and "bin\x86\Debug\WebView2Loader.dll" 32-bit exists, then 32-bit works. It appears that "bin\x86\Debug\WebView2Loader.dll" 32-bit is being used, because "WebView2Loader.dll" file wasn't found in "bin\x86\Debug\x64".
If "bin\x86\Debug\x64\WebView2Loader.dll" is replaced with 32-bit version of WebView2Loader, then 32-bit works. Regardless of whether or not "bin\x86\Debug\WebView2Loader.dll" exists.
If "bin\x86\Debug\x64\WebView2Loader.dll" 64-bit file exists, and "bin\x86\Debug\WebView2Loader.dll" 32-bit exists, then 32-bit doesn't work-it throws System.NullReferenceException.

The details of the error seems to be showing "Microsoft.Web.WebView2.WinForms" as the source of the error. It seems to be checking the "x64" folder, finding the 64-bit version of "WebView2Loader.dll", and then throwing an exception because the 32-bit version is needed.

Microsoft.Web.WebView2.targets has the following code:

<ItemDefinitionGroup>
  <Link>
    <WebView2LoaderLib Condition="'$(WebView2LoaderPreference)' == 'Static'">WebView2LoaderStatic.lib</WebView2LoaderLib>
    <AdditionalDependencies>%(WebView2LoaderLib);WebView2Loader.dll.lib;WebView2Guid.lib;%(AdditionalDependencies)</AdditionalDependencies>
    <AdditionalLibraryDirectories>$(MSBuildThisFileDirectory)$(EffectivePlatform);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
  </Link>
</ItemDefinitionGroup>

If WebView2LoaderPreference is "Dynamic" then WebView2LoaderLib will be undefined which results in AdditionalDependencies having an extra semi-colon at the beginning.

AdditionalDependencies=;WebView2Loader.dll.lib;WebView2Guid.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;shlwapi.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;urlmon.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;

I think this can be rewritten as:

<ItemDefinitionGroup>
  <Link>
    <WebView2LoaderLib Condition="$(WebView2LoaderPreference) == 'Static'">WebView2LoaderStatic.lib</WebView2LoaderLib>
    <AdditionalDependencies Condition="$(WebView2LoaderPreference) == 'Static'">WebView2LoaderStatic.lib;WebView2Loader.dll.lib;WebView2Guid.lib;%(AdditionalDependencies)</AdditionalDependencies>
    <AdditionalDependencies Condition="$(WebView2LoaderPreference) == 'Dynamic'">WebView2Loader.dll.lib;WebView2Guid.lib;%(AdditionalDependencies)</AdditionalDependencies> 
    <AdditionalLibraryDirectories>$(MSBuildThisFileDirectory)$(EffectivePlatform);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
  </Link>
</ItemDefinitionGroup>

Is WebView2Loader.dll.lib necessary when WebView2LoaderPreference is "Static"?

Here's an updated version of Microsoft.Web.WebView2.targets that seems to work right now.

Microsoft.Web.WebView2.targets

<?xml version="1.0"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- The Platform property is Win32 or x64 for C++ projects. Convert to Win32 to x86 to match our directory structure.
    See conditions: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2019
    and PropertyGroup: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
  -->
  <PropertyGroup>
    <EffectivePlatform>$(Platform)</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Win32' Or '$(Platform)' == 'x86'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'true'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'false'">x64</EffectivePlatform>
  </PropertyGroup>

  <!-- Define custom property to provide user ability to switch between loader static lib or dll.
    Dynamic value to dll, Static value to static lib
    See MSBuild properties: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-properties?view=vs-2019
  -->
  <PropertyGroup>
    <WebView2LoaderPreference>Dynamic</WebView2LoaderPreference>
  </PropertyGroup>

  <!-- Make our header path available in the include path.
    See CL task: https://docs.microsoft.com/en-us/visualstudio/msbuild/cl-task?view=vs-2019
  -->
  <ItemDefinitionGroup>
    <ClCompile>
  <!-- MSBuildThisFileDirectory is the path containing this targets file.
    See well-known properties: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-reserved-and-well-known-properties?view=vs-2019
  -->
      <AdditionalIncludeDirectories>$(MSBuildThisFileDirectory)include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    </ClCompile>
  </ItemDefinitionGroup>

  <!-- Update link path to include appropriate arch directory and link against our lib.
    See Link task: https://docs.microsoft.com/en-us/visualstudio/msbuild/link-task?view=vs-2019
  -->
  <ItemDefinitionGroup>
    <Link>
      <WebView2LoaderLib Condition="$(WebView2LoaderPreference) == 'Static'">WebView2LoaderStatic.lib</WebView2LoaderLib>
      <AdditionalDependencies Condition="$(WebView2LoaderPreference) == 'Static'">WebView2LoaderStatic.lib;WebView2Loader.dll.lib;WebView2Guid.lib;%(AdditionalDependencies)</AdditionalDependencies>
      <AdditionalDependencies Condition="$(WebView2LoaderPreference) == 'Dynamic'">WebView2Loader.dll.lib;WebView2Guid.lib;%(AdditionalDependencies)</AdditionalDependencies> 
      <AdditionalLibraryDirectories>$(MSBuildThisFileDirectory)$(EffectivePlatform);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
    </Link>
  </ItemDefinitionGroup>

  <!-- Copy DLL to the output path.
    Only Copy DLL to the output path when project is C++ and WebView2LoaderPreference is set to Dynamic.
    .NET will pick DLL at runtime from runtime folder or processor bit folder base on Core or Framework.
    See Content: https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2019
    See Architecture-specific folders for .NET: 
    https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders
  -->
  <ItemGroup Condition="'$(WebView2LoaderPreference)' == 'Dynamic' And '$(Keyword)' == 'Win32Proj'">
    <Content Include="$(MSBuildThisFileDirectory)$(EffectivePlatform)\WebView2Loader.dll">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <!-- Copy each arch DLL to sub folders when project is in .NET framework.
    Microsoft.Web.WebView2.Core.dll handles picking up right DLL at runtime under those sub folders.
    For SDK style project, check for TargetFramework. For msbuild style, check to make sure project is not C++ and TargetFrameworkVersion equal to v after trim all number and dot.
    https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019#target-framework-and-profile
  -->
  <ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x86'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'arm64' Or $(EffectivePlatform) == 'ARM64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <!-- Cleanup our copied files when cleaning.
    See Delete: https://docs.microsoft.com/en-us/visualstudio/msbuild/delete-task?view=vs-2019
    See AfterTargets: https://docs.microsoft.com/en-us/visualstudio/msbuild/target-build-order?view=vs-2019
  -->
  <Target Name="CleanDownloadContentFiles" AfterTargets="Clean">
    <Delete Files="$(OutputPath)\WebView2Loader.dll"/>
  </Target>
</Project>

champnic · 2020-09-21T04:12:45Z

Thanks for the investigation @cgeier. This matches what we found. The root cause was we were checking for the OS bitness to choose which webviewloader to load at runtime. We've already fixes this to check for process bitness instead so that the load succeeds. I'll forward your proposed fix to our engineer though as well to look at. Thanks!

cgeier · 2020-09-21T09:08:45Z

@champnic I noticed that in the NuGet package the following folders for ARM:

0.9.628-prerelease\build\arm64
0.9.628-prerelease\build\native\arm64

Minor detail, but I think that ARM is usually written in upper-case. So perhaps:

0.9.628-prerelease\build\ARM64
0.9.628-prerelease\build\native\ARM64

I don't have a computer that utilizes the ARM architecture, however in Visual Studio C++, both ARM and ARM64 exist as target architectures. In the NuGet package there is only ARM64.

Are there plans to also add:

0.9.628-prerelease\build\ARM
0.9.628-prerelease\build\native\ARM

While I don't have a need for it, maybe someone else does.

Also found this documentation: Windows 10 on ARM which shows the following:

I've updated the file in my previous post. However, if the folder case-sensitivity is changed for the folder names, it may also have to be changed in the Microsoft.Web.WebView2.targets file so that it works in Linux.

champnic · 2020-09-21T16:52:23Z

We don't currently support ARM32 (because the browser doesn't). We don't currently have plans for ARM32, given Windows 10 on ARM is ARM64 and will run x86 and ARM64 apps.

cgeier · 2020-09-22T21:26:46Z

@champnic In the WebView2 0.9.628-prerelease package, I noticed the following folder structure:

0.9.628-prerelease\build\arm64
0.9.628-prerelease\build\native\arm64

However, in the "runtimes" folder, there's the following:

0.9.628-prerelease\runtimes\win-arm

Since a 32-bit version of ARM exists, it seems that "win-arm" should be renamed to "win-arm64" for consistency, and also to avoid confusion.

According to a post in #461, it was mentioned that the intention is to support multiple architectures when "Any CPU" is specified which will create additional folders. However, if "x86" or "x64" is specified, then the additional folders won't be created--only the specified architecture "WebView2Loader.dll" will be copied to the OutputPath.

Here's an updated version of Microsoft.Web.WebView2.targets that may work for the next release:

Microsoft.Web.WebView2.targets-FutureRevision.zip

This one is updated and is different from the one previously posted. To avoid confusion, the other one has been removed.

*Note: The name of the ARM64 folder may need to be changed to match the expected value. See the "ReadMe" file for more information. Additionally, the Microsoft.Web.WebView2.targets file has quite a few comments in it. Verify whether or not WebView2Loader.dll.lib should be in AdditionalDependencies when WebView2LoaderPreference is "Static".

limyandi · 2020-09-30T02:51:24Z

I came up with a fix. It's been tested on WinForms for AnyCPU (Prefer32Bit), AnyCPU, x64, and x86 for both C# and VB .NET. It's also been tested with C# WPF.

*Note: When running a WPF program as AnyCPU (Prefer32Bit) or x86, the test program didn't generate any errors. It just didn't work. Once the changes listed below were made, the program worked.

Update the code in both of the following files:

Microsoft.Web.WebView2.0.9.628-prerelease\build\Microsoft.Web.WebView2.targets
Microsoft.Web.WebView2.0.9.628-prerelease\build\native\Microsoft.Web.WebView2.targets

It looks like both files are the same. So do the following in both files:

We'll use "EffectivePlatform", so first remove the comment: EffectivePlatform is not used for .NET projects.

Original:

  <!-- The Platform property is Win32 or x64 for C++ projects. Convert to Win32 to x86 to match our directory structure.
    EffectivePlatform is not used for .NET projects.
    See conditions: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2019
    and PropertyGroup: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
  -->

Updated:

  <!-- The Platform property is Win32 or x64 for C++ projects. Convert to Win32 to x86 to match our directory structure.
    See conditions: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2019
    and PropertyGroup: https://docs.microsoft.com/en-us/visualstudio/msbuild/propertygroup-element-msbuild?view=vs-2019
  -->

Next, update the "EffectivePlatform" code:

Original:

  <PropertyGroup>
    <EffectivePlatform>$(Platform)</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Win32'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU'">x86</EffectivePlatform>
  </PropertyGroup>

Updated:

  <PropertyGroup>
    <EffectivePlatform>$(Platform)</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Win32' Or '$(Platform)' == 'x86'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU' And $(Prefer32Bit) == 'true'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'true'">x86</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'Any CPU' And $(Prefer32Bit) == 'false'">x64</EffectivePlatform>
    <EffectivePlatform Condition="'$(Platform)' == 'AnyCPU' And $(Prefer32Bit) == 'false'">x64</EffectivePlatform>
  </PropertyGroup>

There's one more section of code that needs to be updated (also change "sytle" to "style" in the comments). Since there's more code here, I'll highlight the changes. Both the original and updated code are below.

Remove architecture from "Link":

Remove "x86" from: <Link>x86\%(Filename)%(Extension)</Link>
Remove "x64" from <Link>x64\%(Filename)%(Extension)</Link>
Remove "arm64" from : <Link>arm64\%(Filename)%(Extension)</Link>

Add Condition to "Content":

Add Condition="$(EffectivePlatform) == 'x86'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll">
Add Condition="$(EffectivePlatform) == 'x64'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll">
Add Condition="$(EffectivePlatform) == 'arm64'" to <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm64\native\WebView2Loader.dll">

Here's the code:

Original:

  <!-- Copy each arch DLL to sub folders when project is in .NET framework.
    Microsoft.Web.WebView2.Core.dll handles picking up right DLL at runtime under those sub folders.
    For SDK sytle project, check for TargetFramework. For msbuild style, check to make sure project is not C++ and TargetFrameworkVersion equal to v after trim all number and dot.
    https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019#target-framework-and-profile
  -->
  <ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll">
      <Link>x86\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll">
      <Link>x64\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm\native\WebView2Loader.dll">
      <Link>arm64\%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

Updated:

  <!-- Copy each arch DLL to sub folders when project is in .NET framework.
    Microsoft.Web.WebView2.Core.dll handles picking up right DLL at runtime under those sub folders.
    For SDK style project, check for TargetFramework. For msbuild style, check to make sure project is not C++ and TargetFrameworkVersion equal to v after trim all number and dot.
    https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019#target-framework-and-profile
  -->
  <ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
	<Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x86'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'x64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm\native\WebView2Loader.dll" Condition="$(EffectivePlatform) == 'arm64'">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

*Note: These changes weren't tested with "arm64".

Here's the complete Microsoft.Web.WebView2.targets file that works: Microsoft.Web.WebView2.zip

Hi @cgeier thanks for the solution, I have tested this and it works. Can you please explain what's happening in the solution above or point to any documentation about targets file properties, thank you.

cgeier · 2020-09-30T14:12:17Z

@limyandi The posts above contain quite a bit of information. There is additional information in the "Microsoft.Web.WebView2.targets-FutureRevision.zip" file both in the "ReadMe" file as well as the ".targets" file. If you're interested in learning more about how the .targets file(s) works, search for "msbuild targets file".

pipalot · 2020-10-13T13:12:11Z

ClickOnce is still missing WebView2Loader.dll and the x86, x64 and arm64 directories, none of which are copied to the App.Publish sub-directories when I publish. I've tried using 0.9.628-prerelease and even 0.9.579-prerelease with and without the amendments to the target files mentioned above, none of which works with ClickOnce for me.
Is this just affecting me?

According to 228, this was supposedly fixed in 0.9.628-prerelease.

Please excuse me for posting it in this discussion, but as this is a discussion about problems with the Targets files, I thought it made sense in case this is all part of the same problem.

champnic · 2020-10-13T17:03:48Z

@pipalot That's a separate issue, and we're following up in #228. This issue is a problem with choosing the right WebView2Loader.dll, and the publishing is an error in the format of the targets file properties. Thanks!

champnic · 2020-10-19T23:30:39Z

This should now be fixed in WebView2 SDK 1.0.674-prerelease. If this is still an issue please let us know. Thanks!

Alex240 · 2021-03-02T10:52:45Z

This should now be fixed in WebView2 SDK 1.0.674-prerelease. If this is still an issue please let us know. Thanks!

It seems that the problem persists with 1.075.50 version.

champnic · 2021-03-03T21:19:30Z

Hey @Alex240 - could you add some details about your specific repro steps and setup?

Alex240 · 2021-03-04T10:22:59Z

Hi @champnic

the context
Webview2 v1.705.50
VS2019 Framework 4.62
VB Winforms
target CPU platform x86

the problem occurs on Windows 7 64b

with error message when try to load Webview2 :

************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
à Collec.frm_Navigateur.Naviguer()
à Collec.frm_Navigateur.Form1_Load(Object sender, EventArgs e)
à System.Windows.Forms.Form.OnLoad(EventArgs e)
à System.Windows.Forms.Form.OnCreateControl()
à System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
à System.Windows.Forms.Control.CreateControl()
à System.Windows.Forms.Control.WmShowWindow(Message& m)
à System.Windows.Forms.Control.WndProc(Message& m)
à System.Windows.Forms.ScrollableControl.WndProc(Message& m)
à System.Windows.Forms.Form.WmShowWindow(Message& m)
à System.Windows.Forms.Form.WndProc(Message& m)
à System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
à System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
à System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Assemblys chargés
mscorlib
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll

Aaaaaaaaa
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/x.exe

Microsoft.VisualBasic
Version de l'assembly : 10.0.0.0
Version Win32 : 14.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll

System
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

System.Core
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

System.Windows.Forms
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System.Drawing
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

System.Runtime.Remoting
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll

System.Data
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll

System.Xml
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

System.Data.DataSetExtensions
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Data.DataSetExtensions/v4.0_4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll

System.Numerics
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll

Accessibility
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

System.Configuration
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Windows.Forms.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/System.Windows.Forms.resources.dll

System.Transactions
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll

System.EnterpriseServices
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll

mscorlib.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/mscorlib.resources.dll

Microsoft.Web.WebView2.Core
Version de l'assembly : 1.0.705.50
Version Win32 : 1.0.705.50
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.Core.DLL

Microsoft.Web.WebView2.WinForms
Version de l'assembly : 1.0.705.50
Version Win32 : 1.0.705.50
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.WinForms.DLL

System.Management
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll

bgavrilMS · 2021-03-04T15:26:04Z

I have a customer of my library that just experienced this as well. Please reopen.

champnic · 2021-03-06T00:20:53Z

@Alex240 Are you giving the control a writeable user data folder path? I noticed your app is deployed to C:\Program Files (x86)..., and the WebView2 might be failing because it can't write to that location. #297, #295, and #271 might have helpful info if this is the cause.

@bgavrilMS It might be helpful if you could also add details and context for your scenario here.

Alex240 · 2021-03-06T07:15:53Z

Hi @champnic, yes the app use a writeable user data folder and works fine on most of computers tested.

cgeier · 2021-03-08T03:00:52Z

@Alex240, @bgavrilMS:

Ensure that you are using the same bitness (x86 or x64) for both your application and WebView2. If your application is compiled for x86, download/install the x86 version of WebView2 Evergreen Standalone Installer (or use the x86 Fixed Version Runtime).

Workaround:
As a workaround, until issue #1044 is resolved, only install the version (bitness) of WebView2 Runtime that your program is using--do not install both x86 and x64 versions of WebView2 Runtime.

I created and tested a demo VB.NET program using the following:

SDK: v1.0.705.50 (Microsoft.Web.WebView2)
Runtime: 89.0.774.45 (Evergreen Standalone Installer)
VB.NET WinForms
TargetFrameworkVersion: v4.6.2
Platform: Any CPU (Prefer 32-bit)
OS: Win10 and Win7
NuGet Package Management: PackageReference

My demo program seemed to work, except when I didn't have MS Edge WebView2 Runtime x86 installed or when I installed MS Edge WebView2 Runtime x86 and then installed MS Edge WebView2 Runtime x64. See issue #1044 for more information.

Alex240 · 2021-03-08T08:23:57Z

@Alex240, @bgavrilMS:

Ensure that you are using the same bitness (x86 or x64) for both your application and WebView2. If your application is compiled for x86, download/install the x86 version of WebView2 Evergreen Standalone Installer (or use the x86 Fixed Version Runtime). Do not install both x86 and x64 versions of WebView2--see issue described below.

I created and tested a demo VB.NET program using the following:

SDK: v1.0.705.50 (Microsoft.Web.WebView2)
Runtime: 89.0.774.45 (Evergreen Standalone Installer)
VB.NET WinForms
TargetFrameworkVersion: v4.6.2
Platform: Any CPU (Prefer 32-bit)
OS: Win10 and Win7
NuGet Package Management: PackageReference

My demo program seemed to work, except when I didn't have MS Edge WebView2 Runtime x86 installed or when I installed MS Edge WebView2 Runtime x86 and then installed MS Edge WebView2 Runtime x64. See issue #1044 for more information.

Thank you for the information, but the runtime is downloaded to each client workstation from the MicrosoftEdgeWebview2Setup.exe bootstrapper ("Download - evergreen bootstrapper" button on https://developer.microsoft.com/en-us/microsoft-edge/webview2/).

How to choose the bitness (x86) with this bootstrapper?

mjcheetham · 2021-03-08T10:52:07Z

Do not install both x86 and x64 versions of WebView2

I trust this is only a temporary recommendation until issues are resolved?

Asking users or developers not the install both x86 and x64 versions of the evergreen WebView2 runtime is not viable.
If two apps wish to use the evergreen WebView2 runtime but are different bitness then they cannot be installed on the user's machine at the same time!

cgeier · 2021-03-08T13:45:47Z

@mjcheetham: I've updated the post.

cgeier · 2021-03-08T15:41:48Z

@Alex240: According to the documentation:

Distribution of apps using WebView2

Deploying the Evergreen WebView2 Runtime
...
WebView2 Runtime Bootstrapper is a tiny (approximately 2 MB) installer. WebView2 Runtime Bootstrapper downloads and installs the Evergreen Runtime from Microsoft servers that matches the user's device architecture.

Evergreen Bootstrapper Download

When using the Evergreen Bootstrapper, if your operating system (OS) is 64-bit, then WebView2 Runtime x64 will be downloaded and installed. If your operating system is 32-bit, then WebView2 Runtime x86 will be downloaded and installed. It appears that issue #1044 also affects the Evergreen BootStrapper. On a computer running Windows x64, the WebView2 Runtime x64 is installed to %ProgramFiles(x86)%\Microsoft\EdgeWebView\Application.

If your program is compiled for x86 and runs on a computer with a 64-bit operating system (OS), then use the Evergreen Standalone installer--it allows you to choose x64 or x86. Otherwise, if you intend to use the Evergreen Bootstrapper, compile your program as x64 if it's going to be installed on a computer with a 64-bit operating system (OS).

champnic · 2021-03-10T00:58:43Z

Hey all (@mjcheetham @Alex240) -
x86, x64 and AnyCPU compiled apps should be able to use any installed runtime - specific choice (or not) of runtime arch shouldn't affect the decision of which arch to build your app in. On an x86 OS only the x64 runtime will work - this will be automatically chosen and installed by the bootstrapper. You shouldn't need to manually install specific architectures of the runtime. Only one version of the runtime can be installed at a time anyways, so installing x86 runtime and then x64 runtime, the x64 runtime will overwrite the x86 runtime.

We're following up with @cgeier in #1044 to get more info about that failure, but I just tried this and ran an x86 app with x64 runtime with no problems, so I don't think it's a generalized issue.

@Alex240 If it's only failing on some computers, that sounds like it's a difference in the computer setups that's causing the problem. Is there any difference between the computers that are working and those that aren't? Bitness, deployments, other apps/configurations?

cgeier · 2021-03-10T03:38:03Z

@champnic: Thanks for the clarification. I just re-installed the WebView2 runtime and tried it again, and it seems to work as you stated above.

It would be nice if a WebView2 troubleshooter was created to help diagnose issues with WebView2. I spent quite a bit of time troubleshooting the issue on Windows 7 x64 (Home Premium)--not sure why though, since Windows 7 is no longer supported.

The issue seemed to occur when a program compiled as Any CPU (prefer 32-bit) running with the WebView2 runtime x64 version would cause my program to display a white screen. However, my program would work if I installed the WebView2 x86 version using the standalone installer. My program would also work if I compiled my program as x64 and installed WebView2 x64 version using the standalone installer. I didn't use the WebView2 bootstrapper until the end of my testing, so my testing with the WebView2 bootstrapper version was rather limited. Once I felt like I had identified the issue, I also tested it on Windows 10, and seemed to get similar results.

The issue I encountered seems to no longer be reproducible. I did notice that the WebView2 runtime is now v89.0.774.48-- the version I mentioned above, at the time of testing, was v89.0.774.45.

champnic · 2021-03-11T02:20:53Z

Glad it seems to be fixed (although I wish I knew why!). We do have plans to improve logging and error messages to better be able to diagnose failures in startup and runtime launch.

bharatvarsha · 2023-04-12T11:57:02Z

@pipalot

Were you able to find any solution to this ? I have the same issue. I can see Microsoft.Web.WebView2.Core.dll.deploy and Microsoft.Web.WebView2.Wpf.dll.deploy in publish folder but nothing for webview2loader.dll

I get this error on jenkins build (using MSBuild)

Considered "C:\Program Files (x86)\Jenkins\sharedspace\Test\packages\Microsoft.Web.WebView2.1.0.1661.34\build\..\runtimes\win-x86\native\WebView2Loader.dll", but its name "WebView2Loader" didn't match.
Considered "C:\Program Files (x86)\Jenkins\sharedspace\Test\packages\Microsoft.Web.WebView2.1.0.1661.34\build\..\runtimes\win-x64\native\WebView2Loader.dll", but its name "WebView2Loader" didn't match.
Considered "C:\Program Files (x86)\Jenkins\sharedspace\Test\packages\Microsoft.Web.WebView2.1.0.1661.34\build\..\runtimes\win-arm64\native\WebView2Loader.dll", but its name "WebView2Loader" didn't match.

Error is
Unable to load DLL 'WebView2Loader.dll': The specified module could not be found.

Webview2 runtime is installed on client using standalone installer. That is not an issue. It works if I use it via Visual Studio.

cgeier changed the title ~~System.NullReferenceException: 'Object reference not set to an instance of an object.'~~ System.NullReferenceException: Debugging as Any CPU or x86 on 64-bit OS Sep 11, 2020

cgeier changed the title ~~System.NullReferenceException: Debugging as Any CPU or x86 on 64-bit OS~~ System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS Sep 11, 2020

champnic added bug Something isn't working tracked We are tracking this work internally. labels Sep 12, 2020

champnic mentioned this issue Sep 12, 2020

Is WebView2 supported in Excel VSTO Add-in? #187

Closed

champnic pinned this issue Sep 12, 2020

This was referenced Sep 14, 2020

WinForms Invisible / Not showing #437

Closed

WinForms - App Crash on .NET5 ARM64 when source is set - NullReferenceException #438

Closed

champnic mentioned this issue Sep 15, 2020

Microsoft.Web.WebView2.Wpf.dll does not represent a strongly named assembly #181

Closed

This was referenced Sep 17, 2020

Webview2 is not working - windows app #450

Closed

Webview2 not rendering or navigating at all #449

Closed

RenderProcessExited #443

Closed

cgeier mentioned this issue Sep 20, 2020

Login to websites does not work #455

Open

This was referenced Sep 21, 2020

[NET] Remove unnecessary files from output folder #461

Closed

Webview 2 .Net (Windows Form) NullReferenceException #464

Closed

This was referenced Sep 24, 2020

Missing binaries in WebView2 latest nuget packages #478

Closed

WebView2 WinForms does not work when userDataFolder is used #475

Closed

champnic mentioned this issue Sep 29, 2020

[DMC]: wpf don't work in latest prerelease 0.9.628 #920 #492

Closed

cgeier mentioned this issue Sep 30, 2020

CoreWebView2 not initialized - WPF .Net Framework 4.7.2 #495

Closed

cgeier mentioned this issue Oct 2, 2020

Fails with WPF .NET Framework MicrosoftDocs/edge-developer#927

Closed

pipalot mentioned this issue Oct 13, 2020

WebView2Loader.dll is still missing from App.Publish (Winforms, ClickOnce). #528

Open

champnic mentioned this issue Oct 13, 2020

Event 1026, .NET Runtime Error when running a published application #531

Closed

limyandi mentioned this issue Oct 19, 2020

Problems after Windows 2004 October patches and Build 19041.572 install #543

Closed

champnic closed this as completed Oct 19, 2020

champnic added this to the SDK 1.0.674-prerelease milestone Oct 19, 2020

champnic unpinned this issue Nov 9, 2020

cppchuff mentioned this issue Dec 14, 2020

.NET - 1.0.707-prerelease WebView2 doesn't load any page when using WebView2 Runtime #678

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431

System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431

cgeier commented Sep 11, 2020 •

edited by champnic

Loading

champnic commented Sep 12, 2020

cgeier commented Sep 12, 2020

cgeier commented Sep 12, 2020 •

edited

Loading

champnic commented Sep 12, 2020

champnic commented Sep 12, 2020

cgeier commented Sep 12, 2020 •

edited

Loading

cgeier commented Sep 12, 2020

cgeier commented Sep 15, 2020 •

edited

Loading

cgeier commented Sep 20, 2020 •

edited

Loading

champnic commented Sep 21, 2020

cgeier commented Sep 21, 2020 •

edited

Loading

champnic commented Sep 21, 2020

cgeier commented Sep 22, 2020 •

edited

Loading

limyandi commented Sep 30, 2020 •

edited

Loading

cgeier commented Sep 30, 2020 •

edited

Loading

pipalot commented Oct 13, 2020 •

edited

Loading

champnic commented Oct 13, 2020

champnic commented Oct 19, 2020

Alex240 commented Mar 2, 2021

champnic commented Mar 3, 2021

Alex240 commented Mar 4, 2021 •

edited

Loading

bgavrilMS commented Mar 4, 2021

champnic commented Mar 6, 2021

Alex240 commented Mar 6, 2021 •

edited

Loading

cgeier commented Mar 8, 2021 •

edited

Loading

Alex240 commented Mar 8, 2021

mjcheetham commented Mar 8, 2021

cgeier commented Mar 8, 2021

cgeier commented Mar 8, 2021 •

edited

Loading

champnic commented Mar 10, 2021

cgeier commented Mar 10, 2021 •

edited

Loading

champnic commented Mar 11, 2021

bharatvarsha commented Apr 12, 2023 •

edited

Loading

System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431

System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431

Comments

cgeier commented Sep 11, 2020 • edited by champnic Loading

champnic commented Sep 12, 2020

cgeier commented Sep 12, 2020

cgeier commented Sep 12, 2020 • edited Loading

champnic commented Sep 12, 2020

champnic commented Sep 12, 2020

cgeier commented Sep 12, 2020 • edited Loading

cgeier commented Sep 12, 2020

cgeier commented Sep 15, 2020 • edited Loading

cgeier commented Sep 20, 2020 • edited Loading

Any CPU - Prefer 32 bit:

x86:

champnic commented Sep 21, 2020

cgeier commented Sep 21, 2020 • edited Loading

champnic commented Sep 21, 2020

cgeier commented Sep 22, 2020 • edited Loading

limyandi commented Sep 30, 2020 • edited Loading

cgeier commented Sep 30, 2020 • edited Loading

pipalot commented Oct 13, 2020 • edited Loading

champnic commented Oct 13, 2020

champnic commented Oct 19, 2020

Alex240 commented Mar 2, 2021

champnic commented Mar 3, 2021

Alex240 commented Mar 4, 2021 • edited Loading

************** Assemblys chargés ************** mscorlib Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll

Aaaaaaaaa Version de l'assembly : 1.0.0.0 Version Win32 : 1.0.0.0 CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/x.exe

Microsoft.VisualBasic Version de l'assembly : 10.0.0.0 Version Win32 : 14.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll

System Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

System.Core Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

System.Windows.Forms Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System.Drawing Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

System.Runtime.Remoting Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll

System.Data Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll

System.Xml Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

System.Data.DataSetExtensions Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Data.DataSetExtensions/v4.0_4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll

System.Numerics Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll

Accessibility Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

System.Configuration Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Windows.Forms.resources Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/System.Windows.Forms.resources.dll

System.Transactions Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll

System.EnterpriseServices Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll

mscorlib.resources Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/mscorlib.resources.dll

Microsoft.Web.WebView2.Core Version de l'assembly : 1.0.705.50 Version Win32 : 1.0.705.50 CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.Core.DLL

Microsoft.Web.WebView2.WinForms Version de l'assembly : 1.0.705.50 Version Win32 : 1.0.705.50 CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.WinForms.DLL

System.Management Version de l'assembly : 4.0.0.0 Version Win32 : 4.6.1590.0 built by: NETFXREL2 CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll

bgavrilMS commented Mar 4, 2021

champnic commented Mar 6, 2021

Alex240 commented Mar 6, 2021 • edited Loading

cgeier commented Mar 8, 2021 • edited Loading

Alex240 commented Mar 8, 2021

mjcheetham commented Mar 8, 2021

cgeier commented Mar 8, 2021

cgeier commented Mar 8, 2021 • edited Loading

champnic commented Mar 10, 2021

cgeier commented Mar 10, 2021 • edited Loading

champnic commented Mar 11, 2021

bharatvarsha commented Apr 12, 2023 • edited Loading

cgeier commented Sep 11, 2020 •

edited by champnic

Loading

cgeier commented Sep 12, 2020 •

edited

Loading

cgeier commented Sep 12, 2020 •

edited

Loading

cgeier commented Sep 15, 2020 •

edited

Loading

cgeier commented Sep 20, 2020 •

edited

Loading

cgeier commented Sep 21, 2020 •

edited

Loading

cgeier commented Sep 22, 2020 •

edited

Loading

limyandi commented Sep 30, 2020 •

edited

Loading

cgeier commented Sep 30, 2020 •

edited

Loading

pipalot commented Oct 13, 2020 •

edited

Loading

Alex240 commented Mar 4, 2021 •

edited

Loading

Assemblys chargés
mscorlib
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll

Aaaaaaaaa
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/x.exe

Microsoft.VisualBasic
Version de l'assembly : 10.0.0.0
Version Win32 : 14.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll

System
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

System.Core
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

System.Windows.Forms
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System.Drawing
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

System.Runtime.Remoting
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll

System.Data
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll

System.Xml
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

System.Data.DataSetExtensions
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Data.DataSetExtensions/v4.0_4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll

System.Numerics
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll

Accessibility
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

System.Configuration
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Windows.Forms.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/System.Windows.Forms.resources.dll

System.Transactions
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll

System.EnterpriseServices
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll

mscorlib.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/mscorlib.resources.dll

Microsoft.Web.WebView2.Core
Version de l'assembly : 1.0.705.50
Version Win32 : 1.0.705.50
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.Core.DLL

Microsoft.Web.WebView2.WinForms
Version de l'assembly : 1.0.705.50
Version Win32 : 1.0.705.50
CodeBase : file:///C:/Program%20Files%20(x86)/aaaaaa/Microsoft.Web.WebView2.WinForms.DLL

System.Management
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1590.0 built by: NETFXREL2
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll

Alex240 commented Mar 6, 2021 •

edited

Loading

cgeier commented Mar 8, 2021 •

edited

Loading

cgeier commented Mar 8, 2021 •

edited

Loading

cgeier commented Mar 10, 2021 •

edited

Loading

bharatvarsha commented Apr 12, 2023 •

edited

Loading