2009-03-06 7 views
3

Nous utilisons un modèle d'automatisation COM Object pour rendre notre application disponible pour nos clients.Inscription gratuite (Regfree) COM

Ils utilisent pour la plupart python pour accéder à notre interface applicaton. Comme nous voulons être en mesure d'installer (pas encore exécuté, c'est un autre problème) les différentes versions de l'application, nous modifions nos composants COM pour être regfree.

Mais cela est en conflit avec l'accès des langages de script via l'automatisation IDispatch car ils ont besoin des entrées dans le registre.

Notre approche consiste à créer une application qui gère la version active de notre application actuelle. Il permet à l'utilisateur de décider quelle version il veut avoir et il s'occupe des entrées de registre.

Quelles sont les alternatives à notre approche?

Répondre

3

Il existe un protocole dans COM pour ce faire. Si vous versionnez les Interfaces (et modifiez le GUID pour chaque version), vous pouvez installer plusieurs versions. Microsoft le fait avec WORD, etc.

Il est possible de créer une classe Word.Document.5 spécifique à la version 5 de la bibliothèque, ou simplement word.Document qui créera une instance du plus présent sur la machine . Je ne suis pas sûr que cette fonctionnalité soit intégrée dans COM ou qu'elle doive être implémentée, mais cela vaut la peine d'y réfléchir.

+0

La solution de versioning est bien sûr sympa, mais nous avons décidé de ne pas vouloir changer les identités pour chaque version. Et cela ne résout pas le problème d'accès à une ancienne version de l'application à partir d'un script. – PsiX

1

Eh bien, la réponse est suggérée par vous-même. Vous pouvez écrire une application qui a une liste complète de toutes les versions des composants COM. Une fois qu'une version est sélectionnée par l'utilisateur, vous pouvez appeler l'application regsvr32 pour enregistrer cette version particulière.

3

Les objets COM Regfree sont accessibles via l'objet Microsoft.Windows.ActCtx.

En ce qui concerne l'automatisation IDispatch nécessitant des entrées dans le registre - ce n'est pas strictement correct. Je suppose que vous utilisez l'implémentation ATL par défaut, IDispatchImpl. Nous avons résolu cette solution en fournissant notre propre implémentation, IRegFreeDispatchImpl, qui utilisait le activation context manipulation APIs dans le manner suggested here pour intégrer tous les points d'entrée dans la DLL avec une activation/désactivation du contexte d'activation.

Questions connexes