CODEWITHSUNDEEP
.netcominteropvbscript
Cheeso
Cheeso

Reputation: 192417

How to debug "Wrong number of arguments or invalid property assignment" vbscript .NET interop

I have a .NET assembly, written in C#. It's marked ComVisible, has a guid, is signed, regasm'd (/codebase). I did not formally define an interface for the COM part.

I use this assembly via VBscript.

There's an overloaded method - one form takes a single string argument, and the second takes two strings. Both return another .NET type from the same assembly. I call it like so: 

set foo = WScript.CreateObject("Prog.Id")
' the following succeeds
set bar = foo.Method1("string")
' the following fails
set baz = foo.Method1("string1", "string2")

The first call to Method1 succeeds. The second one fails with "Wrong number of arguments or invalid property assignment".

How can I debug this?

In testing, if I define a brain-dead simple .NET class with overloads like this, I can call it from VBScript, no problem. There's something else about my "real" assembly that is causing this to fail. How do I figure out what it is?

Upvotes: 3

Views: 7017

Answers (2)

Cheeso
Cheeso

Reputation: 192417

More on this: While COM does not "allow" overloading of methods, the CCW generated on a .NET class that uses overloaded methods will expose all overloads. In other words, a COM-based environment like VBScript will be able to access all overloads on a .NET class. Some of the overloads get mangled names.

Let's suppose there is a class that exposes three methods with the name Extract(). The first overload is named Extract(). The others are named with suffixes _2, and _3.

What determines which overload is "the first" overload and which get the mangled names? I don't know. It may be the order of appearance of the methods in the assembly. But what determines that order? Here again, I don't know.

The only way I know to certainly determine which overload is which, is to view the CCW in the OleView too.

Upvotes: 2

Andreas F
Andreas F

Reputation: 404

I'm not sure if this is truly the case, but it appears that COM does not allow overloading of methods: here or here

The first links seems to suggest that there may be a way around this (with an explicit interface definition and attributes perhaps?), but I doubt it.

You could also check the resulting type library with OleView.exe to see what your two methods look like to COM clients after using tlbexp on your assembly.

Upvotes: 4

Related Questions