Calling external libraries from the code

[Sergey Zhilyakov]

Hi,

I use Excel-Dna to expose my C# code to XLL.

here is an example of code:

=====================
using SomeExternalLibrary;

public class Class1
{
public static double SomeMethod()
{
SomeExternalClass c = new SomeExternalClass();

return c.GetDouble();
}
}
====================

When I try to use this UDF from Excel, Excel crashes (it doesn't
return "#VALUE !', it chashes!). The funciton works fine if I use the
following code, though:

public static double SomeMethod()
{
return -1;
}

As I understood the problem is with calling external classes/
libraries.

Please, advise how to fix the problem.

the DNA file looks like this:

<DnaLibrary>
<ExternalLibrary Path="MyCSharpDLL.dll" />
</DnaLibrary>

Also I tried to use the 'Reference' statement in the DNA file, but it
didn't help:

<DnaLibrary>
<Reference Name="SomeExternalLibrary" />
<Reference Path="C:\SomeExternalLibrary.dll" />
<ExternalLibrary Path="MyCSharpDLL.dll" />
</DnaLibrary>

Thanks in advance.

[SebastianDotNet]

put a try catch in the method and see if an exception was thrown (dont
prompt a message box in the catch handler, log to a text file!)
looks like a reference problem(BadImageFormatException)

sebastian

[Sergey Zhilyakov]

Thanks for the response, Sebastian.

I have tried to put a try/catch, but it didn't help. Excel crashes.

Actually I noticed the following interesting things:
1. The external assembly I use is protected with .Net Reactor. If I
use protected assembly, Excel crashes. If I use unprotected assembly,
all works fine;
2. The external assembly I use implements Excel Automation Addin and
can be used from Excel independently. If I enable this addin in Excel
(in Excel 2003: Tools -> Add-ins -> Automation), Excel crashes when I
try to call my XLL function (even if I use unprotected assembly). But
if I disable this addin, all works fine.



Sergey.

On Aug 16, 9:16 pm, SebastianDotNet <supermicrosch...@gmail.com>
wrote:

[Govert van Drimmelen]

Hi Sergey,

For my simple test, there is no problem executing code from a
dependent assembly which sits next to my .dll and .xll.

I would not expect the missing reference to cause an error that
crashes Excel (unless you have marked your function as
IsExceptionSafe=true and it throws an exception).

If you indeed have a scenario that crashes Excel, I'd certainly like
to have a closer look.

I don't think the <Reference /> entries are used in the usual runtime
scenario. They are used in two cases:
1. compiling code at runtime from inside the .dna file.
2. To determine which dependencies should be packed by the packing
tool.

So it seems the <Reference> won't help you in the current problem.

Sebastian is right that a number of things might be wrong with the
assembly loading, throwing some exception, but these should not crash
Excel.
Catching and printing the exception details could help debug. I can
think of issues like:
1. You are running under .NET 2.0 but the dependent assembly
target .NET 4.0 (add a <DnaLibrary RuntimeVersion="v4.0"> in your .dna
file).
2. You are loading a mixed-mode assembly built for .NET 2.0 into
a .NET 4.0 environment (add some entry in the excel.exe.config).
3. You are loading a 32-bit assembly into a 64-bit process (Excel 2010
64-bit).
4. The assembly you are loading is damaged or has other dependencies
that are not present.

-Govert




On Aug 16, 7:16 pm, SebastianDotNet <supermicrosch...@gmail.com>
wrote:

[Govert van Drimmelen]

From what you write it sounds like a .NET reactor problem (I think
they interweave some native code, so all .NET safety bets are off) .

I'd suggest you contact them to debug the crash - giving them your
code and the Excel-DNA source code.

If they want to send me their source code, I'd be happy to debug the
problem too ;-)

-Govert

[Sergey Zhilyakov]

Hi Govert, thanks for the reply.

I have configured .Net Reactor, so now the protected assembly works
fine. The problem was with the 'NecroBit' feature that allows to
protect the assembly by replacing the CIL code within methods with
encrypted code.

The second problem is still actual, though. As I wrote earlier, Excel
crashes when I call my XLL function and the assembly I use is
registered as Automation Addin. If it is not registered, all works
fine.

I tried to put try/catch into the method and set the IsExceptionSafe
field to true, but it didn't help. The method is not called at all.

Have you any idea why is this so?

I use .Net Framework 3.5 anywhere. The <Reference /> is not used
anymore.

Sergey.

[Govert van Drimmelen]

Hi Sergey,

If you set IsExceptionSafe=true, then Excel should crash when
unhandled exceptions are thrown - this is by design.
IsExceptionSafe=true means that your function will never throw an
unhandled exception. It allows some performance optimization by Excel-
DNA, but is a feature best ignored.

However, you say the Excel crash seems to happen without your function
ever being called. I'd certainly like to understand this case better.

If you could make a simple Automation Add-In where Excel crashes when
it is used with Excel-DNA, I'd be happy to have a look.
You can send an example to me by e-mail, or by attaching to a message
on this list.

-Govert

[Ronan Mouquet]

Hi Govert,

About IsExceptionSafe=true :
"It allows some performance optimization by Excel-DNA, but is a feature best ignored."

Can you tell us more ?
I am sure that every exceptions are handled while calling to any UDF from my addin. Would the performance gain be relevant ?

Thanks
Ron

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to exceldna+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/exceldna?hl=en.

[Govert van Drimmelen]

Hi Ron,

There are two performance-relevant differences between the default
marshaling and the dangerous IsExceptionSafe=true setting:
1. By default the function call is wrapped in an exception handler.
2. By default the return type is registered as 'object' and the
returned value is boxed, so value types like double are returned as
object (this is to allow the special #VALUE value to be returned when
an exception is handled.)

I suspect only case 2. make a measurable difference - entering a 'try'
is very light-weight.
So you could try to measure the difference on a function that returns
'double'.

I'm still considering removing this option in future - I think it
looks pretty bad when your add-in crashes Excel...
And it's pretty hard to implement a function that is both:
1. simple enough for the boxing and try-catch overhead to be
noticeable, and
2. complicated enough not to be a trivial Excel formula.

Any feedback from your experiments would be welcome.

-Govert

[Ronan Mouquet]

Ok, my code does something similar : each call is wrapped in an exception handler that returns an object (the main idea is to return a string if there is an error). So this option has no interest for me.
To be honest, the performance issue given by boxing/unboxing the result should be ridiculous according to the calculation time of each function.
I agree with your considerations about removing that option.

Ron