1

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?

Community
  • 1
  • 1
Modan
  • 775
  • 4
  • 14
  • In this case, removing the reference to the tlb file, and then adding it again solved the problem. I am still interested to know what I could have looked at help diagnose the problem, even though stabbing around blindly I eventually found the solution – Modan Aug 28 '09 at 14:45
  • I'm having a similar problem, but in creating an instance of a native VBA class, so there's no reference to add/remove (see here: http://stackoverflow.com/questions/2677091/automating-excel-through-the-pia-makes-vba-go-squiffy) - did you get any further in diagnosing this, and if so any suggestions? Thanks! – Jon Artus Apr 23 '10 at 13:08
  • @Modan: you can answer your own question and then accept your own answer to signal that you have found what you are looking for. – adamleerich Sep 15 '11 at 05:05

2 Answers2

1

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.

srdjan.veljkovic
  • 2,468
  • 16
  • 24
0

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.

Modan
  • 775
  • 4
  • 14
  • 1
    I would check the various GUIDs for the types and library and all the interfaces, look at the Wrong.Type and Foo.Bar types in particular and their interfaces. – Arafangion Aug 07 '13 at 23:48