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.