Marshalling di interoperabilità

Il marshalling di interoperabilità è responsabile del modo in cui i dati vengono passati negli argomenti dei metodi e nei valori restituiti tra la memoria gestita e non gestita nel corso delle chiamate. È un'attività della fase di esecuzione effettuata dal servizio di marshalling di Common Language Runtime.

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 questa panoramica sono incluse le sezioni seguenti:

• Modelli basati su platform invoke e sull'interoperabilità COM

• Marshalling e apartment COM

• Marshalling di chiamate remote

• Argomenti correlati

• Riferimenti

Modelli basati su platform invoke e sull'interoperabilità COM

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

• Platform invoke, 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 (Component Object Model) mediante interfacce.

Il marshalling di interoperabilità viene utilizzato sia da platform invoke 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, una chiamata al metodo di platform invoke viene effettuata dal codice gestito a quello non gestito e mai viceversa, ad eccezione del caso in cui sono coinvolte funzioni di callback. Benché il flusso delle chiamate platform invoke possa andare solo dal codice gestito a quello non gestito, il flusso dei dati può essere in entrambe le direzioni, come parametri di input o di output. Le chiamate al metodo di interoperabilità COM possono scorrere in entrambe le direzioni.

Flusso delle chiamate con i metodi di platform invoke 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 da platform invoke. Per informazioni dettagliate, vedere comportamento predefinito del marshaling.

Torna all'inizio

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à.

Server gestiti e client COM

Un server gestito esportato con una libreria dei tipi registrata dallo Regasm.exe (strumento di registrazione di assembly) 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 gestiti e server COM

Benché l'impostazione predefinita per gli apartment dei client gestiti 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 System.STAThreadAttribute, l'oggetto System.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.

Torna all'inizio

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 in 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 .NET Remoting Overview.

Torna all'inizio

Argomenti correlati

Torna all'inizio

Riferimenti

System.Runtime.InteropServices

Torna all'inizio