Étranges problèmes de construction de VB6 (liés à nlog)

Question

Cela, je pense, est lié à mon utilisation de l'API C ++ de nlog (et ma question sur le forum nlog est ici ); Le but de ma question ici est d’obtenir une audience plus large sur mon problème et peut-être d’obtenir des idées plus générales sur l’échec de l’EDI VB6 à intégrer mon scénario particulier.

En résumé, le problème que je rencontre est que je ne parviens pas à créer des composants VB6 faisant référence à des composants C ++ non gérés ayant des appels à l'API C \ C ++ de nlog (définie dans NLogC.DLL). Les problèmes de construction ne surviennent pas pendant la compilation, mais bien quand le binaire est construit, ce qui me suggère qu'il s'agit d'un problème de type éditeur de liens. Je ne sais pas assez sur la façon dont les fichiers binaires VB6 sont générés pour le dire. Le fichier binaire VB6 est produit, mais il est corrompu et se bloque peu de temps après son appel.

Quelqu'un at-il déjà vécu une expérience similaire avec VB6 (ne doit pas nécessairement être lié à nlog ou à C ++)?

edit: Merci pour toutes les réponses à ce problème plutôt obscur. Toujours pas de progrès malheureusement; mes découvertes depuis que j'ai posté ceci:

1. "Ajuster" les options de compilation ne semble pas résoudre ce problème.
2. L'ajout d'une référence au composant C ++ activé par nlog à partir d'un projet VB6 "vide" ne le bloque pas et ne provoque pas d'étranges problèmes de construction. Donc, ce n'est pas un problème VB6 'natif', c'est peut-être un problème d'interaction entre nlog et les divers composants et bibliothèques tierces utilisées par d'autres composants référencés?
3. En ce qui concerne les conventions d'appel C ++: le composant C ++ activé par nlog est conforme à ces conventions et fonctionne bien lorsqu'il est référencé par VB6 tant qu'il ne fait aucun appel d'API nlog. Pas sûr que nlogc.DLL soit conforme à VB6, mais j'aurais pensé que cela importait peu, puisque les appels d'API sont passés à partir du composant C ++. VB6 ne devrait pas savoir ou se soucier de ce que le composant C ++ fait référence (c'est ce que je comprends le mieux ...)

edit2: Je dois également noter que le message d'erreur obtenu lors de la construction est le suivant: "Erreurs lors du chargement. Veuillez vous reporter à la section "xxx". pour plus de détails " ;. Lorsque j'ouvre le fichier journal, il ne contient que: "Impossible de charger le contrôle xxx". Il est intéressant de noter que toutes les références à ce contrôle particulier disparaissent de ce projet particulier, ce qui entraîne des erreurs de compilation si je tentais de reconstruire à nouveau.

Answer 1

Vous avez résolu le problème en utilisant l'interface COM de NLog (NLog.ComInterop.DLL) à partir de mon code C ++ non géré. Pas aussi facile à faire que l’API C \ C ++, mais au moins elle ne plante pas mes composants VB6.

Answer 2

J'essaierais de modifier certaines des options de compilation présentes dans le menu Projet , Propriétés du panneau Compiler . pour voir si elles donnent des indices supplémentaires sur ce qui ne va pas.

Par exemple, si vous compilez l'exécutable en code p plutôt qu'en code natif , il se bloque toujours au démarrage.

Answer 3

Quel message d'erreur recevez-vous lorsque vous exécutez votre binaire compilé?

Je doute que le compilateur / lieur soit le problème: les références de projet dans un projet VB6 ne sont pas liées dans l'exécutable final. Une référence de projet dans VB6 est en réalité une référence à une bibliothèque de types COM (qui peut ou non être incorporée dans un fichier .dll ou un autre type de fichier binaire). Les références de projets ont principalement deux objectifs:

1. L'EDI extrait les informations de type des bibliothèques de types référencées qu'il affiche ensuite dans le navigateur d'objets (et dans la liste déroulante d'Intellisense)

2. Au moment de la compilation, le compilateur extrait les informations de type stockées dans les bibliothèques référencées, y compris le CLSID de chaque classe que vous instanciez, et incorpore ces données à l'exécutable. Cela permet à votre exécutable de créer des instances de classes contenues dans les bibliothèques que vous avez référencées.

Notez que le fichier binaire compilé ne lie à aucun code des bibliothèques référencées et ne contient même pas les noms de fichiers des bibliothèques référencées. Le fichier exécutable final contient uniquement les informations CLSID et les autres types dont il a besoin pour instancier des objets COM au moment de l’exécution.

Il est beaucoup plus probable que le problème vienne de NLog ou de la façon dont vous l'appelez à partir de votre code plutôt que d'un problème rencontré dans le processus de compilation de VB6.

Answer 4

Si vous pensez que cela pourrait être un problème de l'éditeur de liens, cela devrait le bloquer de la même manière:

1. créer un nouveau projet standard (de tout type)
2. ajoutez un nouveau module et copiez-y les déclarations "déclare"
3. compiler

Si ça ne plante pas, c'est autre chose.

Answer 5

Cela aiderait à une description exacte de l'erreur ou à une capture d'écran de ce qui se passe.

Il convient de vérifier si la convention d’appel correcte a été définie pour NLogC.DLL ou la DLL C ++ que vous avez générée. Fondamentalement, vous ne pouvez pas modifier les noms de fonction de DLL ni utiliser quoi que ce soit d'autre que la convention d'appel STDCALL. Si la DLL C ++ n'a pas été créée avec ces deux éléments à l'esprit, elle ne fonctionnera pas avec VB6.

Article MSDN sur la convention d'appel.

Answer 6

" Impossible de charger le contrôle xxx " Les fichiers .oca créés à partir d'une version d'un fichier .ocx différente de celle actuellement utilisée peuvent être à l'origine d'erreurs. Si tel est le cas, il est utile de supprimer les fichiers .oca.