RC6 and WebView2 - Error in compiled exe

[wwolf]

Hi,

since yesterday, the WebView2 no longer works in the compiled exe. Everything is still ok in the IDE. Can anyone confirm that here? I use RC6.0.0.4 / WebView2Loader 1.0.790.0 and WebView2 89.0.774.45. I also tested older versions.

Greetings W. Wolf

[Schmidt]

Everything is still ok in the IDE...

When it works in the IDE and not in the compiled Exe -
then this might be caused by "non-matching binaries in the Exes \Bin\-Folder" -
(in case regfree loading is in place in "*.exe-mode")...

Could you check, whether the exact same binaries from the Folder where your "registered version" resides,
are in the Exe-local \Bin\-Folder?

The only other difference between IDE- and Exe-mode is (usually) the Useraccount,
the Process is running under (IDE-process runs as Admin, Exe-process as "normal User").

Olaf

[wwolf]

W10-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.1 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf

W10-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.1 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll


unregister RC6.0.0.1
copy RC6.0.0.4 to C:\RC6\
register RC6.0.0.4

W10-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.4 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf

W10-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.4 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll

W7-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.2 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.664.37 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf

W7-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.2 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.664.37 C:\RC6\WebViewLoader.dll
Try with WebViewLoader.dll V1.0.790.0 -> fail

Greetings W. Wolf

[SearchingDataOnly]

https://www.vbforums.com/showthread....=1#post5443031

[Schmidt]

Found time to review this now - and can reproduce it on my dev-machine...

And it has nothing to do with "regfree-mode" of the RC6-Dlls - or not...

It all works (including the creation of a ICoreWebView2Environment instance) -
but the second part of the "init-sequence" - a call into the WebView2Loader.dll
-> ICoreWebView2Environment.CreateCoreWebView2Controller(hWnd, CallBackObject)
...works only in the IDE (not in the compiled Exe).

The problem is a "weird one" (seemingly has to do with "Process-Security-Settings" somehow) -
because what CreateCoreWebView2Controller (from inside WebView2Loader.dll) attempts,
is simply the "shelling" of the msedgewebview2.exe (sitting in Folder: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\...)

And that "shelling" works (for some weird reason) when the hosting-process is the VB6-IDE -
but not when the hosting-process is the "compiled Exe" (whatever Exename it has).

I've tried all kind of things already on the compiled Executable, including:
- several types of Manifests (including the absolute identical one, I've applied to my VB6.exe)
- running it normally (non-elevated)
- running it as Admin
- also giving the compiled Exe a proper AppID (in Sub Main()) with: SetCurrentProcessExplicit*****erModelID

All to no avail... the "shelling" of: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\msedgewebview2.exe fails -
and in turn the CreateCoreWebView2Controller-method (which initiates this shelling) will not raise a Success-Event on my Callback-Object.

What exactly is different, when the Host-Process is VB6.exe (where that "indirect shelling" of the webview2-child-process is successful),
I've not yet found out...

And what's funny is, when I open via Windows-Explorer the original Edge-Folder:
- C:\Program Files (x86)\Microsoft\Edge\Application\89.0.774.45\
I can successfully start msedgewebview2.exe there via Mouse-DblClick (resulting in a Browser-instance)

But when I go via Explorer into the Folder:
- C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\
I cannot start the msedgewebview2.exe successfully (there's also no error-message, nor any EventLog-Entry)
I followed up in that Folder with two additional attempts:
- starting msedgewebview2.exe from an unelevated Command-Console
- starting msedgewebview2.exe from an elevated Command-Console
Both attempts not resulting in any process-startup - and also no reported info in the Console-Window...

So the problem is not really located in "wrong Dll-Bindings" - all the WebView2Loader-methods work fine -
they simply fail, because:
- a normal compiled Exe as the HostProcess is missing some "hidden Properties" or "registry entries" (or whatever) related to security
- which for some weird reason "can be found", when VB6.exe is the HostProcess

Maybe it's a real bug (in the EdgeWebView-Evergreen-installation of version 89.0.774.45) -
not sure how recent this version is ... if the update came in the last 2 or 3 days, then chances are,
that the same problems exist also for "other languages" ...
(although VB6.exe as a working HostProcess is still "crazy", because it shows that 89.0.774.45 can work OK, "when started from some HostProcesses")


Olaf

[saturnian]

I have exactly the same issue with Webview 2 version 89.0.774.45.


To work around it, I downloaded the "fixed version" 88.0.705.81 on https://developer.microsoft.com/en-u...edge/webview2/
After unzipping it, I copied it in a folder called "999.9.999.99" in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application directory. This version is then taken by default and works perfectly

On the other hand, Olaf, on my PC, starting msedgewebview2.exe in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application\ folder never does anything while it launches Edge in C:\Program Files (x86)\Microsoft\Edge\Application\ , even with a version that works with RC6

François

[wwolf]

https://www.vbforums.com/showthread....=1#post5443031

Thank you! But I know how to use RC6. I've been using that since RC3. The problem occurred without my intervention. There was no new version of my exe. My deployment hasn't changed. W. Wolf

[wwolf]

After unzipping it, I copied it in a folder called "999.9.999.99" in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application directory. This version is then taken by default and works perfectly

Thank you very much! Works perfectly! I am surprised. Is the VebviewLoader so easy to build? Is it based on a version in the folder name? Incredibly!
W. Wolf

[oskarrr]

I have exactly the same issue with Webview 2 version 89.0.774.45.


To work around it, I downloaded the "fixed version" 88.0.705.81 on https://developer.microsoft.com/en-u...edge/webview2/
After unzipping it, I copied it in a folder called "999.9.999.99" in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application directory. This version is then taken by default and works perfectly

On the other hand, Olaf, on my PC, starting msedgewebview2.exe in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application\ folder never does anything while it launches Edge in C:\Program Files (x86)\Microsoft\Edge\Application\ , even with a version that works with RC6

François

Works perfectly again. Thank you!

[Schmidt]

Seems the problem was found now (at the MS-side of things)...

Had to do with "Version-Info-Parsing" on the given Exe-Binary of the Host-Process...

VB6.exe itself seems to have stored its Version-Info in a way "compatible to the Edge-SubProcess-readout-method" -
whereas Version-Info-Resources, produced in a post-compile-step by the VB6-Compiler (in your own Exe) -
were having "compatibility-problems" with the "readout-method" of the Edge-environment.

Here is the proper thread for this in the github-tracker-discussions:
https://github.com/MicrosoftEdge/Web...ack/issues/850
(the cause described in the last few postings in that thread)...

Just now checking here again before pressing the send-button...
aaand yes - a fix for that is now already "rolled out" by MS
(an increase from the failing version 89.0.774.48 to 89.0.774.50)

So, everything is fine again with the "rolling-release" (from an "Evergreen-install" of the WebView2-runtime).

@Wolfgang
The "fixed version" of the runtime-package can always be "shipped" along with your Edge-based App
(to rule out such "breaking changes" in the future).

And you won't even have to put it into the "normal Edge-Install-folder" (behind \Programs x86\...) -
even a folder below your App.Path will do (if you properly point to that path in your WV.BindTo-call).

I still prefer the "evergreen-runtime" though, because it is the only way to remain "on the safe side of things" regarding security- or other patches.

Let's just hope it was a "wake-up-call at the right time", and that this "runtime-update blow-up" by MS was a one-time-thing.

The whole WebView2-Loading stuff is not yet that long "out of beta" - so a few devs at MS were probably still ticking in "test-channel-mode" -
but I think they realize now more and more, that people indeed start using it "in production-scenarios" (making them double-check before releasing something).

Olaf

[wwolf]

Hi Olaf

And you won't even have to put it into the "normal Edge-Install-folder" (behind \Programs x86\...) -
even a folder below your App.Path will do (if you properly point to that path in your WV.BindTo-call).

Dang it, I already knew that!
Thanks for the reminder!

The whole WebView2-Loading stuff is not yet that long "out of beta" - so a few devs at MS were probably still ticking in "test-channel-mode" -
but I think they realize now more and more, that people indeed start using it "in production-scenarios" (making them double-check before releasing something).

It doesn't always have to be a mistake. Sudden interface changes could also be a problem. I think that's good about the fixed version. I can now decide for myself when to upgrade to the next version.

W. Wolf

[xiaoyao]

If you can load it in this way with late binding, I think this is the perfect solution.

dim a as excel.application
Version incompatibility errors often occur in this way.

dim a as object

set a =createobtect("excel.application")
This method does not require the office version of the system.

[wwolf]

Hi

If you can load it in this way with late binding, I think this is the perfect solution.

What question does your answer refer to?
The version incompatibility of the WebView cannot be resolved in this way.
Regards W. Wolf

[wqweto]

Expect soon to be referred to a topic named "sorry,Chrome OCX,Miniblink,VB6 chromium,Chrome core only one dll" marketed as better solution for. . . everything!

This is usually the final routine of the rogue bot we have here.

cheers,
</wqw>

[xiaoyao]

I see, this needs a corresponding version.Different versions of just like chromedriver. Correspond to different chromium version

[SearchingDataOnly]

I see, this needs a corresponding version.Different versions of just like chromedriver. Correspond to different chromium version

No, it should be a problem with the compatibility of Microsoft's WebView version. Under normal circumstances, Olaf’s WebView wrapper always automatically uses the latest version (I haven’t tested this yet)

[wwolf]

And you won't even have to put it into the "normal Edge-Install-folder" (behind \Programs x86\...) -
even a folder below your App.Path will do (if you properly point to that path in your WV.BindTo-call).
Olaf

This is my program folder:
MyApp.exe
cairo_sqlite.dll
DirectCOM.dll
RC6.dll
WebView2Loader.dll
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (unzipped MS folder)

that works:
WV.BindTo cfMain.hWnd '(works with the WebView from the Program Files (x86))

none of this works:
WV.BindTo cfMain.hWnd, , "Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"

what am I doing wrong? The same version is also in my Program Files (x86) folder. How do I have to enter the browserInstallPath argument?

[Schmidt]

This is my program folder:
MyApp.exe
cairo_sqlite.dll
DirectCOM.dll
RC6.dll
WebView2Loader.dll
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (unzipped MS folder)

that works:
WV.BindTo cfMain.hWnd '(works with the WebView from the Program Files (x86))

none of this works:
WV.BindTo cfMain.hWnd, , "Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"

what am I doing wrong? The same version is also in my Program Files (x86) folder. How do I have to enter the browserInstallPath argument?

If you have only the above "blue colored" FixedRuntime-folder version (89) in your App.Path,
then neither of the red-marked calls will work of course...

But even if you'd correct that, there's a high probability that it will fail anyways in RC-6.0.0.4,
because the newer LoaderLibs expect (in case of a Userdefined RuntimeFolder), "a hint"
regarding the supported version-number (in the config-interface, I provide internally).

This "version-hint" is missing in 6.0.0.4 - but now contained in the newest upload 6.0.0.5.

With that new version - and a corrected Runtime-Path-Param like:
-> WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
everything should be fine again...

Olaf

[wwolf]

This "version-hint" is missing in 6.0.0.4 - but now contained in the newest upload 6.0.0.5.

[/COLOR]

Ok, these are my results:

MyApp folder:
MyApp.exe
cairo_sqlite.dll
DirectCOM.dll
RC6.dll (6.0.0.5)
WebView2Loader.dll (1.0.790.0)
Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86 (folder with unzipped files from MS download)
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (folder with unzipped files from MS download)

My different experimental paths
p1 = ""
p2 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
p3 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
p4 = "C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.54"

Code:
ret = mWV.BindTo(cfMain.hWnd, , px)

Results:
p1: all works, ret=1
6x msedgewebview2.exe (89.0.774.54) is loaded from p4

p2: don't works ret=0
msedgewebview2.exe is not loaded

p3: don't works ret=1 (!after .NavigateToString WV_DocumentComplete is not fired)
4x msedgewebview2.exe (89.0.774.54) is loaded from p3

p4: don't works ret=0
msedgewebview2.exe is not loaded

W. Wolf

[Schmidt]

On what WinOS do you run this?

FWIW, the code below works on Win10 in IDE and compiled
(with all 3 different Path-Variations ... using a cWidgetForm as you do):

modMain.bas

Option Explicit

Public fBrowser As New cfBrowser

Sub Main()
  Cairo.SetDPIAwareness
  
  fBrowser.Form.Show
  
  Cairo.WidgetForms.EnterMessageLoop
End Sub

cfBrowser.cls

Option Explicit

Public WithEvents Form As cWidgetForm, WithEvents WV As cWebView2
 
Private Sub Class_Initialize()
  Set Form = Cairo.WidgetForms.Create(vbSizable, "Edge-Chromium WebView2")
End Sub

Private Sub Form_Load()
  Set WV = New_c.WebView2
  Dim P As String
'      P = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.50.x86"
'      P = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
      P = WV.GetMostRecentInstallPath() '<- this is what I use underneath the BindTo-call, when you don't give a specific path
  Form.Caption = P: Debug.Print P
  
  If WV.BindTo(Form.hWnd, 4, P, App.Path) = 0 Then MsgBox "couldn't initialize WebView-Binding": Exit Sub
'  If WV.BindTo(Form.hWnd) = 0 Then Form.Caption = "couldn't initialize WebView-Binding": Exit Sub
  
  WV.Navigate "https://google.com"
End Sub

Private Sub Form_Resize()
  If Not WV Is Nothing Then WV.SyncSizeToHostWindow
End Sub

My Debug-Output for WV.GetMostRecentInstallPath() is:
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.54

Olaf

[wwolf]

Hi Olaf,

I used your code under W10-64 in the IDE and as exe.
My Debug-Output for WV.GetMostRecentInstallPath() is
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.57

I have these folders in my app folder:
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (folder with unzipped files from MS download)
Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86 (folder with unzipped files from MS download)
89.0.774.57 (copy from C:\...\Application\89.0.774.57)

      P1 = ""
      P2 = WV.GetMostRecentInstallPath()
      P3 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
      P4 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
      P5 = App.Path & "\89.0.774.57"
      P6 = "C:\89.0.774.57" 'copy from C:\...\Application\89.0.774.57

P1 works with 6 instances of msedgewebview2.exe from P2
P2 works with 6 instances of msedgewebview2.exe from P2
P3 does not work. 3 instances of msedgewebview2.exe from P3 are started
P4 does not work. 4 instances of msedgewebview2.exe from P4 are started
P5 does not work. 3 instances of msedgewebview2.exe from P5 are started
P6 works with 6 instances of msedgewebview2.exe from P6

I think I found the problem. My App.Path is a network drive.
I've moved my App.Path with all MS-Folders to C:\ -> everything works.
I've moved my App.Path with all MS-Folders to D:\ -> everything works (second local hard drive)

I have also tested different variants with userDataFolder (App.Path, Temp-Path and without parameter). The results are identical.

Summary: App.Path can be anywhere, but the WebView files must on local hard drive saved. Maybe something is wrong with the path resolution in RC6 or in the WebViewLoader?

[Schmidt]

I think I found the problem. My App.Path is a network drive.
I've moved my App.Path with all MS-Folders to C:\ -> everything works.
I've moved my App.Path with all MS-Folders to D:\ -> everything works (second local hard drive)

I have also tested different variants with userDataFolder (App.Path, Temp-Path and without parameter). The results are identical.

Summary: App.Path can be anywhere, but the WebView files must on local hard drive saved.

Good to know, it all works fine, when the Folder with the WebView2-Runtime-Files sits on a local drive...

Maybe something is wrong with the path resolution in RC6 or in the WebViewLoader?

No chance for "messing things up" in the RC6-code, because in case of a userdefined Path to the Runtime-Files,
I'm just passing this Path-String along to MS's WebView2Loader.dll (no chance for me to influence the loading-process in any way after that).

I guess that's another reason for the rule, to better "not use any Binaries from Network-Shares".

Maybe the WebView2Loader (or the upstarting edgeprocesses) have this problem only,
when the NetworkShare-location was given via an UNC-Path... so, did you test this with a "mapped network-drive" already?

What you could try from the outside, is to provide your Network-Path as a file-URI:
(for UNC-Paths the notation would be: "file:////server/folder/subfolder/...")
Mayhap this notation is more willingly accepted than "classicaly given UNC-Paths...

If you have to keep up your network-share-based App-deployment-scheme,
then a little check at App-Startup should be done, whether the Runtime-Binaries already exists in a location locally,
and if not, then just "copy the whole runtime-folder over" to such a local Runtime-location before you init the WebView.

That's not all that uncommon... e.g. we had to do such a thing for a quite large (40MB) *.chm helpfile in our Apps,
because the WinHelp would otherwise not properly startup with the HelpFile on an UNC-Path.

HTH

Olaf

[wwolf]

I guess that's another reason for the rule, to better "not use any Binaries from Network-Shares".

Coincidence. My source code is on a NAS. This is useful because it gives me access from different computers. I really only wanted to test the optional browserInstallPath parameter and therefore copied the WebView files into this folder.

Maybe the WebView2Loader (or the upstarting edgeprocesses) have this problem only,
when the NetworkShare-location was given via an UNC-Path... so, did you test this with a "mapped network-drive" already?

Yes i use by default a mapped network-drive. I didn't test that with the UNC-Path. I didn't realize the problem until I started thinking about the possible differences between my test and yours. Your suggestion with GetMostRecentInstallPath made me recognize the problem. If we want to use WebView in productive systems, it is good if we recognize all dangers early on.

Thank you for your support.
W. Wolf

[Schmidt]

Just found out something interesting...

Background:
What early versions of the WebView2Loader.dll did support,
was the direct referencing of the "real Edge"-Folder in the optional Runtime-Path
(instead of pointing to a Folder which contained the WebView2Runtime)

For the release versions of the WebView2Loader.dll, specifying the "true Edge-folder"
as the one which holds the runtime-binaries is failing - due to a lookup for the term:
"\Program Files (x86)\Microsoft\Edge\ "
If that is contained in the user-provided RuntimePath, then the instantiation will fail.

So, circumventing this "rule" boils down to the question:
"How to be able to give a different Path (not containing the "forbidden" snippet in it),
which nevertheless "points" to the already existing one..."
Answer: SymLinks

Below a code-snippet, which makes use of the CreateSymbolicLinkW API (available from Vista+).

cfBrowser.cls

Option Explicit

Private Declare Function CreateFolderSymLink Lib "kernel32" Alias "CreateSymbolicLinkW" (ByVal pDstFolderLink&, ByVal pSrcFolder&, Optional ByVal IsDirectory& = 1) As Long
 
Public WithEvents Form As cWidgetForm, WithEvents WV As cWebView2
 
Private Sub Class_Initialize()
  Set Form = Cairo.WidgetForms.Create(vbSizable, "Edge-Chromium WebView2")
End Sub

Private Sub Form_Load()
  Set WV = New_c.WebView2
  
  Dim EdgeSrc As String, EdgeVersion As String, EdgeDst As String
      EdgeSrc = WV.GetMostRecentInstallPath("Edge", EdgeVersion)
      EdgeDst = New_c.FSO.GetLocalAppDataPath & "\Edge_" & EdgeVersion
  If Not New_c.FSO.FolderExists(EdgeDst) Then
     'New_c.FSO.MultiFileCopy EdgeSrc, EdgeDst
     Debug.Print CreateFolderSymLink(StrPtr(EdgeDst), StrPtr(EdgeSrc)), Err.LastDllError
  End If
 
  If WV.BindTo(Form.hWnd, 10, EdgeDst) = 0 Then MsgBox "couldn't initialize WebView-Binding": Exit Sub
 
  WV.Navigate "https://google.com"
End Sub

Private Sub Form_Resize()
  If Not WV Is Nothing Then WV.SyncSizeToHostWindow
End Sub

So, the above is able, to start WebView2 against an already existing "normal Edge-installation" -
(by using a "different Symbolic PathName", which points to the original Edge-Install-Path)

The code above was mapping the original Edge-Install-Path into the local User-Directory as:
C:\Users\Olaf\AppData\Local\Edge_89.0.774.57

Side-Note... it is still not "all Roses" with the above approach, because:
- SymLink-creation (pointing into the Programs-Folder) apparently needs Admin-rights
- therefore the Code-Example worked already on the first attempt in the IDE (due to running it already elevated)
- but after deleting the SymLink-Folder Edge_89.0.774.57 in C:\Users\Olaf\AppData\Local\
- and making an additional attempt from a compiled Exe, it failed to create the Symlink (due to insufficient rights)

So, unless somebody finds a way to create a "symlinked folder" against a real Folder which sits in "Programs x86" -
only using "normal UserRights" (I had a normal Exe-manifest set at "asInvoker" in place),
the User would need to be "instructed", to run the App at least on the first attempt "as Admin".

What worked in both cases (IDE and compiled) though,
was "making a full copy" (see the bold, currently outcommented Line in above code)

Maybe somebody with more knowledge about such UserRights-topics,
can help find a solution which works without starting the compiled Exe "as Admin" once...

Olaf

[wwolf]

Hi,
I continued to test yesterday and today so that we can get a better overview of what is possible and what is not possible.

Start from USB stick: Works. SecondsToWaitForInitComplete must not be too small. But I had no problem with the default of 8 seconds. So Regless Stickware should work. I think CD-ROM will work, but I haven't tested it.

Start on a different network (Windows server with Active Directory. My NAS from yesterday has Linux). That doesn't work. However, three instances of msedgewebview2 are loaded and the application shows the browser window with an error message: There is a problem on this page. An Update switch does nothing.

I also want to work with the EverGreen variant as standard. But if someone doesn't want to install this or as a fallover, an alternative solution is always nice. We already know a lot about what's going on.

I did my tests today on W7-64.

I couldn't test the SymLink method today because I don't have an edge installation here (and I don't want to do one).

[WZabel]

I did my tests today on W7-64.

I also did.
I figured out, that any path stops binding, also WV.GetMostRecentInstallPath

40      Set WV = New_c.WebView2 'create the instance
50      webviewpath = WV.GetMostRecentInstallPath()
60      Debug.Print webviewpath
70      If WV.BindTo(picWV.hWnd, 8, webviewpath) = 0 Then MsgBox "couldn't initialize WebView-Binding 1": Exit Sub

[Schmidt]

I also did.
I figured out, that any path stops binding, also WV.GetMostRecentInstallPath

What's the output of:

?New_c.Version

when you execute it in your ImmediateWindow?

Olaf

[WZabel]

What's the output of:

?New_c.Version

6.0.4

[Schmidt]

Please download and install 6.0.5 (I've commented about the failing 6.0.4 in #18).

Olaf

[wwolf]

Please download and install 6.0.5 (I've commented about the failing 6.0.4 in #18).

Attention: on your page there is still 6.0.4 even if the download already contains 6.0.5.
W. Wolf

[WZabel]

Thank you Olaf, your update does the trick.

Now there is my next question: How can request-headers be changed?
It looks as it has to be done when the 'NavigationStarting' event is fired. But there is no such event....

Robert

[Schmidt]

Now there is my next question: How can request-headers be changed?

The new WebView2Loader-Dlls already have interface-extensions for the
TypeLib-defined ICoreWebView2-interface (two of them):
-> interface ICoreWebView2_2 : ICoreWebView2
-> interface ICoreWebView2_3 : ICoreWebView2_2

And ICoreWebView2_2 comes (among others) with the new method:
HRESULT NavigateWithWebResourceRequest([in] ICoreWebView2WebResourceRequest* request)

Here is the Interface-Def for the new ICoreWebView2WebResourceRequest
(a "Data-Object", which needs to be passed into the above new method)...

[uuid(97055cd4-512c-4264-8b5f-e3f446cea6a5), object, pointer_default(unique)]
interface ICoreWebView2WebResourceRequest : IUnknown {

  /// The request URI.

  [propget] HRESULT Uri([out, retval] LPWSTR* uri);

  /// Sets the `Uri` property.

  [propput] HRESULT Uri([in] LPCWSTR uri);

  /// The HTTP request method.

  [propget] HRESULT Method([out, retval] LPWSTR* method);

  /// Sets the `Method` property.

  [propput] HRESULT Method([in] LPCWSTR method);

  /// The HTTP request message body as stream.  POST data should be here.  If a
  /// stream is set, which overrides the message body, the stream must have
  /// all the content data available by the time the `WebResourceRequested`
  /// event deferral of this response is completed.  Stream should be agile or
  /// be created from a background STA to prevent performance impact to the UI
  /// thread.  `Null` means no content data.  `IStream` semantics apply
  /// (return `S_OK` to `Read` runs until all data is exhausted).

  [propget] HRESULT Content([out, retval] IStream** content);

  /// Sets the `Content` property.

  [propput] HRESULT Content([in] IStream* content);

  /// The mutable HTTP request headers

  [propget] HRESULT Headers([out, retval] ICoreWebView2HttpRequestHeaders** headers);
}

I plan to incorporate support for that kind of "fully user-defined Request" into one of the next releases.

Olaf

[WZabel]

This sounds great.
So I will wait patient for new releases.
Thank you!

Robert

[wwolf]

Good news: Microsoft is auto-installing the Windows 10 WebView2 Runtime
https://www.bleepingcomputer.com/new...view2-runtime/

W. Wolf

[wwolf]

I plan to incorporate support for that kind of "fully user-defined Request" into one of the next releases.

Hi Olaf,
is this still current or even in the works?
Greetings W. Wolf