What is good practice for deploying an xll and dll?

135 views Asked by At

My c++ project consists of mylib.xll and mylib.dll. The xll depends on the dll. When I build the project, it dumps the xll and dll in a build output folder (say the x64/Debug folder). I had hoped that when I add the xll into excel, it would automatically find the dll. This is not so, and it pops up an error message "The file format and extension of 'mylib.xll' don't match".

By saving the files in C:\Program Files\Microsoft Office\root\Office16 I established there is nothing wrong with the xll and dll other than their location.

What is the best way to deploy an xll depending on a dll?

  1. Should I statically link so the dll isn't necessary?
    • A bit of a shame, as other non-excel parts of my application will use the same dll
  2. Should I copy both into a folder owned by my application?
  3. How do I tell excel that the dll lives in the same folder as the xll?
    • I found the VBA Workbook_Open() macro runs after opening the addin has already failed, so I can't use that
    • Is there a way to start excel with a special PATH that includes the folder
    • Should I dynamically load the xll after programatically pointing at the dll?
    • But then what if my application crashes before closing and unloading the xll gracefully?
  4. Is there a way to build the xll so it expects the dll in the same folder?

As well as deploying to clients, I would like it to be fairly easy for me to repeatedly build the c++ application and open a spreadsheet pointing at the debug or release build of my choice.

This must be a very common issue, but I haven't been able to work it out

Thank you

1

There are 1 answers

1
Peter A On

I have decided to deploy mylib.dll and mylib.xll in the same folder. I have set the linker for the mylib.xll to delay load mylib.dll. In the xlAutoOpen function, I am calling

    XLOPER12 xXLL;  
    Excel12f(xlGetName, &xXLL, 0);

to get the name and path that the xll was loaded from. Then replace mylib.xll with mylib.dll and call LoadLibrary to load the dll. This seems to work: the xll correctly loads the dll from its own folder.