Question

I have just made an update to a dll that is called from VBA within Powerpoint. All development went fine, but when I tried to deploy on another users machine I get a problem that I have no idea how to debug.

What happens is that when the .Net object is created in the VBA, the reference that is returned is to the wrong object, so the next line fails with method not found.

Dim myObj As Foo.Bar

Public Sub RefreshData()

//'instantiate object
Set myObj = New Foo.Bar   
//'call a method
myObj.HelloWorld

The last line fails with Run-time error '438' Object doesn't support this property or method which is caused by the fact that myObj is somehow of type "Wrong.Type" instead of "Foo.Bar".

"Wrong.Type" is also in the assembly, so I assume something is going wrong with the type library, but I have tried regenerating (using regasm /codebase /tlb MyLib.dll), and this hasn't helped.

I don't know how to diagnose this any further. Hopefully someone out there can list some steps on how to diagnose this sort of problem?

Was it helpful?

Solution 2

In this case, removing the reference to the tlb file, and then adding it again solved the problem

Unfortunately, I never did find a general solution, or an explanation for the behaviour.

OTHER TIPS

It might the problem of automatically generated GUIDs (class, interface, type library) - when you changed the DLL, GUIDs changed. Since the old TLB used old GUIDs, by referencing it, you associated those old GUIDs with type names, so the code failed to work with the new GUIDs. Most VB (6 and .NET) code I encountered has this problem, so if your DLL is written in VB, it's probably it (and your work around supports this theory).

If that is the problem, a general solution is to set GUIDs explicitly, which is a little annoying if you have a lot of types, since you're supposed to change GUIDs as your version(s) change, and you'll have to do it manually.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top