DLL v XLA - which way to go?

[PeteG]

Hi,
I am returning to Excel VBA after quite some time off of the subject. I will be rationalising a set of Excel files that have grown and expanded over time and contain similar code, updated at different times by different people. My first thought is to bring all this code together in one source, to avoid all of the similar code that exists (that should actually be the same but isn't).
So, I will probably end up with a set of files (split because the business wish it to be that way) but hopefully referencing the same code base.
My question is; why would I use an XLA over a DLL, or vice-versa? Both would give me a single source of my code but what are the big advantages of one over the other? I can understand that an XLA might be the way to go if it is only ever going to be shared with other Excel files and will contain purely Excel-related functionality - but would I lose anything by creating an XLA ahead of a DLL?
Thanks for any advice

 

[combo]

DLLs are faster (esp. in case of complex calculations) and more secured, probably you still will need 'xla' as an interface between excel and dll file.
If you plan to intensively use excel functions, modify interface etc. 'xla' add-in will be the simplest, however it is easy to recompile the code (in fact, break vba project protection).

combo

 

[PeteG]

Thanks for your thoughts. However, what about distribution? From memory, both methods are similar in that I have to make the XLA or DLL available to all the users (on a network share, for example) in order for them to be able to use them?

 

[fumei]

The difference is that the DLL has to be registered with the OS, in order to be used. An XLA file just has to be available.

faq219-2884

Gerry
My paintings and sculpture