CefSharp in ExcelDNA

248 views
Skip to first unread message

Andrew Kittredge

unread,
Sep 5, 2017, 1:57:07 PM9/5/17
to Excel-DNA
Calcbench has integrated CefSharp into our ExcelDNA Add-in after years of struggling with .net's terrible WebBrowser.  It was not easy.

We started with Steven Robertson's AppHostCefSharp project.  Steven's project uses http to communicate between the processes, we modified the project to communicate with named pipes.  Our fork is here.

RedGate's AppHost project asks the OS for the executing directory, which is not accurate when you are in Excel/ExcelDNA.  We forked AppHost to allow setting the executing directory.  In retrospect we could have set the executing directory by extending the ProcessStarter class.  In any event our fork is here.

Getting our Wix installer to wrap up everything for deployment was painful but we finally got it.  You need to include all of the files listed here.

We handle permissions (asp.net cookies) by passing cookies across the process boundary and setting them in CefSharp.

This project was a lot of work but having access to a real browser from ExcelDNA has been powerful.

Steven Robertson

unread,
Sep 12, 2017, 4:00:41 AM9/12/17
to Excel-DNA
I had been using CefSharp experimentally for desktop applications, and hadn't used it with Excel-DNA. When I tried this I found that it didn't work. This was due to problems with AppDomain, so far as I understand. One suggestion was to use RedGate.AppHost. This may be taking a sledge-hammer to crack a nut, but lacking any practical alternatives, I had a go at making this work with AppHost. It worked, with some limitations. You practically run the browser component in a different process from the window hosting it. Communication between the web control and the window host is limited. Most of the communication required was from the browser to the Excel add-in, so I started with the HTTP server. I restrict it to local connections, though this may not be absolutely secure - it's good enough. We don't expect the control to be updated as often as a real web browser, so vulnerabilities need to be considered.

Andrew's approach to use a named-pipe looked interesting, and I've worked from his fork to update the example I provide. Looks good to me. I'm still cautious about threading, so using the Excel-DNA way to run code on the main Excel thread. I'm using a blocking collection to pick up the result, as I had done with the web server connections. Certainly, one advantage with the HTTP server is being able to develop the add-in using Google Chrome and Excel-DNA hosting the web-server.

My own motivation was to support the use of React components. I'm writing UI components then that can be hosted in a desktop app, an Excel add-in, or a website. For my application this is near perfect. There are some smaller differences between the Chromium embedded browser, though it is a fairly recent version it's good enough.

The biggest problem with the usual standard .NET WebBrowser control is that it's features vary depending on the browser installed on the system.

My example demonstrates the CefSharp using an HTML page from the file-system, with JavaScript and bound object using a proxy with named-pipe in between. The example lists the sheets and linked to select the active sheet.

Two-way communication across the process boundary would make this work even better. It's important to shutdown the browser control, so I had adopted a polling solution which I'll be glad to remove.

Nice contribution from Andrew here. I'll likely use the named-pipe, and it's a better example now, with one less 3rd-party dependency.

Paul Harrington

unread,
Sep 18, 2017, 8:15:51 AM9/18/17
to Excel-DNA
This is fantastic news! I am looking forward to checking it out. I looked into this a couple of years ago and was daunted by the amount of engineering that seemed to be required.

pjjH

Andrew Kittredge

unread,
Sep 8, 2021, 10:31:59 AMSep 8
to Excel-DNA
I no longer recommend CefSharp, use WebView2 instead. 

Reply all
Reply to author
Forward
0 new messages