VB.Net dll functions not appearing in Excel

[dfarr...@gmail.com]

I am new to Excel-DNA and working through the Getting Started actions.  The sample AddThem function with code in the dna file works fine and when I open Excel and type =AddThem(2,5) I get the expected result of 7 and the function displays in the context help as I type.  I can build the example MultiplyThem dll using c# and it similarly behaves as expected.  However, when I build the dll using VB.Net I cannot get the function to appear in the context help as I type and I receive the #NAME? error in the cell.  I have used the steps discussed in the Patrick O'Beirne "VBA to VB.Net XLL add-ins with Excel-Dna" tutorial without success.  We have a bunch of VB6 function libraries deployed as dll's that need migration to .Net.  Development environment is Win7-64, VS 2010 and 32-bit Excel 2010.

Thanks for any suggestions.

[Govert van Drimmelen]

You need to check that your functions are inside a Public Module, or are marked as Shared in a Public Class.

If that still does not work, you can post some code that you expect to work, but doesn't.

-Govert

On 15 Nov 2014, at 0:34, "dfarr...@gmail.com" <dfarr...@gmail.com> wrote:

I am new to Excel-DNA and working through the Getting Started actions.  The sample AddThem function with code in the dna file works fine and when I open Excel and type =AddThem(2,5) I get the expected result of 7 and the function displays in the context help as I type.  I can build the example MultiplyThem dll using c# and it similarly behaves as expected.  However, when I build the dll using VB.Net I cannot get the function to appear in the context help as I type and I receive the #NAME? error in the cell.  I have used the steps discussed in the Patrick O'Beirne "VBA to VB.Net XLL add-ins with Excel-Dna" tutorial without success.  We have a bunch of VB6 function libraries deployed as dll's that need migration to .Net.  Development environment is Win7-64, VS 2010 and 32-bit Excel 2010.

Thanks for any suggestions.

--
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.

[Patrick O'Beirne]

DFarrell,

Please work through the example in "Stage 2: Compiling  a .DLL" and tell me where the first problem occurs.

Thanks
Patrick

On 15/11/2014 08:40, Govert van Drimmelen wrote:

[dfarr...@gmail.com]

I have worked through the Stage II compiling a dll.  The problem occurs when I try to use the functions in the dll.

A VB Class Library project named VBLib is created with a single Class1.vb file as follows:

Imports ExcelDna.Integration
Public Class FuncLib
    Public Shared Function MultiplyThem(ByRef x As Double, ByRef y As Double) As Double
        Return x * y
    End Function
End Class

and the TestFuncs.dna file is:

<DnaLibrary Language="VB" RuntimeVersion="v4.0">
  <ExternalLibrary Path="VBLib.dll" />
</DnaLibrary>

I have included the reference to ExcelDna.Integration within the project.

The code compiles and VBLib.dll is created.  ExcelDna.xll (V0.32) is copied and renamed to TestFuncs.xll.

Double-clicking the xll opens Excel and the macro prompt displays and is allowed.  I open a new workbook but the MultiplyThem function is unknown.

I have also tried in VS 2008 and with V0.30 with no difference.  I have also tried using Public Module without any success.

This is driving me crazy.

Dave.

[Patrick O'Beirne]

If you had ever got an error earlier in the dev process Excel may have disabled the addin for security reasons. Check "disabled addins" and re-enable it.

[dfarr...@gmail.com]

No disabled add-ins. I went back to the starting point, copied your code and command line compiled.  This time it ran.  I then command line compiled my code and it continued to fail.  I then started looking for differences finding that the ByRef keyword was the problem.  Now I can sleep.

Thanks for your help.
Dave.

[Patrick O'Beirne]

See Sharp eyes :-)
Thanks, Dave.