Using default App Domain for ExcelDNA

[Matthew Darnall]

Hi,

I wanted to start using ExcelDna to replace some old addins, but I noticed that every ExcelDNA addin creates its own App Domain.  This causes a lot of memory bloat for me, since I have 15 other libraries that are loaded into the process, and if I call one of the libraries from ExcelDNA it reloads the library (and duplicates the associated data).  It looks like when ExcelDna is used outside of an excel process, it doesn't use a separate domain (see IsRunningOnCluster function below). My plan is to just set that to TRUE all the time for my use.  Is there any known issues with doing this? It seems like this would be a good configuration option to have when building an addin. It would also be nice to directly reference some of the dlls like ExcelDna.Integration instead of loading them from resources.

https://github.com/Excel-DNA/ExcelDna/blob/2aa1bd9afaf76084c1d59e2330584edddb888eb1/Source/ExcelDna/ExcelDnaLoader.cpp#L848

Regards,

Matt

[Govert van Drimmelen]

Hi Matt,

Excel-DNA is designed so that independent add-ins can live side-by-side.

AppDomain isolation is the main way this is achieved, and seems to have worked well so far.

The fact the add-ins do not share an AppDomain is baked into the Excel-DNA architecture in various ways, e.g. 

- liberal use of statics without care about the exact assembly identities

- managing AppDomain assembly resolution for implementing packed assemblies

I can't tell how well a version of Excel-DNA would work where everything is loaded into the default AppDomain.

The special case of running in an Excel compute cluster is one where the isolation is assured by the compute cluster host.

I have no knowledge of this feature being used anywhere.

It might be OK in the special case where you have full control over the Excel process and you're sure no other add-ins are loaded.

I would certainly not like to consider removing that AppDomain isolation as a possible change for Excel-DNA at this stage.

For sharing data between the AppDomains you might consider the standard remoting mechanism, or something like a hidden UDF that can be called from one side to the other, to get access to the shared memory items.

I'm not sure whether these are reasonable options in your environment.

-Govert

[Matthew Darnall]

Thanks for the reply. For making many self contained addins, the AppDomain approach is great, at my company we used it already in some isolated helper tools.. 

In our main "workhorse" spreadsheets, we load a lot of .NET dlls for models and times series data manipulation. Currently they are called through autogenerated C++ addins by reading the exported COM classes from our .NET dlls.  ExcelDna is a cleaner way of defining the Excel interface, but the separate AppDomain means we either load the assemblies multiple times in the same process or have to marshal data across the domains. We already manage the assembly resolution for our spreadsheets, so I don't think it is a big concern for us

I will try running a bit with the AppDomain isolation off, initial tests seem to show it works fine.

BTW, when you say "liberal use of statics without care about the exact assembly identities", do you mean you use static variables to store properties of the current addin, and this could be an issue if you have multiple addins in the same domain?

[C. Augusto Proiete]

An alternative approach that would give you the single AppDomain you're looking for, but with less risk (or more controlled risk) would be to deploy a single Excel-DNA add-in (host) to your users that dynamically load the assemblies of all other add-ins, and bootstrap them yourself.

That way, your host add-in will be isolated in its own AppDomain, and all of your other assemblies will share the same AppDomain.

You can use the Registration extension to register functions exposed by your different assemblies at run-time. If you use Ribbons or other COM features, you would also have to load these yourself at run-time as well.

Cheers,
C. Augusto Proiete
https://augustoproiete.net

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/0ba6561f-b39e-4ef2-9f70-379f6a21087ao%40googlegroups.com.