La creazione di un progetto ATL in MSVC sembra non creare uno ma due progetti; il secondo ha lo stesso nome del primo, ma con PS è stato aggiunto al suo nome. Qual è lo scopo di questo secondo progetto e come posso sapere se ne ho bisogno?
COM supporta rendendo metodo di interfaccia chiamate in due diversi thread, due diversi processi o due macchine diverse. Questo è chiamato marshaling. Due thread diversi sono il caso più comune, un server COM spesso non è thread-safe. COM implementa la sicurezza del thread per tali coclocks a thread singolo effettuando il marshalling della chiamata dal thread 'errato' al thread che ha creato il server. Il marshalling tra processi si verifica quando si scrive un server out-of-process. Tra diversi computer su una rete si chiama DCOM.
Questo viene implementato con la creazione di un'istanza dell'interfaccia che sembra esattamente come l'originale. Ma tutti i metodi dell'interfaccia sono in realtà sostituti che svolgono il compito di effettuare il marshalling della chiamata. Questo è il proxy. All'altra estremità del filo c'è un sostituto che sembra esattamente come come l'interfaccia ma fa il lavoro opposto. Questo è lo stub. Il proxy e lo stub lavorano insieme per creare l'illusione che stai facendo una semplice chiamata di metodo nel tuo programma.
Il lavoro principale del proxy è serializzare gli argomenti della chiamata di metodo in un buffer di memoria o pacchetto di rete. Questo può essere piuttosto non banale, specialmente quando si usano puntatori su strutture di dimensioni variabili. COM ha bisogno di aiuto per farlo e questo è il lavoro del tuo progetto FooPS. Quando esegui midl.exe sul tuo file .idl, midl genera automaticamente il codice dalle definizioni dell'interfaccia per implementare il proxy e lo stub. Questo è abbastanza spesso abbastanza buono, ma potrebbe essere necessario implementare il proprio se le parole chiave incorporate in midl non sono sufficienti per descrivere i dati.
Ultimo ma non meno importante, Windows fornisce un marshaller standard che può eseguire il marshalling di interfacce semplici. Progettato per supportare il sottoinsieme di COM definito da COM Automation. In altre parole, le interfacce derivano da IDispatch e utilizzano solo tipi compatibili con l'automazione. Hai solo bisogno di ottenere le voci di registro giusto per abilitarlo e non necessitare altrimenti del proxy/stub generato da midl. E naturalmente, se si fanno solo semplici chiamate in-process su un thread, non ne avrete nemmeno bisogno. Questo è abbastanza comune.
risposta impressionante ... ha reso la mia giornata :) – Houston
È il codice proxy/stub, che contiene marshaller di dati non standard necessari per trasferire i dati tra diversi appartamenti (relativi al threading). Viene utilizzato quando l'applicazione, che chiama l'oggetto COM, utilizza un modello di threading COM diverso. C'era un'opzione nella procedura guidata ATL/COM per unire questo codice nella libreria principale. In molti scenari comuni non devi preoccuparti di ciò (ad esempio quando la tua dll COM viene eseguita nel contesto client), a meno che tu non voglia scrivere un marshaller personalizzato.
Come detto @ebutusov, * progetto PS contiene implementazioni per Proxy and Stub. Non sono standard, ma sono generati da MIDL per le interfacce esportate dal server ATL. Queste interfacce sono dichiarate nel file * .IDL. L'uscita del progetto è DLL. È possibile leggere this article per ottenere maggiori dettagli.
È possibile rimuovere il progetto PS dalla soluzione nel caso in cui non si definiscano interfacce personalizzate nel proprio file * .IDL o se si definiscono solo interfacce con modificatori duali e oleautomatici. In tal caso verrà utilizzato un marshaller di tipo libreria standard.
Al fine di essere in grado di utilizzare il marshaller libreria dei tipi di serie, si deve registrare un TypeLibrary (che viene fatto automaticamente dal momento che si sta utilizzando ATL)
"PS" sta per proxy/stub, probabilmente qualcuno sa più di me cosa significa! – ybungalobill