RegisterDelegates coming soon?

Jan 31, 2014 at 7:25 AM
Hi,
I was just reading about the RegisterDelegates in this documentation entry, and the example is really cool. So my question is whether RegisterDelegates is coming in a stable release soon?

To be perfectly honest, I don't know if I actually need RegisterDelegates, or if I can make do with RegisterMethods. What I want is to make it easier to declare UDFs as async, for instance be adding an [Async]-attribute, and then use reflection. Would this be possible, and can I use RegisterMethods instead of RegisterDelegates? I have no need for declaring new UDFs at runtime.
Coordinator
Jan 31, 2014 at 9:58 AM
Hi,

RegisterDelegates is much more helpful than RegisterMethods.
I suggest you try the current check-ins, and let me know if you find any problems (or have success).

I have some minor bits and quite a few things to test before making a new release But the current check-ins don't have problems that I know of.

I've been meaning to try making some examples of the dynamic registration - I'll push that a bit higher on the list too.

-Govert
Jan 31, 2014 at 11:37 AM
Thank you very much for your reply! I have downloaded the latest check-in. In order to do this without too much hardcoding, I need to get the name of the dll containing the UDFs, in order to reflect over them. Is there some way I can get this? For instance, can I find it through the .dna-file in some way - even if it's packed?
Coordinator
Jan 31, 2014 at 11:59 AM
If the assembly that you're running in is the same as the one with the functions, you can get it as Assembly.GetExecutingAssembly(). To get a list of all the exported assemblies from Excel-DNA, I'll have to add a little helper. Give me a few minutes.

-Govert
Coordinator
Jan 31, 2014 at 12:39 PM
OK - I've checked in a version with ExcelIntegration.GetExportedAssemblies().

Does that give you what you need?

-Govert
Jan 31, 2014 at 12:50 PM
I think so. But just to make sure: the exported assemblies, are they the ones containing the UDFs?
Coordinator
Jan 31, 2014 at 1:02 PM
I think so. It's the assemblies from the ExternalLibrary tags in the .dna file (packed or not) plus any assemblies compiled from code in the .dna file itself.

Do you want to register as async some functions that use the Task-based API, or just wrapping existing functions to run on the ThreadPool? For existing functions, you might like to mark them so that they are not registered by Excel-DNA itself, but need to be explicitly registered. For this you use the new ExplictRegistration option of the ExcelFunction attribute.

I hope that makes sense.

-Govert
Feb 3, 2014 at 6:36 AM
Edited Feb 3, 2014 at 7:06 AM
Great, that's what I wanted.:)

Well, my first thought was to just wrap existing functions. But I haven't considered the task-based approach, at all. Is that something you would recommend? And would it be easier to use?

By the way, do you have an approximate date for the next stable release, containing all this? The application I want to use this is, has to be very reliable, so naturally I would like to depend only on thoroughly tested and stable libraries, upon release.
Coordinator
Feb 3, 2014 at 8:33 AM
It depends on what your functions are doing. If they are purely computations, then you'll probably do the work on a ThreadPool thread, and whether you use Task.Run(...) or ExcelAsyncUtil.Run(...) is pretty much the same.

However, if your functions are doing some kind of I/O, say reading from a web service or database, then using the new .NET 4.5 await/async support is much better. This allows you to not block a thread while waiting for the I/O, giving you much better concurrency. So for this case it really is better to use the Task-based APIs.

I've made a proof-of-concept for the automatic wrapper generation, and it seems to work fine. It's not quite ready to publish, but it will register any functions returning Task<T> as async functions in Excel. Let me know if you'd like to have a look.

-Govert
Feb 3, 2014 at 8:46 AM
Much of what our functions will be doing are I/O-stuff, so it would probably be a good idea to use the taks-based APIs. Thank you very much for that tip!

I would very much like to have a look, if that's possible!:)