Quel est l'intérêt de _MERGE_PROXYSTUB?

Question

J'ai généré un objet COM ATL à l'aide de VS2008 et le code contient des références à une définition appelée _MERGE_PROXYSTUB (car j'ai choisi l'option "Fusionner le proxy / le stub" lors de l'exécution initiale de l'Assistant.)

Quel est l'intérêt d'un proxy / stub? Si je ne sélectionne pas l'option de fusion, j'obtiens un MyControlPS.DLL à la place - quand cela sera-t-il utilisé?

FWIW le contrôle semble s’inscrire et fonctionner correctement si je supprime tout le code entouré par les éléments _MERGE_PROXYSTUB . Une version de débogage ne définit même pas _MERGE_PROXYSTUB et cela fonctionne toujours correctement.

Alors, puis-je faire sans proxy / stub?

Answer 1

Vous avez besoin d'un proxy / stub si vous souhaitez que votre objet COM soit appelé à partir d'une application utilisant un modèle de thread différent de votre objet COM.

Par exemple, nous avons un plug-in qui est chargé par une application qui utilise un modèle de thread particulier (je ne me rappelle plus lequel), mais notre objet COM est un appartement multithread (MTA). Le proxy / stub est donc requis. pour rassembler les données entre les objets lorsqu'un appel de fonction est effectué, tout en respectant les règles du modèle de thread.

Si ces règles sont enfreintes, COM lève une exception ou retourne un échec HRESULT tel que RPC_E_WRONG_THREAD

.

Si vous ne cochez pas l'option de fusion proxy / stub, alors visual studio produit un projet séparé pour le proxy / stub qui est intégré à une dll séparée. Cela rend les choses plus difficiles à déployer si elles sont nécessaires, mais vous pouvez fondamentalement les ignorer si vous n'êtes pas concerné par les problèmes de modèle de thread.

Vous pouvez donc vous passer de proxy / stubs si l'application appelant l'objet COM utilise le même modèle de thread que votre objet

Larry Osterman fournit une introduction lisible aux modèles de threading sur son blog.

Answer 2

De même, si vos interfaces ne contiennent que des types conviviaux pour les bibliothèques de types (BSTR, VARIANT, etc.) et apparaissent dans le bloc de bibliothèque de votre IDL, vous pouvez choisir de les faire " ordonné par bibliothèque " ce qui signifie qu'un proxy / stub fourni par le système utilise les métadonnées de la bibliothèque de types.

Lorsque des interfaces sont placées dans le bloc de bibliothèque et que DllRegisterServer est personnalisé pour enregistrer la bibliothèque de types (passez TRUE à XxxModule :: DllRegisterServer, si mes souvenirs sont exacts), vos interfaces seront organisées par le système, si nécessaire, comme décrit par John Sibly.

À ce stade, le proxy / stub n'est même pas utilisé. _MERGE_PROXYSTUB n'a donc aucun effet.