est-il possible de forcer une assemblée interoper pour référencer une copie locale de son com dll associé?
Voici le scénario:
J'ai une application .NET qui fait référence à un assemblage interop (interop.otaclient.dll), qui est l'INTEROP pour un COM dll (otaclient.dll, qui est l'API d'automatisation du centre de qualité HP). Je ne suis pas très connu sur le COM, mais si je comprends bien, l'Assembly Interop recherche les classes COM via les références GUID dans le registre, plutôt que de pointer vers un fichier spécifique.
Le problème que j'ai est que la copie de otaclient.dll que les clés de registre pointaient de remplacer par différentes versions en fonction de la version de QC que je viens de vous connecter dans un navigateur et des différentes versions de ces DLL sont pas compatible entre eux. L'application .NET ne sera connectée qu'à une version spécifique de QC, donc je ne peux donc pas avoir le COM DLL varié de cette manière.
Toute suggestion serait grandement appréciée, car ce comportement est vraiment irritant. J'ai vu d'autres questions sur Cométer les problèmes liés à com, mais ils semblent tous à forcer une version locale de la DLL interop à utiliser à la place d'un dans le GAC, plutôt que de ce scénario particulier impliquant la DLL réelle.
3 Réponses :
Vous voulez COMB .
Salut pavel. Merci pour le lien - j'ai suivi l'exemple et vs a généré l'entrée manifeste pour OTACLIENT comme prévu. Cependant, je vois toujours les mêmes symptômes si la version plus récente de la DLL a été utilisée en dernier par l'application de navigateur qui utilise également cette DLL. Pensez-vous qu'il est possible que OTACLIENT ait ses propres dépendances qui deviennent également écrasées avec de nouvelles versions? Dans l'affirmative, toute suggestion sur la façon dont je pourrais faire face à cela?
Il peut être possible que ces dépendances soient elles-mêmes composantes. Si tel est le cas, vous devez les gérer de manière similaire (afin que vous vous retrouviez avec un ensemble de bibliothèques autonomes).
Pavel m'a pointé dans la bonne direction, alors je vais marquer sa réponse. Pour le bénéfice de tous les autres, voici ce que j'ai fait:
De cette façon, vous pouvez vous connecter et sortir des instances de QC dont les versions diffèrent de celle utilisée par votre application sans la casser. Dans mon cas, j'ai une instance QC locale qui est v9 et utilisée pour une automatisation spécifique au projet (pour diverses raisons, elle est fortement personnalisée pour répondre à nos besoins, a beaucoup d'espace pour le stockage de capture d'écran, etc.), et à laquelle ma demande se connecte. Toutefois, pour les tests manuels, j'ai également besoin de vous connecter à l'aide d'une instance V9.2 située ailleurs. Si j'avais déjà été connecté à l'instance V9.2, je devrais ensuite ouvrir l'instance V9 dans IE et le laisser rejeter les commandes avant d'exécuter mon application ... et maintenant je ne le fais pas. :)
Un petit exemple montrant comment web.config change après que nous définissions la propriété isolée vers true, aiderait les autres à comprendre ce qui se passe réellement à l'arrière lorsque nous définissons des biens isolés vers true. Vs entre réellement quelques lignes dans votre code, de sorte qu'il utilisera COM dll de CLSID spécifique.
En fait, je dispose de deux applications .NET sur le même serveur, où une application utilise le centre de qualité 10.0 DLL et autres sont mis à niveau vers le centre de qualité ALM 11.0. Donc, sur le même serveur, nous ne pouvons pas enregistrer une DLL avec le même nom.