0

I am writing an application that has multiple potential user interfaces and I am using MEF to inject the appropriate implementation during startup. One implementaiton of IDisplay uses ExcelDNA (Excel is the interface). The code launches Excel as a process through

var processInfo = new ProcessStartInfo
{
    FileName  = PATH_TO_EXCEL,
    Arguments = PATH_TO_EXCELDNA_ADDIN
};

Process.Start(processInfo);

This works fine except that Excel is now in a seperate memory space so UI callbacks (i.e. Ribbon button clicks) cannot get access to any injected or assigned properties.

One possible solution is to launch Excel first then have ExcelDNA's AutoOpen() hook (which gets called once the add in has loaded in Excel) call the bootstrapper class to configure MEF however I'm wondering if it is possible to share memory between the C# and Excel processes? Would starting Excel via Excel.Application app = new Excel.Application { Visible = true; } resolve? I would try this but have not been able to find out how to specify the path of the ExcelDNA addin for it to load (like above).

clicky
  • 865
  • 2
  • 14
  • 31

1 Answers1

3

Excel will always run as a separate process. So you can't share memory between the Excel process and another process. However, C# code can run inside the Excel process - this is exactly how an Excel-DNA add-in works.

You can also communicate between the Excel process and some other process. One option for this is to use the COM Automation interop - this is what you're doing when you call new Excel.Application from your own executable. You are starting a separate Excel process (or connecting to an existing running process), and then getting back an inter-process communication proxy (the Application object).

If you then want to tell that Excel process to load an Excel-DNA add-in, you can call Application.RegisterXLL(path_to_add_in) to have it load the .xll. How you hook up the Excel-DNA add-in and the rest of your code is still to be figured out.

You might still need some kind of cross-process communication, like .NET Remoting, WCF with named pipes or something like that.

Govert
  • 16,387
  • 4
  • 60
  • 70