CEF Forum

Hello,

This is similar to the question asked in Using CEF in a Plug-in Environment.

Forgive my ignorance, certainly not my area of knowledge. We've got a single process host .NET application. The host application loads multiple winforms apps, isolated by app domain. These child apps reference CEF, and invoke their own calls to CefRuntime.Initialize, etc (though not CefRuntime.Shutdown).

In our case, the child apps may reference different versions of CEFGlue & CEF.

- Is this scenario workable / supported?
- Any suggestions on how to handle such a scenario?

Thanks.

It is not recommended/supported to load multiple versions of CEF in the same process. On Windows you can parent HWNDs across processes so you could launch each version in a separate process controlled by your own IPC and have them all parented to the same top-level application window.

Hello.

In short - no.

1. Only one CEF library should be loaded in process and initialized once. (Well, actually it maybe work if loaded different libcef versions/instances in sinle process, but i'm think this scenario is not tested at all.)
2. CefGlue: P/Invoke (DllImport parts) resolves module by name, so it should reuse same module handle. So - whack, it will not work.
3. CefGlue: I'm never test it with non-default domains. It should work from any single (non-default) domain.
4. CefGlue: (Not your case) Accessing to same CefGlue assembly from multiple different domains will lead to errors, because i'm hardly rely on static fields. This will lead to some logic errors at all levels (init flags, object marshalling - gc roots & ref counting).

So looks like there is no have chance to get it work with app domains with your requirements.

Possible solutions:

Depending from how deep plugins use browser, you may want unify control interfaces or counterwise left them unique.

1. Integrate CEF into host. Provide single CEF-based control hosted by plugin-host. Single version, classic design. Unified interfaces of course doesnt met your init reqs.

2. Implement out-of-process browser. I.e. plugin creates child process. Child process via IPC interact with plugin, and inserts native browser window by using window reparenting. Plugin simple wraps this. You can unify or leave unique each plugin. Hard way. But it guaranteed to work. There is how i'm make add-id for outlook. Additionally this can help break x86/x64 differences, while out of process browser can be simple x86 and able to run by x86 and x64 process. For outlook case this is also removes any process instability, so plugin does not conflict with anything, does not crash plugin host, and more important (with outlook case - no problems with stealed focus on new popup windows, no need to hook main hwnd (which finally almost impossible in outlook), something else...).

1-st way are easier as for me.
2-nd more reliable, but usually MUST be used if you not own host app.

Excellent, thank you both for your help / advice

Will most likely spend time investigating option 1. We do own the host, so it's certainly possible, though will require a little bit more work due to its structure, but no worries.

Hi,

I'm new to CEF and currently I'm trying to get it Working into an Outlook Addin. Therefore I created a Ribbonbutton (Outlook 2013+). Into my clickhandler I create a new WPF window:

CefRuntime.Load();
MyWindow window = new MyWindow();
WindowViewModelvm = new WindowViewModelvm ();
window.DataContext = vm;
window.Show();

which hosts the cef control :
<cef:WpfCefBrowser StartUrl="https://www.google.de" />

But while loading this window I get an Exception 'failed to create browser'.

Is there any running example for MSOutlook/MSOffice Addins?

Thanks alot
Kooki

There is no public available example. Also WPF is wrong choice. All outlook .net based addins uses winforms. Also you should not load CEF inside outlook addin otherwise i'm sure, users ban plugin over time. It requires more intelligent and complex arch which i'm describe above.