Exposing nested arrays to COM from .NET

Question

I have a method in .NET (C#) which returns string[][]. When using RegAsm or TlbExp (from the .NET 2.0 SDK) to create a COM type library for the containing assembly, I get the following warning:

WARNING: There is no marshaling support for nested arrays.

This warning results in the method in question not being exported into the generated type library. I've been told there's ways around this using Variant as the COM return type, and then casting/etc on the COM client side. For this particular assembly, the target client audience is VB6. But how do you actually do this on the .NET side?

Note: I have an existing legacy DLL (with its exported type library) where the return type is Variant, but this DLL (and the .tlb) is generated using pre-.NET legacy tools, so I can't use them.

Would it help at all if the assembly was written in VB.NET instead?

Answer 1

Even if you were to return an Object (which maps to a Variant in COM Interop), that doesn't solve your problem. VB will be able to "hold" onto it and "pass it around", but it won't be able to do anything with it.

Technically, there is no exact equivalent in VB for a string[][]. However, if your array is not "jagged" (that is, all the sub-arrays are the same length), you should be able to use a two-dimensional array as your return type. COM Interop should be able to translate that.

string [,] myReturnValue = new string[rowCount,colCount];

Whether your method formally returns an Object (which will look like a Variant to VB), or a string[,] (which will look like an Array of Strings in VB), is somewhat immaterial. The String array is a nicer return, but not a requirement.

If you array is jagged, then you are going to have to come up with a different method. For example, you could choose to make your return 2D array as big as the biggest of the sub-arrays, and then pass the length information in a separate [out] int[] parameter, so that VB can know which elements are used.

Answer 2

The equivalent of variant in C# is System.Object. So you might want to try to return the result cast to object and pick it back up on the other side as a variant.

VB doesn't have any facilities that C# lacks, so I doubt it would be better or easier if the .NET side was written in VB.