MEF

Oct 30, 2011 at 9:21 PM

Hello,

Just wondering, its possible to use MEF with Excel-DNA, to load other assemblies in runtime and add more UDFs ?

Thanks.

Coordinator
Oct 30, 2011 at 9:32 PM

Hi,

There is some support in Excel-DNA for explicitly registering a set of methods at runtime. From a macro in your ExcelDna project you can call ExcelDna.Integration.Integration.RegisterMethods(methodList) with a List<MethodInfo>, which will register the methods through Excel-DNA. 

However, Excel-DNA has no MEF support built in, so you'd have to host MEF in your own add-in. And then somehow use reflection find the methods you want to register.

I have no experience with MEF myself though, so I'd be keen to know what you find if you give it a go. Also if you run into particular changed on the Excel-DNA side that would help in this scenario, let me know.

Regards,

Govert

Oct 30, 2011 at 9:54 PM
Govert,

Thanks for your support.

I will try to build a solution using MEF and Excel-DNA, soon as i have
something working i will send to you.

Thanks!

2011/10/30 govert <notifications@codeplex.com>:
> From: govert
>
> Hi,
>
> There is some support in Excel-DNA for explicitly registering a set of
> methods at runtime. From a macro in your ExcelDna project you can call
> ExcelDna.Integration.Integration.RegisterMethods(methodList) with a
> List<MethodInfo>, which will register the methods through Excel-DNA.
>
> However, Excel-DNA has no MEF support built in, so you'd have to host MEF in
> your own add-in. And then somehow use reflection find the methods you want
> to register.
>
> I have no experience with MEF myself though, so I'd be keen to know what you
> find if you give it a go. Also if you run into particular changed on the
> Excel-DNA side that would help in this scenario, let me know.
>
> Regards,
>
> Govert
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe on CodePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at CodePlex.com
May 23, 2012 at 2:40 PM

Hi,

I wanted to follow up on this thread related to Excel-Dna-MEF composition.  Based on my reading of the ExcelDna.Integration project, I thought the following was the essential sequence.

  • DnaLibrary.Intialize
    • GetAssemblies() => discoveres available assemblies
    • AssemblyLoader.ProcessAssemblies => discovers ExcelFunction and ExcelAddIn types and compiles their IL methodinfo
      • discovers Excel Function and Addin types and compiles their IL method info.
    • ExcelRtd.RegisterRtdServerTypes
    • ComServer.RegisterComClassTypes
  • DnaLibrary.DnaLibraryAutoOpen (invoked by Loader.XlLibrary by reflection)
    • DnaLibrary.CurrentLibrary.AutoOpen
      • Integration.RegisterMethods

So, is calling Integration.RegisterMethods enough?  I also did not see how the RegisterMethodsDelegate is set.  Can you point me to this?  Seems like the DnaLibrary.Initialize steps related to Excel are important and building the MethodInfo are absent.  Also, some of these EDNA Assembly related types are internal and not public.  How can a MEF container reuse them?

Much Obliged, BT

Coordinator
May 23, 2012 at 9:28 PM

Hi BT,

I think you have the basic flow right - the "compiles their IL" is basically the creation of some wrappers that deal with the parameter marshalling, and the creation of a dynamic assembly that contains the delegate types that eventually get registered with Excel. This work is done again if you call Integration.RegisterMethods.

I'm not sure what you mean by 'is calling Integration.RegisterMethods enough?' It's enough for you to register some methods with Excel. It's not enough for you to register RTD servers, ribbons etc.

There is no (public) way of registering a whole new assembly while your add-in is running - so that the RTD servers etc. would be registered. However, it might be possible to update and re-load an add-in if you have a fresh .dll that should be loaded.

RegisterMethodsDelegate is set via reflection from the ExcelDna.Loader project, in the LoadIntegration method of ExcelDna.Loader.XlAddIn. The hookup between ExcelDna.Loader and ExcelDna.Integration is tricky, because I wanted there to be no dependency either way. I try to declare as little as possible of the internals of Excel-DNA public, and I would not expect a container to reuse these.

It might be much easier to give some help if I knew what you were trying to do. How would you like to use MEF to put your add-in together?

Maybe we are just missing one or two additional integration entry points.

Regards,

Govert

May 24, 2012 at 3:20 PM

Hello Govert,

I originally conceived that my add in would be started up by Excel and does the following.

  • Create bootstrapper that hosts the MEF parts catalog and MEF object container.
  • Populate catalog with locally available assemblies (for now).
  • Populate object container by discovering IModule implementations in assemblies.
  • Discover and collect EDNA types which are siblings of IModule that are marked as ExcelFunctionAttribute.
  • Register UDF's using ExcelDna.Integration.RegisterMethods.
  • Setup shared logging, network client proxy, etc.
  • Return control to Excel.

This scenario supports loading of multiple modules (*.dna, *.xll) which is common if multiple teams are working in loosely coupled fashion and initializing services shared across different Excel UDF's.  What I am missing is how to properly initialize ExcelDNA when it is not loaded by its XLL, ideally by passing some Excel application objects for EDNA's internal initialization.

Or, is there another way for me to better refactor my code so that I can be notified of the AutoOpen() event or when the EDNA XLL addin is started so that I can perform the Bootstrap stuff?  Can I implement an interface or register for some events?  That way EDNA remains in control as the "root" AddIn.  I am fine with this too.

I have a picture that clarifies the flow but codeplex discussions does not supporting posting such files herein.

Anyhow, I am excited about baking Excel-DNA into our applications and believe it is a quantum leap forward, especially for our technically agile business users.

Best, BT

May 24, 2012 at 5:41 PM

Quick update..

I am experimenting with my Bootstrapper implementing the ExcelDna.Integration.IExcelAddIn interface and am including the runtime dll as an external library in my *.dna file. I believe this is going to work just fine.  The Bootstrapper is getting launched upon the AutoOpen event triggered by EDNA (confirmed through debugger), but don't see the AutoClose event triggered or exceptions thrown when I shutdown Excel.  Anyhow, I will update as I make further progress.

public class Bootstrapper : DisposableBase, IBootstrapper, IExcelAddIn
{
        public void AutoClose()
        {
            Stop();
        }

        public void AutoOpen()
        {
            Init();
            Start();
        }
}
Coordinator
May 24, 2012 at 10:01 PM
Edited May 24, 2012 at 10:02 PM

Right. This last plan where you drive the MEF initialization from the AutoOpen seems right to me. The idea of your code loading Excel-DNA "when it is not loaded by its XLL" is not viable at all.

It seems your only current question is about the AutoClose:

By design (and dealing with some Excel quirks), AutoClose is only called when your add-in is explicitly unloaded by the user in the add-ins dialog, or if the add-in is re-loaded via File->Open. In this case you should be cleaning up your add-in - particularly removing any UI customization.

On the other hand, when Excel is closing normally, AutoClose will not be called. Since the process is shutting down, you typically should not do any clean-up yourself. (Network connections, open files and anything in memory will be most quickly and efficiently cleaned up by the operating system.)

However, if you really need some notification of Excel closing there are some workarounds - easiest is if you are defining an Excel-DNA ribbon, then you can just override the OnBeginShutdown or OnDisconnection methods. If you have no ribbon, it can also be done by creating an ExcelComAddIn-derived class in your add-in, but for this you need a trick to work around a bug in the v0.29 release of Excel-DNA (fixed in a more recent check-in). If you want to work off the v.0.29 release, the workaround is described here: https://groups.google.com/group/exceldna/browse_frm/thread/143bd77dec8e6579

Govert