1

I'm using IKVM.NET in order to convert a Java library (signally, Strata) into a .NET library. Here are the steps I perform:

  1. I download the latest Strata release.
  2. I unzip all the JAR files contained into the lib folder of the archive to C:\Strata\, including the following auxiliary libraries:
    • commons-math3-3.6.1.jar
    • guava-26.0-jre.jar
    • joda-beans-2.4.0.jar
    • joda-convert-2.2.0.jar
    • slf4j-api-1.7.25.jar
  3. I generate a keyfile for the library I want to create using the command sn -k "C:\Strata\Strata.snk".
  4. Using the binary bytecode compiler of IKVM.NET, I convert the JAR files of Strata into a .NET library with the following command: ikvmc -out:"C:\Strata\Strata.dll" -keyfile:"C:\Strata\Strata.snk" -assembly:Strata -version:2.2.0 -fileversion:2.2.0 -target:library -platform:anycpu -recurse:"C:\Strata\*.jar".

Once the process described above is done, even if a few warnings concerning missing classes are shown, I obtain a working .NET wrapper of Strata. If I create a new Visual Studio project referencing the Strata.dll assembly, I'm capable of using its classes and methods without problems.

What I would really love to achieve is to make the wrapper work in Excel VBA macros, so that I can instantiate and use Strata classes in the subs, according to the contents of the sheets.

This is what I tried so far, but to no avail:

  1. I register all the IKVM.NET libraries and the Strata wrapper into the GAC as follows: gacutil /i "C:\IKVM\IKVM.*.dll", gacutil /i "C:\Strata\Strata.dll".
  2. I register the Strata wrapper as COM component and I create its types library as follows: regasm /codebase /tlb "C:\Strata\Strata.dll".

Now, when I open Excel and I go under Development > Visual Basic > Tools > References... I can see the TLB file of Strata (located at "C:\Strata\Strata.tlb") and I can add it to the current project. But as soon as I type something the window or I open the Objects Browser, Excel crashes without providing any meaningful information about what's going on.

I'm totally clueless about this issue.

Is my registration process correct? Do I have to register the IKVM.NET libraries too and create their type libraries? Should I include them into the Excel VBA project together with the Strata wrapper type libraries? Could the problem be caused by the fact that I'm using a x64 version of Excel and the wrapper has been compiled under AnyCPU? Do I need to edit the wrapper by adding a ComVisible attribute on every public class? May this problem be due to the fact that the wrapper contains weird method names like “\_Build01_\p”?

Tommaso Belluzzo
  • 23,232
  • 8
  • 74
  • 98
  • 1
    I've always added a ComVisible attribute for each public class, seems to work ok. Registration looks fine, but you can use the Register for COM interop option too (https://stackoverflow.com/questions/3534600/what-does-register-for-com-interop-actually-do). Try targeting x86 explicitly. I'm assuming you are using the unmanaged exports library, you added `[ComVisible(true), ClassInterface(ClassInterfaceType.AutoDual)]` attribute to the class? Might be helpful to see the code you are making into the dll. – Ryan Wildry Jan 29 '19 at 13:24
  • Dear Ryan, thanks for your reply. Unfortunately, I cannot use the "Register for COM Interop" option because I'm just producing a .NET library from JAR files without relying on a Visual Studio project and ad-hoc code. And this is the exact same reason I should programmatically edit the output library in order to add the ComVisible attributes, if needed. All I do is to create a .NET library from the JARs, using ikvmc, as described in the first part of my question. – Tommaso Belluzzo Jan 29 '19 at 14:13

1 Answers1

0

Rather than use IKVM.NET you can use Java directly to build an Excel add-in.

To build an Excel add-in in Java instead of having to use .NET, see https://exceljava.com.

There is even a Strata-Excel project that you might be interested in that wraps the Strata library in an Excel add-in: https://github.com/exceljava/strata-excel

I think you should find this much more convenient than converting the Java libraries to .NET.

Tony Roberts
  • 387
  • 1
  • 5