-
Notifications
You must be signed in to change notification settings - Fork 52
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.NullReferenceException when Debugging as Any CPU or x86 on 64-bit OS #431
Comments
If you downgrade the SDK to 579-prerelease do you still see the issue? |
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. |
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.
Forgot to mention that I'm using VS 2019 (version: 16.7.3). |
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! |
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:
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:
Updated:
Next, update the "EffectivePlatform" code: Original:
Updated:
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":
Add Condition to "Content":
Here's the code: Original:
Updated:
*Note: These changes weren't tested with "arm64". Here's the complete Microsoft.Web.WebView2.targets file that works: Microsoft.Web.WebView2.zip |
For anyone interested in seeing the values of VS/2017 / VS 2019: In the output, search for "Platform" and/or "EffectivePlatform". When done, one can change verbosity back to "Minimal" (if desired). |
For anyone reading this, when installing the WebView2 NuGet package, it looks like the following process occurs: If The necessary files/folders are copied from Update the code in both of the following files:
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
To see the Path being used:
Click on one of the following files and look at the Path property:
|
@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:
Results:
x86:Executable Path: "bin\x86\Debug\Test.exe" Existing Files:
Results:
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.
If
I think this can be rewritten as:
Is Here's an updated version of Microsoft.Web.WebView2.targets
|
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! |
@champnic I noticed that in the NuGet package the following folders for ARM:
Minor detail, but I think that ARM is usually written in upper-case. So perhaps:
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:
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 |
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. |
@champnic In the WebView2 0.9.628-prerelease package, I noticed the following folder structure:
However, in the "runtimes" folder, there's the following:
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". |
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. |
@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". |
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. 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. |
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. |
Hey @Alex240 - could you add some details about your specific repro steps and setup? |
Hi @champnic the context the problem occurs on Windows 7 64b with error message when try to load Webview2 : ************** Texte de l'exception ************** ************** Assemblys chargés **************
|
I have a customer of my library that just experienced this as well. Please reopen. |
@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. |
Hi @champnic, yes the app use a writeable user data folder and works fine on most of computers tested. |
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: I created and tested a demo VB.NET program using the following: SDK: v1.0.705.50 (Microsoft.Web.WebView2) 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? |
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. |
@mjcheetham: I've updated the post. |
@Alex240: According to the documentation:
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). |
Hey all (@mjcheetham @Alex240) - 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? |
@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. |
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. |
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. Error is Webview2 runtime is installed on client using standalone installer. That is not an issue. It works if I use it via Visual Studio. |
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:
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:
Test 1: (Any CPU)
Test 2: (x86)
Here's the demo project: WebView2Test.zip. It's just a WebView2 control on Form1.
AB#29286853
The text was updated successfully, but these errors were encountered: