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.
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.