webview2loaderstatic not available in vs2015?

[LEE-YONG-UN]

It worked when I tested it in vs2019. (#110)

But it failed in vs2015.

I want to work with vs2019

But I have to use vs2015 for the time being.

Is there a way?

AB#33900780

[champnic]

Hey @LEE-YONG-UN - could you add some details/context on the failure you are seeing in VS2015?

[LEE-YONG-UN]

---

When I followed the guide in link #110, there was no problem at build time. However, when running the built app, it does not run with the error message 'Program Too Big to Fit In Memory'. 😵

[LEE-YONG-UN]

I moved the code of the WebView2Sample example to the project created with vs2015 . Without using static linking, my project works.

screenshot :

[champnic]

What is the architecture of your app and what is the architecture of your OS?

This doesn't look like the program itself is actually to big for memory, as the exe is only 220KB...

Have you tried running this from Visual Studio rather than the command line?

[LEE-YONG-UN]

Yes I tried running it in my development environment and it still doesn't run. The current development environment is Windows 10.

Is the binary incompatible in vs2015 because WebView2LoaderStatic was built in vs2019?

Screenshot :

[LEE-YONG-UN]

My question has been abandoned. :(

[champnic]

Sorry for the delay here - I've added this as a bug on our backlog. I'd be very surprised if this doesn't work generally - the WebView2LoaderStatic library was not built using VS at all, so shouldn't be specific to a version of VS.

[LEE-YONG-UN]

Thank you.

[akielbas]

@LEE-YONG-UN when you link against WebView2LoaderStatic.lib is the binary produced a valid executable (it starts with the PE magic numbers)?

We're seeing what may be a similar issue in our VS2017 build and static loader. The linker appears to be generating a garbage binary. We're still root causing to see what's going on.

[akielbas]

@champnic not sure if you'd like for me to open a new issue or track it here, it does sound very similar to what @LEE-YONG-UN is reporting.

My repro steps: 1) Cloned https://github.com/MicrosoftEdge/WebView2Samples 2) Opened WebView2APISample using VS2017 3) Updated WebView2APISample to use v141 toolset and 10.0.19041.0 SDK 4) Modified WebView2APISample vcxproj file using instructions from here: https://docs.microsoft.com/en-us/microsoft-edge/webview2/how-to/static by adding <PropertyGroup> <WebView2LoaderPreference>Static</WebView2LoaderPreference> </PropertyGroup> 5) Built Debug (or Release) x86 target

The binary produced is not a valid executable.

[champnic]

I was able to reproduce this as well. It worked with v141 toolset in vs2019, so might be related to the SDK version or maybe something else.

[LEE-YONG-UN]

@LEE-YONG-UN when you link against WebView2LoaderStatic.lib is the binary produced a valid executable (it starts with the PE magic numbers)?

We're seeing what may be a similar issue in our VS2017 build and static loader. The linker appears to be generating a garbage binary. We're still root causing to see what's going on.

As you said, when I open the generated binary file with PEView, it seems that the PE Magic Number is invalid. It seems to be the same problem. I hope it gets resolved soon.

[ajwfrost]

@champnic do you have any update on this, we've just been finding the same issue: when we link against the static library (and the linker pulls in the reference for CreateCoreWebView2EnvironmentWithOptions) the binary is not a PE executable, it's just shown as a 'data file' and ignored by things like Dependency Walker.

Wondering if there's any alternative mechanism to get at the ICoreWebView2Environment object, it doesn't seem normal to call a Win32 DLL method like this, I was expecting to use CoCreateInstance or similar..? Plus we have had customers download the WebView2 component but they're not finding WebView2Loader.dll on their machine, so our initial attempt at dynamically loading that library to call CreateCoreWebView2EnvironmentWithOptions isn't currently viable.

thanks

[szz743]

I hit the same problem and found out that removing /DEBUG switch from the linker options resolves the it,. Not the best solution though, still need PDB in order to release the software.