Mauvais objet retourné à partir de COM Callable Wrapper

Je viens de faire une mise à jour à une DLL qui est appelée à partir de VBA dans Powerpoint. Tout le développement s'est bien passé, mais quand j'ai essayé de déployer sur une autre machine d'utilisateurs j'ai un problème que je n'ai aucune idée comment déboguer.Mauvais objet retourné à partir de COM Callable Wrapper

Que se passe-t-il lorsque l'objet .Net est créé dans le VBA, la référence qui est retournée est le mauvais objet, donc la ligne suivante échoue avec la méthode non trouvée.

Dim myObj As Foo.Bar 

Public Sub RefreshData() 

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

La dernière ligne échoue avec Erreur d'exécution « 438 » objet ne prend pas en charge cette propriété ou méthode qui est causée par le fait que myObj est en quelque sorte de type « Wrong.Type » au lieu de " Foo.Bar ". "Wrong.Type" est également dans l'assembly, donc je suppose que quelque chose ne va pas avec la bibliothèque de type, mais j'ai essayé de régénérer (en utilisant regasm/codebase/tlb MyLib.dll), et cela n'a pas aidé .

Je ne sais pas comment diagnostiquer cela davantage. Espérons que quelqu'un là-bas peut énumérer quelques étapes sur la façon de diagnostiquer ce genre de problème?

Source

2009-08-28 Modan

Dans ce cas, supprimer la référence au fichier tlb, puis l'ajouter à nouveau a résolu le problème. Je suis toujours intéressé de savoir ce que j'aurais pu regarder pour aider à diagnostiquer le problème, même si poignarder aveuglément j'ai finalement trouvé la solution – Modan

J'ai un problème similaire, mais en créant une instance d'une classe native VBA, donc il n'y a pas référence à ajouter/supprimer (voir ici: http://stackoverflow.com/questions/2677091/automating-excel-through-the-pia-makes-vba-go-squiffy) - avez-vous eu plus de diagnostic à ce sujet, et Si oui, des suggestions? Merci! –

@Modan: vous pouvez répondre à votre propre question et ensuite accepter votre propre réponse pour signaler que vous avez trouvé ce que vous cherchez. – adamleerich

Dans ce cas, la suppression de la référence au fichier TLB, puis l'ajouter à nouveau résolu le problème

Malheureusement, je n'ai trouvé une solution générale, ou une explication du comportement.

Source

2011-10-14 13:32:40 Modan

Je voudrais vérifier les différents GUID pour les types et la bibliothèque et toutes les interfaces, regardez les types Wrong.Type et Foo.Bar en particulier et leurs interfaces. – Arafangion

Il peut s'agir du problème des GUID générés automatiquement (classe, interface, bibliothèque de types) - lorsque vous avez modifié la DLL, les GUID ont été modifiés. Comme l'ancien TLB utilisait les anciens GUID, en les référençant, vous avez associé ces anciens GUID aux noms de type, de sorte que le code n'a pas fonctionné avec les nouveaux GUID. La plupart du code VB (6 et .NET) que j'ai rencontré a ce problème, donc si votre DLL est écrite en VB, c'est probablement elle (et votre travail supporte cette théorie). Si tel est le problème, une solution générale consiste à définir explicitement les GUID, ce qui est un peu gênant si vous avez beaucoup de types, puisque vous êtes supposé changer les GUID à mesure que vos version (s) changent, et vous Je vais devoir le faire manuellement.

Source

2015-01-29 01:39:12

Mauvais objet retourné à partir de COM Callable Wrapper

Répondre

Questions connexes