0

I have an AddIn application. It is composed of several class library dll files.

The host application that the AddIn is launched from is found in a completely different folder on the hard drive. Not a parent nor subdirectory. And this is by the host application's "AddIn" design schema. I cannot do anything about this.

I am trying to use CefSharp for users to login with. However, it appears that CefSharp is looking for the dependency redistributable files based on the executable's location at runtime.

That is not where the dependency files are going to be. And I do not have the option to place them there, since I believe the host application is using CefSharp to its own degree, using different versions of those same dependency files.

I know that CefSettings can be set to guide locales to other directories. Is there any way to do the same thing for libcef.dll and company?

I've tried Fody Costura to combine the dependencies into my own, hoping that CefSharp would see the dependencies at runtime, but all I'm getting, consistently, is

"Could not load file or assembly 'CefSharp, Version=75.1.142.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138' or one of its dependencies. The system cannot find the file specified."

I've also tried finding out exactly WHICH dependency it's not finding through ProcessMonitor. It's a lot to look through but I'm noticing that it is attempting to find a file at "en/CefSharp.Wpf.Resources.dll" in several locations. I think this is probably just noise.

Also, I suspect this whole project will be moving to .NET Core as the GUI options open up with .Net Core 3.0, so if there is a .Net Core direction that would be more future proof to adopt for a simple login-and-leave, please let me know.

cyanstudios
  • 1
  • 1
  • See `Option 2` in https://github.com/cefsharp/CefSharp/issues/1714 you can use the same approach, just change the `Resolver` method to point to the appropriate directory. There is an open issue on `GitHub` regarding adding `.Net Core` support. – amaitland Oct 01 '19 at 22:26
  • Some other options are listed at https://github.com/cefsharp/CefSharp/issues/601 – amaitland Oct 02 '19 at 01:40
  • @amaitland, thank you for your response. I should've mentioned that early on in the process yesterday, I tried that option #2 and it was giving a similar result. In the Resolver method, if I debug it and wait for something to attempt to resolve, it is always CefSharp.Wpf.Resources.dll that it attempts to resolve. However, that file does not exist in my build folders or any redist folder that I've found, so it is never loaded. https://imgur.com/a/ADVXhDk I'm sorry if I'm missing something. – cyanstudios Oct 02 '19 at 13:56
  • The example code provided should return null for the resources dlls. There is no resource all as the build doesn't generate one. See https://stackoverflow.com/questions/4368201/appdomain-currentdomain-assemblyresolve-asking-for-a-appname-resources-assembl for background – amaitland Oct 02 '19 at 23:19
  • Sorry for the delay. Yes, I stumbled across a similar post a little while after my comment. In short, this resource.dll is not really relevant to the issue. I believe the problem is the fact that the host application has its own version of many of these libraries. I think they are conflicting. It looks like I do not have the option of using CefSharp within my addin, although I may be able to use it in an external process. I can work with that. Thank you for your help again. – cyanstudios Oct 04 '19 at 13:36
  • If CefSharp is already used in the host application then you are limited to using exactly the same version. – amaitland Oct 04 '19 at 19:49

0 Answers0