Ce qui peut provoquer l'erreur d'exécution Vb6 430

Question

J'ai une DLL COM écrite en vb6. Lorsque j'essaie de créer un nouvel objet d'un module de classe à partir de cette DLL, j'obtiens une erreur de minuteur d'exécution 430: La classe ne prend pas en charge l'automatisation ou ne prend pas en charge l'interface attendue. Ce qui est intéressant, c'est que cela n'arrive que de l'extérieur de l'EDI, quand je débogue depuis l'EDI, aucune erreur n'est levée et le nouvel objet de la classe est créé avec succès. Quelle peut être la cause?

En général, j'obtiens parfois ce genre d'erreurs dans les DLL COM. Quel est le meilleur moyen de déboguer les problèmes COM? Comment puis-je connaître le chemin de la DLL utilisée lorsqu'un programme est en cours d'exécution?

Answer 1

Si ce projet est entièrement en VB6. La cause probable de ceci est que l'EXE a une copie du DLL binaire dans son répertoire. Quand vous tirez, il utilise cette copie au lieu de la copie compilée. Lorsque vous ajoutez des méthodes ou des classes EXE devient incompatible avec l'ancienne DLL. Si vous avez corrigé un bogue ou simplement travaillé avec le code interne, EXE s'exécutera mais utilisera l'ancienne DLL.

Définissez votre DLL sur Compatibilité binaire. Assurez-vous d'avoir un répertoire compatible. Mettez la DLL de la dernière version ici. Pointez la compatibilité binaire vers cette DLL. Assurez-vous que votre EXE compile dans son répertoire de projet. Exécutez le fichier EXE à partir de son répertoire de projet. De cette façon, il utilisera la DLL que vous avez compilée. Vous devez écrire un utilitaire pour pouvoir compiler chaque projet séparément. Testez votre configuration à l'aide de Virtual PC ou d'un autre ordinateur.

Toutes ces étapes permettront d'éviter DLL Hell. Mon propre projet a deux douzaines de projets ActiveX en 6 couches. Quand j'ai adopté ce qui précède, mes problèmes d'enfer DLL ont chuté à presque rien.

Answer 2

Il s'agit presque certainement d'un problème de versionnement, parfois appelé "DLL hell". Le contexte est que le monde .NET est explicitement conçu pour permettre aux interfaces d'évoluer tout en conservant le même nom. Mais dans le monde COM, les interfaces sont considérées comme immuables. Lorsque vous travaillez dans l'EDI, Visual Studio crée un nouveau wrapper COM Interop pour la DLL COM chaque fois que vous exécutez votre solution. Mais à moins de libérer et de remplacer la totalité de votre solution à chaque fois, y compris un tout nouveau wrapper COM Interop, vous allez rencontrer un problème de version, où le code .NET attend une interface COM mais en voit une autre.

EDIT: Pour une raison quelconque, j'ai supposé que vous essayez d'utiliser le composant COM à partir d'un composant .NET. Si la solution complète est en réalité VB6, la solution de M. Conley est l'approche recommandée. Here's a good link qui traite du problème.

Answer 3

Lire sur binaire vs projet compatible.

Si vous avez une DLL partagée, vous devez faire attention et utiliser le binaire de manière compatible. De cette façon, VB6 conservera la même signature/interface COM entre les versions. Vous devez avoir une copie de la DLL libérée pour comparer avec VB6 - j'ai habituellement un dossier séparé pour les binaires libérés. La restriction avec la compatibilité binaire est que vous ne pouvez pas supprimer les propriétés publiques ou les méthodes et vous ne pouvez pas modifier leurs signatures. Vous pouvez ajouter de nouvelles propriétés et méthodes.

Utilisez la compatibilité de projet si vous devez apporter des modifications importantes (comme la suppression de méthodes publiques anciennes). Cependant, si vous le faites, vous devrez recompiler toutes les autres applications qui utilisent la DLL partagée.