Managed Est-il possible d'avoir:classe de base non géré avec la sous-classe
en utilisant SWIG ou de la colle C++/CLI?
Vous pouvez toujours écrire un encollage C++/CLI personnalisé pour envelopper les objets gérés dans des encapsuleurs non gérés ou des objets non gérés dans des encapsuleurs gérés. Si vous ne voulez pas suivre cette approche, vous pouvez également utiliser COM et "COM/.NET interop". En d'autres termes, vous pouvez déclarer votre interface dans un fichier COM .idl; Une fois cela fait, vous devriez pouvoir consommer (et implémenter) l'interface dans le code non géré et managé (C++, C++/CLI, C#, etc.). En C++ (non géré ou non), vous pouvez #importer l'idl ou #include le (s) fichier (s) en-tête que votre compilateur de choix génère après avoir "compilé" l'idl via midl.exe. Pour C#, vous pouvez écrire certaines API managées en C++/CLI pour envelopper les interfaces COM ou vous pouvez utiliser tlbimp.exe pour générer automatiquement un assembly managé à partir de la bibliothèque de type COM (.tlb) que midl génère. Cet "assembly interop" peut être directement référencé par tout ancien assembly géré régulier.
(Cela pourrait tout sembler un peu cryptique ou magique si vous n'êtes pas familier avec COM ou COM/.NET Interop;. Pour plus d'informations sur la façon d'exposer les composants COM à .NET, here's some background material on MSDN pour vous commencer)
Une fois que vous avez exposé avec succès les composants COM en question à .NET, l'implémentation de l'une des interfaces COM exportées dans .NET devrait être aussi simple que de définir une nouvelle classe en C# ou C++/CLI qui hérite du interface en question.
En ce qui concerne l'exigence n ° 3 ... la façon dont vous y parvenez dépend vraiment du problème plus large que vous essayez de résoudre. Une fois que vous avez transmis une référence à l'objet géré (qui implémente l'interface COM) en code natif, ce code peut vraiment utiliser l'objet comme s'il s'agissait d'un objet COM natif; il peut - pour la plupart - rester parfaitement inconscient du langage utilisé pour implémenter les interfaces COM requises. Si vous fournissez des détails supplémentaires sur le contexte de votre problème, nous serons peut-être en mesure de fournir des pointeurs supplémentaires sur la façon d'y parvenir.
SWIG est l'outil que vous voulez utiliser ici. Spécifiquement, utilisez SWIG directors. Dans la documentation en ligne:
La fonctionnalité directeurs SWIG ajoute un code supplémentaire aux classes de proxy C# générées qui permettent d'utiliser ces classes dans le polymorphisme multilingue. Essentiellement, il permet au code C++ non géré de rappeler en code managé pour les méthodes virtuelles afin qu'une classe C# puisse dériver d'une classe C++ encapsulée.
C'est assez simple, même si le diable est dans les détails. Faites très attention à la durée de vie des objets - vous avez affaire à deux approches différentes de la gestion de la mémoire, et si vous ne faites pas attention, il est facile de se retrouver avec des pointeurs invalides. Mais c'est une toute autre histoire;)