2012-05-02 13 views
6

Ho un cliente/partner che sta cercando di collegare la propria applicazione alla nostra utilizzando la nostra funzionalità COM esposta. Finora, hanno un oggetto COM che rappresenta un'istanza del nostro pacchetto software e quindi utilizzano i nostri metodi COM per creare in modo programmatico qualcosa per l'utente in base a ciò che hanno fatto nella loro applicazione. È essenzialmente una funzione di "esportazione".Rilasciare "proprietà" dell'oggetto COM in .NET

Quello che mi hanno chiesto di fare, che non riesco a capire come fare è consentire all'utente di decidere quando l'istanza è chiusa. Ciò che intendo è quando il nostro pacchetto software viene caricato, è visualizzabile e interagisce con l'utente. Quando avranno finito, farebbero clic sulla croce in alto a destra per uscire dal software. Questo non funziona poiché l'oggetto COM è ancora "attivo" nella loro applicazione. Il nostro pacchetto software può essere chiuso solo eliminando il processo in Task Manager mentre l'applicazione che lo ha caricato tramite COM rimane aperto. Una volta che la loro applicazione è terminata, la nostra si chiuderà automaticamente. Sembra che la loro applicazione "possegga" la nostra a causa della chiamata COM.

Ho fatto una rapida app dimostrativa in C# per provare a utilizzare cose come Marshal.FinalReleaseComObject(myObject) inutilmente.

Mi rendo conto che l'utilizzo di COM per questo genere di cose non è proprio quello a cui è destinato, ma si spera che ci sia una soluzione alternativa? Il cliente/partner utilizza VB.NET ma C# va bene.

+0

Si prega di chiarire se l'applicazione è automatizzata dall'interno dell'applicazione stessa (simile allo scripting VBA all'interno di applicazioni VS o Office) o dall'esterno (simile all'utilizzo dell'automazione di Word per creare un nuovo documento dalla propria app/script della console)? –

+0

Non riescono a chiudere una finestra? Non ha senso, dovrai chiarire. –

+0

Viene da fuori, stanno usando VB per avviare un nuovo processo facendo riferimento al nostro exe e istanziando un oggetto COM da esso. Abbiamo un "Open" che fa esattamente quello che sembra, apre una finestra utilizzabile del nostro pacchetto software. In termini di non essere in grado di chiudere la finestra, non è possibile fare clic sulla X rossa in alto a destra, ma è possibile ma non accade nulla. Si chiuderà solo quando la loro applicazione VB è chiusa. Non so molto sull'interoperabilità di COM, ma sembra che l'app VB abbia la proprietà o sia la madre di quel processo. – sxthomson

risposta

3

Hai dimenticato alcune informazioni critiche sulla tua applicazione, incluso soprattutto come stai implementando le interfacce COM che esponi all'applicazione client. Un aspetto della tua descrizione che è una bandiera rossa per me è l'istanziazione della tua applicazione. Tu dici che l'applicazione client è "usando VB per avviare un nuovo processo facendo riferimento al nostro exe". Questo non dovrebbe essere necessario se hai implementato e registrato correttamente il tuo server COM. Lascia che ti dica l'architettura che userei per realizzare ciò che chiedi, e spero che questo ti sia utile.

Per iniziare, se si desidera fornire un oggetto COM da un processo separato, il modo corretto è implementare un server COM fuori dal processo. Con un server fuori processo, COM avvierà automaticamente l'applicazione quando un client richiede una delle tue interfacce tramite COM. Parte dei requisiti di implementazione di un server fuori processo è l'arresto automatico quando l'ultimo client COM rilascia il loro ultimo puntatore di interfaccia.

Per esporre un'interfaccia utente dal server fuori processo, è necessario generare un thread STA (Single-threaded Apartment) separato con un loop di messaggi. Ciò consentirà di chiudere qualsiasi finestra sul thread STA, inclusa la finestra principale, senza uccidere il server COM. Questo perché l'implementazione del server COM eseguirà il proprio thread di loop di messaggi Multi-threaded Apartment (MTA) per supportare la COM fuori dalle chiamate proc. Il thread MTA è il thread dell'applicazione principale e il server lo spegnerà quando viene rilasciata l'ultima interfaccia client.

Un server COM non deve essere spento mentre le interfacce rimangono inutilizzate. Ciò significa che l'applicazione client ha la responsabilità di rilasciare correttamente le interfacce. Ma il tuo frame di test .NET dovrebbe averlo fatto, quindi sembra che qualcosa non sia giusto con la tua implementazione.

Supponendo che seguiate questa guida, avrete bisogno di un piano per gestire lo scenario in cui è stata rilasciata l'ultima interfaccia client, ma avete ancora finestre dell'interfaccia utente aperte. Una volta che tutto è stato configurato correttamente, questo non dovrebbe essere un grosso problema. Ad esempio, puoi semplicemente prendere un riferimento a una delle tue interfacce mentre l'interfaccia utente è aperta, questo impedirà l'arresto del MTA.

Problemi correlati