Limitare un server EXE ATL a un solo processo (istanza)

Question

Ho un server ATL EXE scritto con C ++ (Visual Studio 2010, con unendo la DLL proxy-Stud). L'eseguibile è compilato per Windows 7 x86 e x64. Di seguito si verificano su entrambe le architetture:

Il server ATL EXE dovrebbe funzionare come un "processo del server", cioè un processo (myatlserver.exe, solo uno!) Dovrebbe esistere per macchina e molti client (manteniamola semplice: sulla stessa macchina) consumano oggetti COM da esso. Il server salva lo stato dell'applicazione (in memoria) e tutti i client dovrebbero "condividere" questo sate, utilizzando gli oggetti COM esposti del server.

Il server EXE di solito inizia quando il sistema si avvia perché viene invocato da una chiamata COM per creare uno dei suoi oggetti ospitati. La chiamata ha origine dall'interno del processo Spoolsv.exe (Servizio Spooler Stampa). Ciò provoca l'esecuzione del processo del server con l'utente "Sistema" (immagino a causa del fatto che Spoolsv.exe funziona con "Sistema").

Quando uno dei client crea un oggetto COM dal server ATL, viene istanziato un altro processo (di nuovo myatlserver.exe) (in esecuzione sotto l'utente che ha effettuato l'accesso a Windows), quindi non può condividere lo stato dell'applicazione con quello "originale" (originale (originale "(originale" (originale "(originale" (originale "(originale" che è in esecuzione sotto "sistema"). Un secondo client si collegherà a quello istanziato dall'utente loggato (il secondo ").

Dopo aver cercato innumerevoli forum sul web, sono riuscito a giungere alle seguenti conclusioni:

1) Il mio server ATL utilizza il modulo ATL predefinito (generato automaticamente da VS2010) che eredita da ATL :: CatlexEmodulet <>. Scavando nelle intestazioni ATL Sono positivo che questo modulo chiama atlCommoduleRegisterClassObjects con i flag corretti per questo tipo di utilizzo (dwclscontext = clsctx_local_server, flags = regcls_multipleuse | regcls_suspedended). Quindi governa questo.

2) Utilizzo di start -> run -> dcomcnfg -> dcom config -> myatlserver -> Proprietà ho impostato l'opzione "questo utente" nella scheda 'Identity' (con l'utente dell'amministratore locale). Nella scheda "Posizione", l'opzione "eseguire l'applicazione su questo computer" non è selezionata e grigia. Questo mi ha fatto cercare di nuovo e sono arrivato qui: http://social.technet.microsoft.com/forums/en-us/w7itprosecurity/thread/4f63ee111111111111111111111111111111111111111111-e472-40f9-85db-a6b235d7579c. Il link spiega che la versione X64 dell'utilità DCOMCNFG è buggy e si dovrebbe usare la versione a 32 bit su X64 Windows (start-> run-> 'mmc Comexp.msc /32'). Dopo averlo controllato su due sistemi (uno di ciascuno) ho scoperto che l'opzione "Esegui su questo computer" è grigiata e non selezionata su entrambi.

Da questo punto sono totalmente perso (e cerco di sopprimere la frustrazione ... :-)). Sono sul percorso corretto? Qualcuno l'ha fatto prima?

O l'intento originale: come faccio a rendere il mio server ATL EXE "individuato"?

Grazie!

Omri

Answer 1

Ok ... quindi finalmente risponderò :-)

Ho trovato un po 'di tempo per provare a risolvere questo problema (e di nuovo ...). Dopo aver impostato 2 diverse nuove macchine Dev (Win7x86 e Win7x64) e utilizzando solo la versione a 32 bit di DCOMCNFG - una macchina ha funzionato, quello 32 bit (Win7x86)!

Scavando nelle macchine "non lavoratori", ho scoperto di aver incontrato Guids Hell! Sulla macchina DEV X64, gli oggetti COM sono stati registrati con GUID diversi rispetto ai valori nei file di codice (il codice generato). Per renderlo ancora difficile, ho usato punti di connessione, che sono stati registrati anche con GUID non validi. Con questo intendo: i valori GUID nel registro non erano corretti! Fino ad ora, non ho idea del perché ciò accada, ma sono sicuro al 100% che i procedimenti commessi in VS2010 siano buggy (generano codice parziale, se non presenti ...), forse il codice che questi maghi generano stanno causando problemi di registrazione.

Per risolvere il problema ho eliminato manualmente tutte le chiavi di registro pertinenti del server ATL, ho annullato la registrazione automatica nel progetto VS e registrato Exe da solo (su X64 utilizzando la console %Windir % syswow64 cmd.exe, non quello nativo X64).

Dopo aver registrato manualmente il server, tutto ha funzionato bene (come previsto, un singolo processo, condiviso tra diversi client) e non c'erano caselle di controllo grigio nell'utilità di configurazione DCOMCNFG.

Sono sicuro che questa soluzione ha molte lacune inspiegabili, ma funziona per me (per ora ...).

Saluti ;-)