Linking with WebView2LoaderStatic.lib produces corrupted DLL

[szz743]

Hello, I'm trying to get rid of WebView2Loader.dll usage. Everything works just fine if WebView2Loader.dll is linked dynamically, but if I link statically with WebView2LoaderStatic.lib then VS2017 linker produces the corrupted output DLL.
If I comment the only function used from webVeiw2Loader.dll - CreateCoreWebView2EnvironmentWithOptions , then linker produces the correct file.
The produced binary file looks like below:

Tried changing various linker settings - so far no luck, have not found any that would affect the output.
Please advise what can I check. Thanks!

[szz743]

Removing /DEBUG switch resolves the problem. Did not think that this switch could help while I was checking other switches.
Any chance this could be fixed soon enough?
Releasing a DLL without PDB does not quite work for us.
thanks!

[LiangTheDev]

I've tried to build using static lib for WebView2Sample app and I am able to build Debug project and run the app without issue. Try to confirm whether it is the same for you. If the sample app also works for you, try to see what configurations are different between the projects.

[szz743]

I have built x64 DEBUG version of WebView2APISample.exe using v141 toolset of VS2017 and the results are the same - static linking produces invalid binary with the same C5 C9 C33 01 header. bytes. VS version is 15.9.48 but the same was with the earlier version 15.8.3x. MS SDK version is 10.0.19041 but the same happens with other versions.

RELEASE builds produce the same invalid binaries if PDB generation is on.

VS2022 and v143 toolset produces valid MZ binary.
VS2022 and v142 toolset produces valid MZ binary.
VS2022 and v141 toolset produces invalid binary of course

[szz743]

Any chance the problem can be fixed?

[LiangTheDev]

We are still trying to understand it, and not sure whether we can fix it or not at the moment.

Edge WebView2 SDK is built with clang, which tries to be MSVC compatible. Not 100% sure, but our guess is that Clang is building to an ABI/feature set that is compatible with the feature set shipped in VS 2019 (i.e. v142) and includes features/updates/etc that aren’t understood by the VS 2017 (i.e. v141) linker resulting in the corrupted binary/PDB. VS higher version can understand libs built from older toolset, but not the reverse.

If it works with v142 and v143 toolsets, the best way out currently would be to use one of those toolsets.

[LiangTheDev]

Did more search on Edge build environment, it is using VS 2019 toolchain. As it is a global build environment for all Edge binaries, it is hard to change.
Therefore, the solution would be to use VS 2019 or VS 2022 tool chain for building the app.

[szz743]

I noticed that lib is compiled using clang and that it is four time larger than the dll. Lib even contains the very long command-line used for clang.
Unfortunately I cannot use VS 2019 or 2002 toolset, our software currently uses VS 2017 toolset and our SDK libs are not quite compatible with 2019. We still need Windows XP support (not for webview2) so cannot migrate to 2019.
I will go with redistributing webview2loader dll for now.

[icnocop]

Similar issue here #1404