Bibliothèques C++ non gérées - différences entre VS2005 et VS2008?

Question

Je vais commencer par dire que je suis un programmeur C# qui a hérité d'un code horrible sans documentation. J'ai une bibliothèque C++ non managée enveloppée avec du code managé qui a bien fonctionné dans VS2003 avec .Net 1.1 Framework. J'essaie de l'améliorer au moins .Net 2.0.

J'ai la bibliothèque C++ non gérée qui a été compilée avec "MSVC 8.x" (donc équivalente à VS 2005, je suppose). J'ai essayé de tout migrer vers VS2008 et j'ai encore quelques problèmes avec cette bibliothèque à l'exécution.

Ma question est la suivante: cette bibliothèque devrait-elle fonctionner avec VS2008? Ou devrais-je développer dans VS2005 si la bibliothèque a été compilée avec VC8.x?

Toutes les pensées seraient grandement appréciées. Merci!

Answer 1

Cela devrait fonctionner, je suppose que vous avez des problèmes avec votre marshalling. Il s'agit probablement de choses qui ont été déclarées incorrectement pour PInvoking qui a réussi à fonctionner dans .NET 1.1 mais pas dans les versions ultérieures.

Vous ne dites pas quel genre de problèmes vous rencontrez au moment de l'exécution, ni comment vous accédez à votre bibliothèque. Par exemple, compilez-vous votre bibliothèque avec votre projet? Si oui, pouvez-vous activer le débogage non géré dans votre projet C# et entrer dans le code avec lequel vous rencontrez des problèmes? Comment appelez-vous le code non managé? Est-ce par PInvoke, ou avez-vous des wrappers C++ gérés? Dans mon expérience, la meilleure solution pour l'appel à une bibliothèque non gérée héritée est d'ajouter une bibliothèque wrapper managée pour votre bibliothèque héritée écrite en C++ managé. De cette façon, vous présentez une interface gérée pour votre bibliothèque pour tous les langages .NET à consommer et vous n'avez pas à vous préoccuper de faire corriger vos signatures PInvoke.

Votre projet devrait ressembler à ceci.

C# Application -> Gérer C++ Wrapper DLL -> DLL héritage

Answer 2

Il peut dépendre que d'autre la lib repose sur. Par exemple, si vous utilisez la STL sur les interfaces de la bibliothèque, ce serait une mauvaise idée de compiler la bibliothèque avec une version différente du client. Cependant, si la bibliothèque présente une interface de fonction de style C simple, vous ne devriez pas avoir de problèmes.

Si vous avez le code source de la bibliothèque, je vous recommande d'essayer de le porter sur VS2008. En général, il est beaucoup moins compliqué à long terme d'avoir tout dans le même environnement de développement. Comment encapsulez-vous la bibliothèque non gérée ... probablement en utilisant des extensions managées pour C++ si elle date de VS2003. Ceci est maintenant obsolète et a été remplacé par C++/CLI à partir de VS2005. Alors que les nouveaux compilateurs supportent un commutateur/clr: oldSyntax pour toujours compiler l'ancien code, il y a certainement des problèmes avec celui-ci. Nous avons un ancien code qui ne compilera pas sur VS2005 (8) en utilisant ce commutateur.

Answer 3

--Rob Prouse:
L'encapsuleur utilise la gestion C++, pas PInvoke. Le wrapper est compilé dans une DLL qui est ensuite utilisée par une autre application (comme vous l'avez illustré).

Le code existant génère des objets graphiques. Lorsque j'essaie d'obtenir le handle d'une image, j'obtiens une exception null à la place. Le débogueur ne me laisse pas aller plus loin dans le code pour comprendre pourquoi. Tout le reste semble fonctionner correctement - les autres objets de données nécessaires pour créer l'image existent et semblent être corrects. (Désolé, je sais que c'est encore une description plutôt vague.

- Walker Walker:
Je n'ai malheureusement pas le code source. Je ne suis pas sûr de "l'utilisation de la liste STL sur les interfaces de la bibliothèque". Est-ce que les graphiques relèvent de cette catégorie?

J'ai été en mesure d'exécuter mon application en utilisant le commutateur/clr: oldSyntax, mais c'est là que j'obtiens les poignées nulles des images. J'ai essayé de mettre toutes les modifications pour qu'elle soit compilée avec/clr, mais j'ai continué à recevoir des erreurs de liens que je n'ai pas pu résoudre. (L'éditeur de liens ne cessait de se plaindre de ne pas pouvoir trouver les fichiers même si ces fichiers se trouvaient dans le dossier où il se trouvait.)