Assemblys COM interopérables et dépendants sans enregistrement

Nous travaillons à l'intégration d'une grande application MFC avec une poignée de compléments gérés (.NET). La communication avec ces compléments est effectuée via COM.Assemblys COM interopérables et dépendants sans enregistrement

Historiquement, nous venions d'utiliser le registre pour rendre ces compléments disponibles (en tant que serveurs COM) à l'application. Mais, maintenant, nous essayons d'utiliser COM interop sans enregistrement pour le faire.

Nous aimerions que ces compléments puissent vivre dans un répertoire distinct de celui dans lequel l'application s'exécute - idéalement n'importe où. Mais, nous rencontrons apparemment des problèmes avec l'instanciation des objets serveur en raison de l'incapacité de résoudre les assemblys dépendants, qui vivent également dans le répertoire avec la DLL du serveur COM.

L'interopérabilité COM "à l'ancienne" gérait cela en utilisant un contexte LoadFrom lors du chargement de l'assembly cible. Mais le mécanisme du contexte d'activation ne semble pas le faire.

Est-ce que quelqu'un sait comment faire fonctionner ça? Il n'est pas clair si nous pouvons identifier les assemblys dépendants dans le manifeste SxS du module, ou peut-être que nous pouvons créer le contexte d'activation différemment?

Merci pour vos idées/conseils!

Jeff

Source

2009-10-29 Jeff

Avez-vous trouvé une solution à that'? – RayOldProf

Espoir Je comprends la question que je ne suis pas familier avec un projet MFC, ni c'est des contraintes. Que diriez-vous d'une classe .NET "bien connue" avec une interface (enregistrée en permanence avec l'application MFC) qui, à son tour, gère toutes les activations et instanciation?

Rodney

Source

2009-12-22 06:40:25 Rodney

C'est en fait une solution de contournement qui a été couronnée de succès: nous créons un module C++/CLI, qui peut être activé sans inscription, et nous l'utilisons pour instancier la classe C#. Pour que cela fonctionne, nous devons également configurer un gestionnaire d'événements AssemblyResolve, afin que les assemblys dépendants dans le même répertoire puissent être localisés. C'est OK, mais c'est un peu maladroit. Il semble que cela devrait pouvoir fonctionner sans ce niveau supplémentaire d'indirection. – Jeff

-1

Avez-vous enregistré intermédiés (PIA) avec dll NET Framework?

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "chemin .. \ AxInterop.xxx.dll" ou C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm « chemin .. \ Interop.xxx.dll »

Cordialement Phani

Source

2009-12-23 07:49:22 Phanidhar

Merci pour le commentaire, Phani. Le but d'essayer de faire ceci est d'éviter l'enregistrement. – Jeff

Quand je regarde l'article à Simplify App Deployment with ClickOnce and Registration-Free COM Je note qu'ils font référence au nom de l'enregistrement DLL sans objet COM dans le manifeste d'application. Je devine que ce nom de fichier pourrait être changé pour inclure un répertoire ou tel. Deuxièmement, dans la section «Un exemple plus complexe», ils incluent les objets COM dépendants comme références à leur projet et les définissent comme isolés. Autrement dit, ils sont maintenant aussi sans inscription. Ma conjecture est que leur chemin pourrait également être mis à jour.

Source

2009-12-23 11:12:33

Nous n'avons pas vraiment le luxe de modifier le manifeste d'application, car les assemblages chargés ici sont des "compléments", et peuvent être ajoutés après coup. Il est possible que quelque chose de plus dans le manifeste du module soit la réponse ici, mais rien de ce que nous avons essayé n'a fonctionné - il semble être "juste" un problème avec les algorithmes de chargement de .NET. – Jeff

-1

ouvrir l'invite de commande Visual Studio et essayez d'enregistrer votre ensemble à l'aide regasm

regasm /tlb:"path"

Source

2009-12-23 12:34:32 shahjapan

Comme je le dis plus haut, nous ne voulons rien enregistrer. Cela inclurait la bibliothèque de types. De plus, dans ce cas, la bibliothèque de types pour l'interface que nous implémentons est déjà enregistrée. – Jeff

Assemblys COM interopérables et dépendants sans enregistrement

Répondre

Questions connexes