Cenni preliminari sul marshalling di interoperabilità

Aggiornamento: novembre 2007

Per la maggior parte dei tipi di dati esistono rappresentazioni comuni sia nella memoria gestita che in quella non gestita. Questi tipi vengono gestiti dal gestore di marshalling di interoperabilità. Altri tipi possono essere ambigui o non essere rappresentati affatto nella memoria gestita.

Un tipo ambiguo può avere più rappresentazioni non gestite che eseguono il mapping su un singolo tipo gestito oppure non avere informazioni sui tipi, come la dimensione di una matrice. Per i tipi ambigui, il gestore di marshalling fornisce una rappresentazione predefinita e rappresentazioni alternative, se ne esiste più di una. È possibile fornire istruzioni esplicite al gestore di marshalling su come eseguire il marshalling di un tipo ambiguo.

In questo argomento verranno esaminati i modelli di programmazione basati sul richiamo piattaforma e sull'interoperabilità COM. Nell'argomento secondario Marshalling e apartment COM viene descritto come integrare il marshalling di interoperabilità con il marshalling COM. In Marshalling di chiamate remote viene quindi illustrata l'esecuzione del gestore di marshalling in un ambiente distribuito.

Modelli basati sul richiamo piattaforma e sull'interoperabilità COM

In Common Language Runtime vengono forniti due meccanismi per l'interoperabilità con il codice non gestito:

• Il richiamo piattaforma, che consente la chiamata di funzioni esportate da una libreria non gestita da parte del codice gestito.

• L'interoperabilità COM, che consente l'interazione del codice gestito con oggetti COM mediante le interfacce.

Il marshalling di interoperabilità viene utilizzato sia dal richiamo piattaforma che dall'interoperabilità COM per spostare con precisione gli argomenti dei metodi tra chiamante e chiamato e viceversa, se necessario. Come mostrato nell'illustrazione seguente, eccetto quando sono coinvolte le funzioni di callback, una chiamata del metodo di richiamo piattaforma viene effettuata dal codice gestito a quello non gestito e mai viceversa. Benché i richiami piattaforma possano passare solo dal codice gestito a quello non gestito, i dati possono scorrere in entrambe le direzioni come parametri In o Out. Le chiamate al metodo di interoperabilità COM possono scorrere in entrambe le direzioni.

Flusso delle chiamate con i metodi di richiamo piattaforma e di interoperabilità COM

Al livello inferiore, lo stesso servizio di marshalling di interoperabilità viene utilizzato da entrambi i meccanismi. Alcuni tipi di dati sono tuttavia supportati esclusivamente dall'interoperabilità COM o dal richiamo piattaforma. Per informazioni dettagliate, vedere Comportamento di marshalling predefinito.

Marshalling e apartment COM

Il gestore di marshalling di interoperabilità esegue il marshalling dei dati tra l'heap di Common Language Runtime e quello non gestito. Il marshalling ha luogo ogni volta che il chiamante e il chiamato non possono operare sulla stessa istanza di dati. Il gestore di marshalling di interoperabilità fa sì che il chiamante e il chiamato sembrino operare sugli stessi dati benché dispongano ognuno della propria copia dei dati.

In COM è anche disponibile un gestore che esegue il marshalling dei dati tra apartment COM o diversi processi COM. Quando le chiamate tra codice gestito e non gestito sono effettuate all'interno dello stesso apartment COM, il gestore di marshalling di interoperabilità è il solo a essere coinvolto. Quando si effettuano chiamate tra codice gestito e non gestito in un diverso apartment COM o processo, sono coinvolti sia il gestore di marshalling COM che quello di interoperabilità.

Client COM e Server .NET

Un server gestito esportato con una libreria dei tipi registrata dallo Strumento di registrazione degli assembly (Regasm.exe) dispone di una voce ThreadingModel del Registro di sistema impostata su Both. Questo valore indica che il server può essere attivato in un apartment a thread singolo (Single-Threaded Apartment, STA) o in un apartment con multithreading (Multithreaded Apartment, MTA). L'oggetto server viene creato nello stesso apartment del chiamante, come indicato nella tabella riportata di seguito.

Poiché il client e il server si trovano nello stesso apartment, tutto il marshalling dei dati viene gestito automaticamente dal servizio di marshalling di interoperabilità. Nell'illustrazione seguente viene mostrato il servizio di marshalling di interoperabilità tra gli heap gestiti e non gestiti all'interno dello stesso apartment di tipo COM.

Processo di marshalling nello stesso apartment

Se si intende esportare un server gestito, ricordare che il client COM determina l'apartment del server. Un server gestito chiamato da un client COM inizializzato in un MTA deve garantire la caratteristica thread-safe.

Client .NET e server COM

Benché l'impostazione predefinita per gli apartment dei client .NET sia MTA, è possibile che essa venga modificata dal tipo di applicazione del client .NET. L'impostazione di apartment per i client di Visual Basic 2005, ad esempio, è STA. Per esaminare e modificare l'impostazione di apartment di un client gestito, è possibile utilizzare l'oggetto STAThreadAttribute, l'oggetto MTAThreadAttribute, la proprietà Thread.ApartmentState o la proprietà Page.AspCompatMode.

L'autore del componente imposta l'affinità di thread di un server COM. Nella tabella riportata di seguito vengono mostrate le combinazioni delle impostazioni di apartment per i client .NET e i server COM, nonché i requisiti di marshalling per le diverse combinazioni.

Quando un client gestito e un server non gestito si trovano nello stesso apartment, tutto il marshalling dei dati viene eseguito dal servizio di marshalling di interoperabilità. Tuttavia, quando il client e il server vengono inizializzati in apartment diversi, è necessario anche il marshalling COM. Nell'illustrazione riportata di seguito vengono mostrati gli elementi di una chiamata su diversi apartment.

Chiamata su diversi apartment tra un client .NET e un oggetto COM

Per il marshalling su diversi apartment, procedere come indicato di seguito:

• Accettare l'overhead del marshalling su diversi apartment, evidente solo quando sono presenti molte chiamate oltre il limite. Registrare la libreria dei tipi del componente COM per consentire alle chiamate di attraversare correttamente il limite dell'apartment.

• Modificare il thread principale impostando il thread del client su STA o MTA. Se il client C# chiama ad esempio molti componenti COM STA, è possibile evitare il marshalling su diversi apartment impostando il thread principale su STA.

  Nota:
  Dopo avere impostato il thread di un client C# su STA, occorre eseguire il marshalling su diversi apartment per le chiamate ai componenti COM MTA.

Per istruzioni sulla selezione esplicita di un modello di apartment, vedere Threading gestito e non gestito.

Marshalling di chiamate remote

Come per il marshalling su diversi apartment, si ricorre al marshalling COM nelle chiamate tra il codice gestito e non gestito ogni volta che gli oggetti si trovano in processi separati. Di seguito è riportato un esempio:

• Un client COM che richiama un server gestito su un host remoto utilizza DCOM.

• Un client gestito che richiama un server COM su un host remoto utilizza DCOM.

Nell'illustrazione seguente viene mostrato come il marshalling di interoperabilità e il marshalling COM forniscano canali di comunicazione attraverso i limiti dell'host e del processo.

Marshalling su diversi processi

Mantenimento dell'identità

In Common Language Runtime l'identità di riferimenti gestiti e non gestiti viene mantenuta. Nell'illustrazione riportata di seguito viene mostrato il flusso di riferimenti non gestiti diretti (prima riga) e di riferimenti gestiti diretti (ultima riga) attraverso i limiti dell'host e del processo.

Passaggio dei riferimenti attraverso i limiti dell'host e del processo

In questa illustrazione:

• Un client non gestito recupera un riferimento a un oggetto COM da un oggetto gestito che lo recupera da un host remoto. Il meccanismo dei servizi remoti è DCOM.

• Un client gestito recupera un riferimento a un oggetto gestito da un oggetto COM che lo recupera da un host remoto. Il meccanismo dei servizi remoti è DCOM.

  Nota:
  La libreria dei tipi esportata del server gestito deve essere registrata.

Il numero di limiti di processo tra chiamante e chiamato non è rilevante. La creazione di riferimenti diretti è identica per le chiamate in-process e per quelle out-of-process.

Servizi remoti gestiti

Tra i servizi di runtime vengono inoltre forniti servizi remoti gestiti, utilizzabili per stabilire un canale di comunicazione tra gli oggetti gestiti attraverso i limiti dell'host e del processo. I servizi remoti gestiti possono contenere un firewall tra i componenti di comunicazione, come mostrato nell'illustrazione riportata di seguito.

Chiamate remote attraverso i firewall mediante SOAP o la classe TcpChannel

È possibile incanalare tramite SOAP alcune chiamate non gestite, ad esempio quelle tra i componenti serviti e COM. Per ulteriori informazioni sull'utilizzo dei sevizi remoti gestiti, vedere Panoramica di .NET Framework Remoting.

Vedere anche

Altre risorse

Marshalling di interoperabilità

Comportamento di marshalling predefinito

Marshalling dei dati con richiamo piattaforma

Marshalling dei dati con interoperabilità COM