Preventing some ExcelFunctions from being visible in Excel

Mar 31, 2014 at 9:18 AM

We would like to prevent some ExcelFunction attributed methods from being visible in Excel. Moreover we'd like to be able to change this settings with a simple configuration change with no need to rebuild the XLL.

We started implementing a solution based on reading the xll.config and filtering the list of methods found by ExcelDNA during startup.

Would you be interested in us contributing this to ExcelDNA ? Do you have a better idea on how to do that ?

Mar 31, 2014 at 10:04 AM

It sounds like something that should be part of the new CustomRegistration library I've been making (see This library has some helpers for rewriting registrations, changing parameter types etc. Having a mechanism for filtering the registrations based on some configuration would fit right in. You'd basically define another IEnumerable<ExcelFunctionRegistration> -> IEnumerable<ExcelFunctionRegistration> processor, which just passes through the appropriate ones. You can also define your own attribute to set this, or derive from ExcelFunctionAttribute.

It you could have a look there, I'd appreciate any feedback on whether that would work for you.

Mar 31, 2014 at 5:11 PM
Hi Govert,

Thanks for your reply.

I work with freeman478 for the same project.

As we need to load the filtering information from a config file. But application starts with excel.exe, so not easy to get the app.config or xll.config file. Working directly in ExcelDna solution,ExcelDna.Integration.ExcelIntegration:Initialize(string xllPath) seems to be easiest way to get the config file.

My question: in your ExcelDna.CustomRegistration solution, can we get equivalent path easily?


Mar 31, 2014 at 8:35 PM
Edited Mar 31, 2014 at 8:35 PM
Hi Yi,

Excel-DNA will automatically load a file called <YourAddIn>.xll.config as the configuration file for the add-in's AppDomain. You can then access settings or whatever in there with the regular .NET Configuration classes.

Otherwise, you can find the full path to the .xll with a call to:
  • ExcelDnaUtil.XllPath (in the new version 0.32), or
  • with a call to XlCall.Excel(XlCall.xlGetName), in older versions (not safe to call from a ribbon handler).
If possible, I'd recommend you not fork the main Excel-DNA runtime, but use the published version of that. Rather try to add your features on top of the CustomRegistration library, or even improve CustomRegistration to suit your purposes and send a pull request on GitHub.