thanks for your reply. I use configuration files in a similar fashion, more precisely I use
where exePath = System.Reflection.Assembly.GetCallingAssembly().Location. The reason is that I want to use several configuration files. For example one configuration file that contains the configuration of nativ dll's to use for Linear Algebra operations (BLAS,
Lapack) etc., an other is used for more exotic
nativ dll's (Random number generators, optimization routines etc.). Finally a configuration file is needed for the configuration of the Excel interface.
The configuration files are linked to a specified Assembly, for example Dodoni.XLBasicComponents.dll.config, Dodoni.BasicLowLevelMathLibrary.dll.config etc. Especially the configuration file of the Excel interface should be independent of all other (for example
if one change the user interface). This makes sense in my eyes.
You are right that packed resources may not have a 'Location'. I just wunder why I get a valid Location for an other Assembly, i.e.
is valid. The Assembly Dodoni.BasicComponents is used in my ExcelAddIn. Moreover it is signed, but I do not know whether this is the reason why it works.
In this context I found a second strange behaviour in the case of packed xll only:
In some cases the static
constructor of my IExcelAddIn implementation will be called twice: Two Assemblies are used and loaded in the .dna file via externalLibrary Path=... Both of them contains an IExcelAddIn implementation. The second Assembly depends
on the first. The first contains a static event that allow the second Assembly to register specified Configuration forms etc. In the AutoOpen() method of the second Assembly I store a specified method in the static event property of the first Assembly, thus
the static constructor of the first Assembly will be called. After that the static constructor of the first Assembly will be called a second time and the event property is null.
Perhaps it helps if I move the event property to an other class that does not implement the IExcelAddIn interface, but I haven't tested it yet.
PS. Thank you very much! My library is not nearly as good as your exceldna project!