Interop COM e gruppi dipendenti dipendenti senza registrazione

Question

Stiamo lavorando per l'integrazione di una grande applicazione basata su MFC con una manciata di componenti aggiuntivi (.NET) gestiti. La comunicazione con questi componenti aggiuntivi viene eseguita tramite COM.

Storicamente, abbiamo appena usato il registro per rendere questi componenti aggiuntivi disponibili (come server COM) per l'applicazione. Ma ora stiamo cercando di usare l'interoperabilità COM senza registrazione per fare questo.

Vorremmo che questi componenti aggiuntivi fossero in grado di vivere in una directory separata da quella in cui è in esecuzione l'applicazione - idealmente ovunque. Ma, apparentemente, ci sono problemi con la creazione di istanze degli oggetti server a causa dell'impossibilità di risolvere assembly dipendenti, che vivono anche nella directory con la DLL del server COM.

L'interoperabilità COM "obsoleto" ha gestito questo utilizzando un contesto LoadFrom quando ha caricato il gruppo di destinazione. Ma il meccanismo del contesto di attivazione non sembra farlo.

Qualcuno sa come farlo funzionare? Non è chiaro se possiamo identificare gli assembly dipendenti nel manifest SxS del modulo, o forse possiamo creare il contesto di attivazione in modo diverso?

Grazie per eventuali pensieri/suggerimenti!

Jeff

Answer 1

Speranza capisco la questione come io non sono così familiare con un progetto MFC, né si tratta di vincoli. Che ne dici di una classe .NET "ben conosciuta" con un'interfaccia (permanentemente registrata con l'app MFC) che, a sua volta, gestisce tutte le attivazioni e le istanze?

Rodney

Answer 2

Non sei iscritto DLL intermediati (interoperabilità) con .net framework?

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "percorso .. \ AxInterop.xxx.dll" o C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "percorso .. \ Interop.xxx.dll"

saluti Phani

Answer 3

Quando guardo l'articolo a Simplify App Deployment with ClickOnce and Registration-Free COM Noto che fanno riferimento il nome del file DLL oggetto COM registrazione gratuita nel manifesto dell'applicazione. Sto indovinando che questo nome di file potrebbe essere cambiato per includere una directory o tale.

In secondo luogo, nella sezione "Un esempio più complesso", includono oggetti COM dipendenti come riferimenti al loro progetto e li imposta come isolati. Cioè, ora sono anche senza registrazione. La mia ipotesi è che il loro percorso potrebbe anche essere aggiornato.

Answer 4

aprire il prompt dei comandi di Visual Studio e cercare di registrare il proprio assembly utilizzando regasm

regasm /tlb:"path"