Objeto errado retornado do invólucro chamável
Pergunta
Acabei de fazer uma atualização para uma DLL chamada do VBA no PowerPoint. Todo o desenvolvimento correu bem, mas quando tentei implantar em outra máquina de usuários, tenho um problema que não tenho idéia de como depurar.
O que acontece é que, quando o objeto .NET é criado no VBA, a referência retornada é para o objeto errado, para que a próxima linha falhe com o método não encontrado.
Dim myObj As Foo.Bar
Public Sub RefreshData()
//'instantiate object
Set myObj = New Foo.Bar
//'call a method
myObj.HelloWorld
A última linha falha com Erro em tempo de execução '438' Objeto não suporta esta propriedade ou método O que é causado pelo fato de MyObj ser de alguma forma do tipo "errado.type" em vez de "foo.bar".
"Whry.Type" também está na assembléia, então presumo que algo esteja dando errado com a biblioteca de tipos, mas tentei regenerar (usando o ReGasm /CodeBase /TLB mylib.dll), e isso não ajudou.
Não sei como diagnosticar mais isso. Espero que alguém aí possa listar algumas etapas sobre como diagnosticar esse tipo de problema?
Solução 2
Nesse caso, remover a referência ao arquivo TLB e depois adicioná -lo novamente resolveu o problema
Infelizmente, nunca encontrei uma solução geral ou uma explicação para o comportamento.
Outras dicas
Pode ser o problema dos GUIDs gerados automaticamente (classe, interface, biblioteca de tipos) - quando você alterou a DLL, o GUIDS foi alterado. Como o antigo TLB usou GUIDs antigos, ao referenciar, você associou esses GUIDs antigos a nomes de tipo, para que o código não tenha funcionado com os novos GUIDs. A maioria do código VB (6 e .NET) que encontrei tem esse problema; portanto, se a sua DLL estiver escrita em VB, provavelmente é (e seu trabalho em torno de apoiar essa teoria).
Se esse é o problema, uma solução geral é definir o GUIDS explicitamente, o que é um pouco irritante se você tiver muitos tipos, já que você deve mudar o GUIDS conforme sua (s) mudança (s) e você terá que faça isso manualmente.