Bloomberg Addin Co-habitation

Jul 20, 2012 at 12:25 PM


I have written an add-in that must live alongside the Bloomberg Excel add-in (BEA) and wanted to better understand 2 Excel-DNA (EDNA) processes and components to ensure co-habitation. 

  • Installation
    • I am adding a registry entry to HKCU\....\Excel\Options\Open="/R MyAddIn.dll"
    • Where does EDNA create its registry entries at runtime?  Are they partitioned from other add-ins such as BEA?
  • RTD
    • Presently, I do not expose RTD functionality, but BEA does.  So long as this the case, does EDNA have any default interactions with the Excel RTD runtime?  I suspect not, but want to check.
  • General Gotchas
    • I understand that each EDNA addin has its own .NET App Domain to partition itself from others.  Besides taking too many CPU cycles, allocating memory, or over-writing someone else's cells, what are some other possibilities for interfering with other add-in's?  Would it matter for example, if addin A is running .NET v3.5 and my EDNA addin B is running .NET v4.0?  Just trying to think "outside the addin"..

Cheers, Bishr

Jul 20, 2012 at 6:33 PM
Edited Jul 20, 2012 at 6:44 PM

Hi Bishr,


For the installation you should note that there may be a number of registry keys, with names OPEN, OPEN1, OPEN2, OPEN3 etc. When installing you should enumerate the keys and add yours to the end, and likewise take care when removing your add-in.


Excel-DNA writes some temporary registry entries if you use any of the following features:

  • RTD Server
  • Ribbon
  • Custom Task Pane helper
  • Com Server support
  • Async helpers in ExcelAsyncUtil.

If you run Regsvr32.exe <YourAddIn.xll> or you call ComServer.DllRegisterServer in your add-in, then persistent entries may be written.

To write the persistent entries, Excel-DNA sometimes first attempts to use to HKEY_CLASSES_ROOT, and if that fails, uses HKEY_CURRENT_USER\Software\Classes. In the other cases only the user's HKEY_CURRENT_USER\Software\Classes hive is used.

The registrations write entries for the CLSID and ProgId, and sometimes the TypeLib to allow the COM loading to work right.

Excel-DNA either creates unique CLSIDs and ProgId using a Guid, or uses those assigned in your code. So they should be unique, even if you have different Excel-DNA add-ins.


Excel-DNA also uses RTD for the new async support, exposed via the ExcelAsyncUtil class. The main danger for interaction with other add-in is in the global Excel ThrottleInterval settings. Excel-DNA does not touch this setting, but the working of the RTD servers and async support depends on it not being set to some unreasonable value. There is a sample in the Excel-DNA distribution that should how you could set or reset this value.


The .NET runtime 2.0 (which is also used by .NET 3.5) and the runtime v4.0 can both be running concurrently. Excel-DNA handles the loading properly, so it starts and loads the right runtime version as needed. If your Excel-DNA add-in loads .NET 4.0 first, I am not sure which runtime will be used when other add-ins load. It might depend on how they are activated, whether you have additional information in an excel.exe.config file etc.

If some other add-in loads .NET 1.1 first, no Excel-DNA will be able to load into the process. Under an unpatched install of Excel 2007 most (non Excel-DNA) add-ins using .NET will be loaded under the .NET 1.1 runtime, thus breaking most VSTO add-ins. MS released a patch fairly soon.

The most obvious ways that Excel add-ins can interfere is in using the same names for functions or macros. Typically the last one 'wins'. But it makes sense to keep all the functions of an add-in together with a shared prefix. That also makes the functions easier to find when typing into a cell.

Add-ins that implement advanced features with timers and macros will often trash the undo stack - for example Bloomberg's =BLP function, or the array resizer and queued async runners in Excel-DNA.


That's all I can think of for now. Let us know if you run into any issues.