WPF XBAP FileNotFoundException when attempting to load CefSharp dlls

[churstz]

WIndows10 x64 .NET 4.6.1 Framework
WPF XBAP application running in full trust under AnyCPU with the Resolver code to load the appropriate bitness assemblies from the Debug directory (see screenshots above).

The PDBs from Nuget don't sync with the source code so I can't tell the exact line, but it 's in the CefSharp.Core project in the Cef.h file when the Cef.Initialize(settings) is called. The failure is around the line: (see screenshot above)
auto success = CefInitialize(main_args, *(cefSettings->_cefSettings), app.get(), NULL);

System.IO.FileNotFoundException was unhandled
Message: An unhandled exception of type 'System.IO.FileNotFoundException' occurred in Unknown Module.
Additional information: Could not load file or assembly 'CefSharp, Version=63.0.3.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138' or one of its dependencies. The system cannot find the file specified.

[churstz]

In using ProcessMonitor, I'm able to see the CefSharp.Core.dll is loading as expected from the path provided by the Resolver, but the CefSharp.dll is attempting to be loaded via the GAC for some reason.

[baby-Jie]

you can see the fourth question. it may help you. Or you can use depends to find what dll you lose.
https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions

[churstz]

Before posting I reviewed the FAQs and verified I have all the various VC redist's installed, the required files are packaged up by nuget and put in their corresponding build project's Debug\x64 and Debug\x86 directories, I'm debugging locally so no ClickOnce deployment concerns yet and the Generate Serialized Assembly is Off. In my case the problem isn't the CefSharp.Core.dll but rather the CefSharp.dll that's not being located. When I step through the code I can can confirm both of these assemblies are being loaded by the Resolver code as well. This Exception occurs after the assemblies are loaded....

[churstz]

So the first ProcessMonitor screenshot above is probably a bad example. In general, .NET is attempting to resolve Assemblies through it's normal locations it's looks. which is more so what that shows. This screenshot shows the CefSharp.dll successfully loaded from the \Debug directory (via the Resolver) but further on down it never hits the Resolver code again after it's searches in the "typical" places like the GAC and the SyWOW64 directories...

I've also tested by copying the bitness specific version (x86 / x64) of files up a directory directly into the \Debug path to avoid the Resolver code but it fails also. I'm able to compile and run the WPFExample app locally so it's not that any prereq files are missing from my system.

[amaitland]

Does the minimal example run? https://github.com/cefsharp/CefSharp.MinimalExample

Looks more likely a problem with your project/environment.

[amaitland]

Looking in the GAC is perfectly normal

[churstz]

I'm not sure how familiar you are with WPF XBAP applications, but they are downloaded via the web to a local workstation in a user's IE Temporary directory and run from there. There is no installation into the GAC. While I understand that .NET applications have a host of locations they usually look to resolve assembly paths, third party assemblies such as this I would expect to resolve to the local directory the application is executing. The Resolver code should then also aid in locating the correct bitness version as well.

Because I can execute the standard WPF Example app without registering the assembly in the GAC, I would expect the XBAP WPF app to work the same way, but it does not. I'm wondering why the code is correctly resolving the assembly path via the Resolver as shown higher in the screenshot, but not lower where it's looking in the GAC.

[amaitland]

My point is quite simply that looking in the GAC is quite normal and expected, you initially indicated it wasn't expected. Doesn't matter how it's installed the way .net resolves assemblies should remain consistent.

I've never tested with xbap, thought I've used clickonce and it's a basically the same mechanics for file deployment, support for unmanaged resources has always been a problem. You should review the Clickonce issues, they might provide some pointers.

[amaitland]

For reference I'd recommend reading https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies#step3

[churstz]

Yes. The Probing portion of what is documented in your link is effectively what is being done using the ApplicationResolver logic identified in Option #2 (#1714).

I have this logic as well as tried using the config file's referenced in the link you provided. As I've indicated, the assembly is loaded in memory when using both of these options via the XBAP WPF logic but it hits a point inside the Cef.Initialize() call where the same assembly is needed again, but this time it can't be found.

[churstz]

I don't believe this to be a ClickOnce deployment issue at this point as I'm simply debugging in Visual Studio and calling IE directly to load the XBAP. I suspect the issue has something to do with how XBAPs are hosted inside of IE and the PresentationHost.exe that's not playing well with the Cef functionality even though XBAPs are WPF applications.

[amaitland]

Have you tried removing the assembly resolver and setting a probing path? Have you confirmed that CefSharp works with XBAP with the simplest possible Implementation? The two AnyCpu options I've listed aren't the only options you have, they're just the only two I've tested. You could also do some copying on first load, check the current process bitness, copy the files from the x86/x64 directory into the executing folder and delete the two x86 and x64 folders. I've not tested this approach, should be trivial to implement.

Please update the issue title to better reflect the problem. I'll leave this open for now, perhaps someone else has some experience with XBAP. My initial reaction is this isn't a bug in CefSharp and I personally have no XBAP experience so asking on say stack overflow is possibly better.

[churstz]

Yes, I'm trying to be respectful of yours (and others time). I have tested using the probing in the config file which avoids the need of using the Resolver codebase but it doesn't work. I've also added post build scripts to take a copy (and optionally delete) the x86 directory contents and copy it into the project Debug path as well hoping that would resolve the assembly reference but that doesn't work either. I've also created a simple WPF Browser Application (aka XBAP) solution to test the same functionality but that does not work (see attached).

I would debug the source myself, but for some reason my references the the appropriate source files don't sync up

XBAPCefSharpSampleSolution.zip

[amaitland]

Please no binary (zip, etc) links, fork the MinimalExample and push your changes to GitHub. (Alternatively use a code sharing service list Gist or Pastebin).

https://github.com/cefsharp/CefSharp/blob/master/ISSUE_TEMPLATE.md#bug-report

[churstz]

My apologies.. I've forked the code and added a pull request 47 (cefsharp/CefSharp.MinimalExample#47)

[amaitland]

I had a quick look, no idea what's going on, behaves in an unexpected way and I've no experience with XBAP to even speculate.

[churstz]

As much as it pains me to say it, there is an MS Edge package similar to this which does work with a WPF XBAP project. While the requirements are more stringent and completely MS based, I thought I would pass it along in the event any of it's codebase may assist with resolving the CefSharp assembly loading issues.

https://docs.microsoft.com/en-us/windows/uwpcommunitytoolkit/controls/webview
https://github.com/Microsoft/WindowsCommunityToolkit/releases

The Edge functionality only works on Win10 w/ the April 2018 update applied which means they've modified something to include hooks. With that in mind, after confirming it works, I did go back and try to CefSharp functionality again to see if any of the hooks also helped out for Chromium. Unfortunately the same results as before, the FileNotFoundException.

[amaitland]

You can try https://bitbucket.org/xilium/xilium.cefglue/overview or https://bitbucket.org/chromiumfx/chromiumfx

[81867376]

I have the same question.

[81867376]

"https://bitbucket.org/chromiumfx/chromiumfx" It's not wrong, but it's not on display in xbap.
It's right to show it in WinForm

[amaitland]

Closing this as wontfix. I did look at this further a while back and the issue is that an XBAP app attempts to load in the non default AppDomain. If you run the code below it should return false.

var isDefault = AppDomain.CurrentDomain.IsDefaultAppDomain()

VC++ doesn't support running in non default AppDomain, as a result neither does CefSharp.

See #351 if you need to know the background.

Either ChromiumFx or CefGlue should be workable, no idea exactly what is required.

If someones does work it out then post a link back here if you like.