Is it possible to make ExcelDna add-in load into existing AppDomain?

[John Doah]

I already have existing VSTO add-in and use ExcelDna for UDF creation;
is it possible to make ExcelDna load into existing AppDomain, so I can
share data?

[Govert van Drimmelen]

No.

Each Excel-DNA creates its own AppDomain which are shared by all
aspects of the add-in - functions and macros, ribbons and custom task
panes and RTD servers. In theory it would be possible to control the
AppDomain used, but it would involved fairly serious changes to the
unmanaged loader portion of Excel-DNA.

(It seems most Excel-DNA users stop using VSTO fairly quickly.)

-Govert

[John Doah]

At this moment, I'm only considering possibility to use Excel-Dna, and
idea to rewrite the whole add-in right now doesn't look very appealing
to me :)

[Govert van Drimmelen]

OK.
Then it's probably not viable for you to make a custom version of
Excel-DNA, and you'll have to deal with different AppDomains.

For cross-AppDomain communication you'd probably set up .NET Remoting
with some MarshalByRefObject classes.

-Govert

[John Doah]

Could you explain about this custom loader?

[Govert van Drimmelen]

I just meant that it's probably not viable for you to make a custom
version of Excel-DNA (which you could do in theory since it's open-
source).

-G

[pfernie]

I have some custom edits on the most recent RC of Excel-DNA that adds
a new parameter "UseDefaultDomain" to the .dna file to allow loading
into the default AppDomain instead of an AppDomain per-xll. My
particular need is that I have a 3rd party managed dll that violates
the GC handle across appdomains issue (http://www.lenholgate.com/blog/
2009/07/error-cannot-pass-a-gchandle-across-appdomains.html for more
details). In order to use this API in our use case, I had to add this
functionality. Honestly, there are a lot of downsides to this
approach, but it is the only approach that works with our particular
needs. In particular, I find it is necessary to register
ExcelDna.Integration.dll to the GAC or place it alongside EXCEL.EXE;
otherwise binding context issues prevent proper loading of the other
DLLs in our projects. I've contacted our 3rd part vendor to try and
have them update their API so we don't have to do this, but our
current solution "works." Again, not idea, but, still, I'd be happy to
contribute these edits back if there were interest. I haven't offered
up these patches in the past as I think it's a little counter to the
spirit of the excellent engineering in Excel-DNA.

-Patrick

[Govert van Drimmelen]

Hi Patrick,

Given what you know, do you think I should add the option in Excel-DNA
to load into the default AppDomain?
ProblematicUnsupportedLoadIntoDefaultAppDomain="true".

If so, would you like to contribute your patches?

-Govert

[pfernie]

Govert,

I've just uploaded patch 9689 (this is my first time collaborating via
codeplex, so hopefully this was correct). I've provided a diff on
ExcelDnaLoader.cpp; as you can see, it's actually quite
straightforward (it piggy-backs on the HPC logic to short circuit the
creation of the isolated AppDomain). It creates a new attribute
"UseDefaultDomain" that can be specified in the .dna file (although,
given how much I dislike the spirit of this patch, perhaps your longer
name is better ;) ). As to whether I think this is a worthwhile
contribution: Frankly, I hated even having to do this, but the simple
truth was there was no alternate way to deal with the 3rd party
library we rely on (if a managed/unmanaged guru has any suggestions on
other means of working around the GC handle-across-appdomains issue in
a 3rd party lib, I'd love to hear them). So, there is definitely a use
case for it, but I would probably document it as being a method of
last resort. For example, this approach actually interferes with some
other in-house add-ins we have written (not on ExcelDNA) that also
tries to do its own custom loading. This has to do with the fact both
add-ins install their own assembly resolution methods in the default
app domain, so whichever gets there "first" ends up trying to resolve
assemblies for the other, but they live in different filepaths and
things break for one of them. Arguably, both should remove their
assembly resolution routines when they are done initializing, but I
suspect this will cause any late-binding assemblies to fail to load
properly. Since we had been intending to port our existing add-ins to
ExcelDNA anyway, I went ahead and did that sooner rather than later to
avoid this issue. But, it's definitely a potential issue.

Also, as you will note from the comment ~l.508 of the patched
ExcelDnaLoader.cpp, I toggled the forceFromBytes flag in the call to
LoadLoaderIntoAppDomain, which may break the HPC codepath (I haven't
tested this). This may be a bug; the code works as-is in our case.

[Govert van Drimmelen]

Hi Patrick,

Thank you!
I will have a look and will think about it, keeping your reservations
in mind.

Regards,
Govert

[German Velez]

Hi there. After reading a few articles, I cannot figure out the best course of action. I created an XLL for a project dealing with a set of Workbooks. Since they are part of a suite, I decided to create an add-in that contains the common functions and data sets but also include classes for each individual workbook. But as one would expect, the size of the XLL is growing (6M so far). Since these workbooks can be used in a suite as well as individually, I wonder if it would be better to create separate XLLs, a main Add-In (common functions and data sets), and one for each of the workbooks so they can be loaded for/by the individual workbook.  However, I am struggling with notion of having to communicate between the main Add-In and the individual one. Right now the communication is great (all contained within the same XLL) but breaking them apart will require marshaling and other good stuff that I am not too familiar with. 

 

Any ideas or experiences out there on the best course of action?

[Caio Proiete]

Hello German,

Are you experiencing any issues already with having an add-in with 6 MB?

Just trying to understand why do you see the need to split into multiple add-ins.

Also, is this add-in deployed in a enterprise environment (if it is, you might consider not packing it into XLL at all).

--

Caio Proiete

http://caioproiete.net

On Fri, Oct 17, 2014 at 1:03 PM, German Velez <german...@gmail.com> wrote:

Hi there. After reading a few articles, I cannot figure out the best course of action. I created an XLL for a project dealing with a set of Workbooks. Since they are part of a suite, I decided to create an add-in that contains the common functions and data sets but also include classes for each individual workbook. But as one would expect, the size of the XLL is growing (6M so far). Since these workbooks can be used in a suite as well as individually, I wonder if it would be better to create separate XLLs, a main Add-In (common functions and data sets), and one for each of the workbooks so they can be loaded for/by the individual workbook.  However, I am struggling with notion of having to communicate between the main Add-In and the individual one. Right now the communication is great (all contained within the same XLL) but breaking them apart will require marshaling and other good stuff that I am not too familiar with. 

 

Any ideas or experiences out there on the best course of action?

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To post to this group, send email to exce...@googlegroups.com.
Visit this group at http://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.